#c# #azure #asp.net-core #azure-active-directory
#c# #azure #asp.net-core #azure-active-directory
Вопрос:
В частности, есть ли какой-либо способ проверить, AuthenticationContext.AcquireTokenByAuthorizationCodeAsync() успешно ли получен токен обновления?
Комментарии:
1. Вы хотите дождаться результата, затем проверьте возвращаемое значение
Taskдля токена доступа. Проверьте learn.microsoft.com/en-us/dotnet/api /…2. @hmiedema9 Мне нужно знать о токене обновления , а не о токене доступа.
3. Он всегда должен возвращать один. Сталкивались ли вы со случаем, когда это было не так? ADAL обрабатывает токены обновления внутренне, они вам не отображаются. Если вы хотите сохранять токены при перезапусках процесса, вам нужно реализовать токен-кэш и передавать его контексту всякий раз, когда вы создаете контекст.
4. И вам не нужен токен обновления, вы можете запросить токены у ADAL, и он будет использовать токен обновления, если срок действия токена доступа истек.
Ответ №1:
Библиотека аутентификации Azure AD (ADAL) использует свой кэш токенов для эффективного управления токенами. Когда вы запрашиваете токен доступа с помощью AcquireTokenSilentAsync и в кэше есть действительный токен, вы получаете его сразу. В противном случае, если есть токен обновления, он используется для получения нового токена доступа из Azure AD. Затем новый токен записывается в кэш и возвращается вам.
Сама библиотека поддерживает все виды сценариев: от мобильных клиентов и JavaScript до серверных приложений. Его можно использовать для хранения токенов как для одного пользователя, так и для многих пользователей. Если вы посмотрите на класс ключей кэша токенов, вы увидите, что токены могут храниться и запрашиваться целевыми ресурсами и органами власти в дополнение к клиентам (приложениям) и пользователям.
Вы не работаете напрямую с ключом кэша и базовым словарем. Вместо этого вы правильно создаете AuthenticationContext и передаете другие параметры, такие как учетные данные клиента, идентификаторы пользователей и / или ресурсов, различным методам AcquireToken *.
По умолчанию в памяти имеется одноэлементный кэш, который хорош для быстрого тестирования, но он не работает в реальных сценариях. Во-первых, токены имеют свое время жизни, и если ваше приложение перезапускается, вы теряете их, и пользователю придется повторно проходить аутентификацию в Azure AD. Во-вторых, при масштабировании вам необходимо сделать кэш доступным для всех экземпляров вашего приложения.
Способ, которым кэш поддерживает внешнее хранилище, в основном сводится к следующему. Вы производны от TokenCache и предоставляете обработчики для событий BeforeAccess и AfterAccess. Технически это даже не события, вы просто предоставляете пару делегатов. BeforeAccess вызывается каждый раз, когда ADAL хочет получить доступ к кэшу, и именно здесь вы получаете возможность заполнить кеш из вашего внешнего хранилища. AfterAccess вызывается в конце методов AcquireToken *, и вы хотите сохранить кэш, если он был изменен, что вы можете определить, изучив свойство HasStateChanged. Довольно прямолинейно.
Теперь, когда вы загружаете или сохраняете кэш, он включает в себя весь словарь, а не только отдельные элементы. Вам предоставляются удобные методы сериализации и десериализации, поэтому вам не нужно беспокоиться о структуре ключей и значений. Вместо этого вы просто сохраняете массивы байтов.
Это означает, что в веб-приложениях на стороне сервера вы хотите управлять кэшем пользователями.
Вы можете выбрать любую технологию внешнего хранилища и доступа к данным. В ASP.NET Ядро имеет смысл использовать IDistributedCache, поскольку вы получаете поддержку SQL Server и Redis из коробки.
Для получения дополнительной информации, пожалуйста, просмотрите: