【问题标题】:Implementing TokenCache when I only need to store a single token per cache当我只需要为每个缓存存储一个令牌时实现 TokenCache
【发布时间】:2018-04-27 17:54:14
【问题描述】:

我有一个应用程序旨在读取来自多个租户的租户数据,这需要管理员同意。所以我只需要为每个租户从AquireTokenByAuthorizationCodeAsync() 存储一个访问令牌和一个刷新令牌。所以我想,如果我在这种场景下实现一个TokenCache扩展,是否有必要实现TokenCache.AfterAccessTokenCache.BeforeAccess?此外,当使用AquireTokenAsync() 时,缓存位是被获取的新令牌覆盖还是只是附加到它上面?如果我想覆盖旧令牌,我可以简单地使用TokenCache.BeforeWrite 来清除旧缓存吗?

基本上,这就是我的想法:

public class ADALTokenCache : TokenCache
{
    public Guid TenantId;

    public ADALTokenCache(Guid tenantId) : base()
    {
        TenantId = tenantId;
        using (var dbContext = new MyDbContext())
        {
            byte[] cache = dbContext.TokenCacheSet.FirstOrDefault(c => c.TenantId == TenantId);
            if (cache != null)
            {
                Deserialize(MachineKey.Unprotect(cache, "ADALCache"));
            }
        }
    }


    void BeforeWriteNotification(TokenCacheNotificationArgs args)
    {
        //Could I call Clear() here so that only
        //the new token from AquireTokenAsync() is written?
    }
}

【问题讨论】:

    标签: c# azure azure-active-directory adal


    【解决方案1】:

    回答您的问题

    • 示例中的缓存之所以如此,是因为可能有多个用户登录到应用程序。顺便说一句,即使这是不同租户中的同一用户(身份可能不同),情况也会如此。您在 Custom token cache serialization in Web applications / Web API 中有实施示例
    • 确实,当AcquireTokenSilentAsync 刷新令牌时,它将覆盖缓存中的前一个令牌。

    但是,退后一步

    • 如果我理解正确,在您的场景中,您的应用程序不是要获取令牌来访问给定用户的数据,而是要访问租户数据(对于用户所属的租户?),然后定期做一些操作。

    • 如果您有一个守护程序应用程序(但多租户)不是更合适吗?因此您可能想要使用client credentials flow 而不是authorization code flow。 由于您使用的是 ADAL(V1 端点),您可以在 Azure 门户中预先同意该应用程序吗?您不需要登录任何用户?客户端凭据流页面包含指向守护程序应用程序的 ADAL 示例的链接。

    • 您可能还想看看active-directory-dotnet-daemon-v2,它似乎与您的场景非常接近(但对于 Azure AD V2 端点)。不过,它很容易转置到 Azure AD V1 端点,或者您仍然可以按原样使用示例,但将接受的权限限制为仅一组租户。

    【讨论】:

    • 感谢您的回答。事实上,我的应用程序是关于读取租户数据而不是用户数据的,我的第一个想法是使用客户端凭据流,效果很好。但是这里的想法是,使用授权代码流程,我只需要使用管理员帐户登录一次,这足以让我的应用程序从该管理员的租户访问数据,并且与凭据流程相比,这涉及的手动步骤更少。
    • 这两种方法都有好的一面和坏的一面。授权代码(委托)很好,因为它在用户上下文中访问 API,并将访问限制为仅用户可以访问的内容。不好的一面是刷新令牌可以被撤销(例如,如果用户的密码被重置)。客户端凭据很好,因为它是可靠的。撤销它的唯一方法是手动删除权限或删​​除服务主体。不好的一面是它需要组织范围内的访问权限。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-03-28
    • 2015-04-18
    • 2017-12-15
    • 2016-07-06
    • 2021-11-15
    相关资源
    最近更新 更多