#asp.net-mvc #openid-connect #azure-ad-b2c
#asp.net-mvc #OpenID-подключение #azure-ad-b2c
Вопрос:
У меня есть asp.net Приложение MVC, которое использует Azure AD B2C для аутентификации пользователей.
До сих пор мы использовали только встроенные потоки пользователей для регистрации и входа, но теперь я создал пользовательский поток для определенного сценария. Я использовал этот документ «Начало работы» для пользовательского потока: https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-get-started
Моя проблема в том, что токены, сгенерированные встроенными потоками, подписаны другим ключом, чем токены, сгенерированные новым пользовательским потоком.
В startup.cs я ссылаюсь на MetaDataAddress для встроенного потока по умолчанию (в котором есть ссылка на ключи подписи)
app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
{
MetadataAddress = https://contoso.b2clogin.com/contoso.onmicrosoft.com/[built-in-flow]/v2.0/.well-known/openid-configuration,
}
При проверке нового пользовательского токена потока он должен соответствовать не ключу в адресе метаданных, определенном выше, а другому ключу подписи.
Как я могу убедиться, что токен правильно проверен как для встроенных, так и для пользовательских потоков? Или как я могу убедиться, что токены, созданные в пользовательских и встроенных потоках, используют один и тот же ключ подписи.
Комментарии:
1. Как насчет добавления инструкции IF для установки metadataAddress на основе идентификатора политики? Вы не можете заставить их использовать один и тот же ключ подписи.
Ответ №1:
Не поддерживается бесшовная работа между потоками пользователей и пользовательскими политиками. В пользовательской политике вызывается технический профиль управления сеансами — подробнее о техническом профиле. Или посетите здесь, чтобы ознакомиться с различными управлениями сеансами. Для соединения ключей между двумя решениями нет UX.
Приложение, вызывающее Azure AD B2C (конечную точку входа), также отличается, поскольку оно должно явно указывать необходимость добавления идентификатора политики при отправке запроса в конечную точку Azure AD B2C.
Наиболее распространенные сценарии, которые я видел, используют сочетание пользовательского потока и пользовательской политики:
- Использование пользовательского потока для потока сброса пароля и пользовательской политики с помощью SUSI (вход при регистрации)
- Развертывание в разных отделах, которые работают независимо (единый вход между ними никогда не требуется)