У меня есть сценарий, когда ожидается, что 3 разных типа клиентов (типы устройств) смогут проходить проверку подлинности в моем веб-приложении через Azure AD. Однако только в первом типе (обычный браузер из среды ПК) пользователей просят ввести свои имя пользователя и пароль Azure AD для входа в систему. Моя идея заключалась в том, чтобы создать какой-то процесс, который требует входа только с помощью Azure AD. имя пользователя и пароль в первый раз. Пользователи будут использовать первый тип клиента для первого входа в систему, но с этого момента процесс также будет работать без имени пользователя и пароля; вместо этого пользователи смогут получить доступ к системе с помощью имени пользователя + пин-кода или даже с помощью входа на смарт-карту.
После некоторого исследования термин «Обновить токен», казалось, всплывал очень часто. Похоже, что более свежие версии ADAL больше не предоставляют токен физического обновления ; поэтому фактический токен обновления не может быть сохранен в какой-либо базе данных, а затем использован при входе в систему с устройств типа 2 или 3. Однако в той же статье также предполагается, что этот токен обновления теперь автоматически обрабатывается ADAL в кеше.
Я также нашел отличный пример кода , который реализует постоянный кеш ADAL Token в базе данных MSSQLLocalDB через Entity Framework.
По сути, моя идея заключается в следующем:
- Используйте OpenIDConnect, чтобы выполнить аутентификацию в первый раз с
имя пользователя и пароль и сохраните TokenCache внутри локальной базы данных
- При следующем входе без имени пользователя и пароля ,
получить сохраненный токен кеша из локальной базы данных и использовать
- AcquireTokenSilentAsync для входа в систему и ADAL обрабатывает обновление
логика токенов для меня, как в сценарии с кэш-памятью.
Теперь я не уверен, что моя попытка обойти это (выше), по крайней мере, на правильном пути (наведите меня :)!), Но я заметил, что tenantID, SignedInUserID и UserObjectID используются в следующем фрагменте все извлекаются при первой успешной аутентификации, что побудило меня по крайней мере попробовать ее.
Dim clientcred As ClientCredential = New ClientCredential(aadClientId, aadAppKey)
Dim authenticationContext As AuthenticationContext = New AuthenticationContext(aadInstance & tenantId, New ADALTokenCache(SignedInUserID))
Dim authenticationResult As AuthenticationResult = Await authenticationContext.AcquireTokenSilentAsync(aadGraphResourceID, clientcred, New UserIdentifier(UserObjectID, UserIdentifierType.UniqueId))
Примечание: ADALTokenCache - это конструктор пользовательского класса ADALTokenCache, который обрабатывает сохранение TokenCache внутри локальной базы данных.
Итак, я сохранил эти 3 значения в своей системной базе данных, а затем при входе в систему со смарт-карты извлекаю их по имени пользователя, а затем использую AcquireTokenSilentAsync, как показано выше.
Я реализовал это решение и у меня есть несколько вопросов -
1) Кажется, что постоянный токен получен из локальной базы данных, и кажется, что объект authenticationResult действительно получает правильные значения; токен доступа, токен id и информация о пользователе! Тем не менее, похоже, что это не подтверждает подлинность меня / регистрирует меня. Request.IsAuthenticated остается ложным, и я не знаю, что делать дальше. Процесс неправильный или мне нужно сделать что-то еще?
2) Похоже, что для authenticationResult указана дата истечения срока действия, которая всегда составляет 1 час с момента создания исходного токена. Это похоже на фактическое время истечения токена доступа, но ничего, связанного с истечением срока действия токена обновления, не видно в любом объекте, связанном с ADAL! Так что это довольно сложная ситуация.
3) ADAL говорит, что токены обновления обрабатываются в кеше автоматически. Но нужно ли что-то настраивать со стороны конфигурации Azure AD? Я не нашел ничего, связанного с настройкой токена обновления или сведений об истечении срока его действия на портале Azure.