Реализация TokenCache, когда мне нужно хранить только один токен на кеш

Question

У меня есть приложение, которое предназначено для чтения данных арендатора от нескольких арендаторов, для чего требуется согласие администратора. Поэтому мне просто нужно хранить один токен доступа и один токен обновления из AquireTokenByAuthorizationCodeAsync() для каждого арендатора. Поэтому я подумал, что если бы я реализовал расширение TokenCache в таком сценарии, нужно ли было бы внедрять TokenCache.AfterAccess и TokenCache.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?
    }
}

Answer 1

Чтобы ответить на ваши вопросы

• Причина, по которой кэш в примерах такой, какой он есть, заключается в том, что несколько пользователей могут войти в приложение. Это будет, кстати, так, даже если это один и тот же пользователь в разных арендаторах (идентичность может отличаться). у вас есть примеры реализации в Пользовательская сериализация кеша токенов в веб-приложениях / Web API
• действительно, когда AcquireTokenSilentAsync обновит токен, он переопределит предыдущий токен в кэше.

Однако, отступая

• если я правильно понимаю, в вашем сценарии ваше приложение предназначено не для получения токена для доступа к данным для данного пользователя, а для доступа к данным арендатора (для арендатора, к которому принадлежит пользователь?), А затем регулярно выполнить некоторые операции.

• Не было бы больше случая, чтобы у вас было приложение демона (но мультитенантное)? и поэтому вы можете захотеть использовать поток учетных данных клиента вместо потока кода авторизации . Поскольку вы используете ADAL (конечная точка V1), вы можете предварительно согласовать приложение на портале Azure? Вам не нужно было бы входить в систему любого пользователя? На странице с потоками учетных данных клиента есть ссылки на образцы ADAL для приложений-демонов.

• вы также можете захотеть взглянуть на active-directory-dotnet-daemon-v2 , который кажется очень близким к вашему сценарию (но для конечной точки Azure AD V2). Однако его можно легко перенести в конечную точку Azure AD V1, или вы все равно можете использовать образец как есть, но ограничить общепринятые права доступа только набором арендаторов.