Блог

Главная - Вопросы по программированию - БЕЗОПАСНАЯ проверка подлинности стека с помощью потоков пользователей Azure AD B2C (или пользовательских политик) — кто-нибудь решил эту проблему?

БЕЗОПАСНАЯ проверка подлинности стека с помощью потоков пользователей Azure AD B2C (или пользовательских политик) — кто-нибудь решил эту проблему?

#azure #authentication #f# #azure-active-directory #safe-stack

Вопрос:

Простой, но открытый вопрос: кому-нибудь удалось подключить приложение БЕЗОПАСНОГО стека к Azure AD B2C, чтобы приглашенные пользователи (в клиенте B2C) могли входить в систему с помощью определенного потока пользователей или пользовательской политики?

Конкретный вопрос, который мог бы позволить мне замкнуть цикл в моем подходе: любая идея, почему приложение использует Microsoft.Идентичность.Веб для обработки аутентификации столкнется с этой плохо документированной ошибкой, и как ее решить? —

«Приложение с идентификатором <<Ugly_GUID><Ugly_GUID>> не может получить маркер идентификатора либо потому, что область openid не была указана в запросе, либо приложение не авторизовано для этого».

Подробная информация о моих неудачных попытках до сих пор: С некоторыми изменениями я смог следовать серии из двух частей Райана Палмера, чтобы принудительно выполнить проверку подлинности Azure AD для моего приложения SAFE Stack (v3, .NET 5) :

Это приводит к поведению, при котором мой реальный логин Azure предоставляет мне доступ к приложению. Но цель состоит в том, чтобы включить поток пользователей (или пользовательскую политику, что бы ни работало), чтобы пользователи, авторизованные в моем клиенте Azure AD B2C, могли проходить проверку подлинности и использовать приложение. С настройками, подобными приведенным ниже (и многими другими вариантами) в appsettings.json, вызов URL-адреса приложения успешно перенаправляет поток пользователей для входа:

 "AzureAD":
{
    "Instance": "https://RoundTableExcaliburDev.b2clogin.com/",
    "Domain": "RoundTableExcaliburDev.onmicrosoft.com",
    "ClientId": "26e6d007-be46-4928-b06e-04acdbfd2913",
    "CallbackPath": "/api/login-callback",
    "SignedOutCallbackPath": "/api/logout-callback",
    "SignUpSignInPolicyId": "B2C_1A_SIGNUP_SIGNIN"
}

URI «b2clogin» (против login.microsoftonline.com в оригинале Райана Палмера) и идентификатор SignUpSignInPolicyId успешно вызывают нужный поток пользователей, и я могу войти (и/или зарегистрироваться) в качестве фиктивного пользователя, сохраненного в моем ресурсе Azure AD B2C. Но когда поток перенаправляется в мое приложение, я получаю ошибку «область действия openid», указанную выше.

Ошибка возникает как на локальном хосте, так и в версии, развернутой в экземпляре веб-приложения Azure, и возникает в Firefox, Chrome и Edge.

Дополнительные сведения о Azure AD B2C:

  • Я зарегистрировал веб-приложение с возвращаемыми URL-адресами https://<имя_приложения>.azurewebsites.net/api/login-callback и https://localhost:8080/api/login-callback
  • Права «Токены доступа» и «Идентификационные токены» были предоставлены в разделе аутентификации зарегистрированного приложения B2C.
  • Зарегистрированное приложение имеет секрет (не сертификат), но я нигде не использовал это значение, и ни в одной документации, которую я еще видел, не указано, где оно будет использоваться.
  • В отсутствие проверки подлинности приложение SAFE Stack работает должным образом на локальном хосте и в Azure.

Ответ №1:

Ну, я нашел волшебную кнопку «исправить все» для моей проблемы, но я не знаю, зачем это было необходимо. При создании регистрации приложения в Azure AD B2C (процесс, который я повторил несколько раз), я установил флажок «Предоставить согласие администратора на openid и разрешения на автономный доступ» в соответствии с инструкциями здесь и в других местах. В представлении «Разрешения API» в зарегистрированном приложении разрешения отображаются в разделе «Microsoft Graph» как «offline_access» и «openid». Несмотря на то, что эти разрешения уже были предоставлены, моя проблема исчезла, когда я нажал «Предоставить согласие администратора для [имя приложения]» и подтвердил (повторное)предоставление.

Учитывая, что в моем неясном сообщении об ошибке упоминались разрешения в «области openid», и учитывая, что я больше ничего не делал между предыдущим сбоем и последующим успехом, я не сомневаюсь, что это было решением, но я не понимаю, почему это было необходимо.

Метки: