Библиотека аутентификации Azure AD (ADAL) использует свой кеш токена для эффективного управления токенами. Когда вы запрашиваете токен доступа с помощью AcquireTokenSilentAsync и в кэше есть действительный токен, вы сразу получаете его. В противном случае, если есть токен обновления, он используется для получения нового токена доступа из Azure AD. Затем новый токен записывается в кеш и возвращается вам.
Сама библиотека поддерживает все виды сценариев: от мобильных и JavaScript-клиентов до серверных приложений. Он может использоваться для хранения токенов как для одного пользователя, так и для многих пользователей. Если вы посмотрите на класс ключей кэша токенов, то увидите, что токены могут храниться и запрашиваться целевыми ресурсами и полномочиями в дополнение к клиентам (приложениям) и пользователям.
Вы не работаете напрямую с ключом кеша и базовым словарем. Вместо этого вы правильно конструируете AuthenticationContext и передаете другие параметры, такие как учетные данные клиента, идентификаторы пользователя и / или ресурса, различным методам AcquireToken *.
По умолчанию в памяти имеется одноэлементный кеш, который подходит для быстрого тестирования, но не работает в реальных сценариях. Во-первых, токены имеют свой срок жизни, и если ваше приложение перезапускается, вы теряете их, и пользователю придется повторно проходить аутентификацию в Azure AD. Во-вторых, когда вы уменьшаете масштаб, вам нужно сделать кеш доступным для всех экземпляров вашего приложения.
То, как кеш поддерживает внешнее хранилище, сводится к следующему. Вы наследуетесь от TokenCache и предоставляете обработчики для событий BeforeAccess и AfterAccess. Технически это даже не события, вы просто предоставили пару делегатов. BeforeAccess вызывается каждый раз, когда ADAL хочет получить доступ к кешу, и здесь у вас есть возможность заполнить кеш из внешнего хранилища. AfterAccess вызывается в конце методов AcquireToken *, и вы хотите сохранить кеш, если он был изменен, что можно узнать, изучив свойство HasStateChanged. Довольно прямо вперед.
Теперь, когда вы загружаете или сохраняете кеш, который включает в себя весь словарь, а не только отдельные элементы. Вам предоставляются удобные методы сериализации и десериализации, поэтому вам не нужно беспокоиться об их структуре ключей и значений. Вместо этого вы просто сохраняете массивы байтов.
Это означает, что в веб-приложениях на стороне сервера вы хотите управлять кешем пользователями.
Вы можете выбрать любую технологию внешнего хранилища и доступа к данным. В ASP.NET Core имеет смысл использовать IDistributedCache, когда вы получаете поддержку SQL Server и Redis «из коробки».
Для дальнейшего ознакомления, пожалуйста, просмотрите:
Адал-РОС-токен-кэш-в-Asp-нетто-жильный