URI ответа для Azure AD B2C возвращает 404, пользовательский поставщик удостоверений OpenID

Мы внедряем настраиваемый поставщик удостоверений для Azure AD B2C с использованием варианта протокола OpenID в качестве универсального OpenID Connect.

Все работает должным образом, пока не придет время отправить ответ обратно в Azure AD B2C с помощью предоставленного URI перенаправления. Я нашел документацию, касающуюся ожидаемой структуры этого URL-адреса ответа, и то, что мы видим в документации, идентично тому, что указывает Azure AD B2C при выдаче последовательности проверки подлинности.

Настроенные значения: Тип ответа: код Режим ответа: form_post Заявка на идентификатор пользователя: sub Заявка на отображаемое имя: name

Когда пользовательский поставщик удостоверений GET или POST отправляет ответ (код) проверки подлинности обратно на https://REDACTED.b2clogin.com/REDACTED.onmicrosoft.com/oauth2/authresp, Azure B2C возвращает 404.

Заметьте, это не 400, не 401, не 403, не 5хх. Это именно 404 (не найдено) с основным текстовым (не HTML) содержимым, говорящим, что ресурс не найден. Этот ответ очень похож на неправильно настроенный уровень управления API на стороне Azure, который указывает неправильный внутренний URL-адрес.

Мы ожидаем, что URL-адрес https://REDACTED.b2clogin.com/REDACTED.onmicrosoft.com/oauth2/authresp действительно работает. Это похоже на ожидаемую конечную точку ответа Azure AD B2C из документации, а также то, что сам Azure AD B2C указывает при инициации последовательности OpenID с помощью нашего пользовательского веб-приложения поставщика удостоверений.

До сих пор нам не удалось найти основную причину или даже какую-либо полезную информацию, кроме необработанных журналов сетевых запросов (обращение в службу поддержки Microsoft было открыто с 23 января 2023 г.). Последним средством может быть повторное создание арендатора B2C, так как эта функция, кажется, работает для других людей, но это потребует миграции и значительного времени простоя с нашей стороны.

РЕШЕНИЕ. В ответе на конечную точку авторизации AD B2C отсутствовало утверждение «nonce» (в полезной нагрузке id_token) и параметр «state» в HTTP-запросе. Оба значения предоставляются AD B2C при инициации авторизации. Как только пользовательский поставщик удостоверений начал правильно добавлять эти два значения, ошибка 404 исчезла.

Для меня URI перенаправления https://myb2ctenant.b2clogin.com/myb2ctenant.onmicrosoft.com‌​/oauth2/authresp работает с настройкой Azure AD в качестве поставщика удостоверений OpenID Connect Connect.

juunas 23.01.2023 09:09

Я подозреваю, что это могло быть вызвано недавней миграцией, которую мы выполняли с ресурсами в соседней подписке. Однако, что бы это ни было, было бы здорово иметь способ положительно подтвердить причину.

Roman Polunin 23.01.2023 21:20

Вы не можете открыть дело с Microsoft?

Skin 07.02.2023 06:18

Дело с Microsoft было открыто пару недель назад, и там произошло много взаимодействий. К сожалению, поддержка до сих пор не пошла дальше сбора необработанных входных данных, таких как сетевые трассировки, скриншоты, репродукции и живые демонстрации экрана.

Roman Polunin 08.02.2023 17:38

Просто для подтверждения: у вас есть правильное имя политики в URL-адресе ответа в ваших трассировках? Итак authresp?p=B2C_1.... Потому что, если имя политики отсутствует или неверно, вы можете сразу получить эту ошибку 404. Вот почему мы используем политику как часть пути https://myb2ctenant.b2clogin.com/myb2ctenant.onmicrosoft.com‌​/b2c_1a_signin/oauth‌​2/authresp с нашим настраиваемым провайдером openID, с ним гораздо меньше проблем.

Alex AIT 09.02.2023 20:44

У нас нет имени политики в URI ответа. Сейчас я попытаюсь вставить имя политики, чтобы посмотреть, поможет ли это.

Roman Polunin 10.02.2023 00:23

Чтобы уточнить, в документации говорится, что имя политики должно быть только в запросе инициации к самому B2C, а параметр redirect_uri, отправляемый в наше пользовательское приложение IdP, не имеет имени политики. Я все равно сейчас попробую.

Roman Polunin 10.02.2023 00:34

Пробовал четыре варианта: 1) добавление имени политики непосредственно перед /oauth2/authresp в исходном имени политики в смешанном регистре, 2) то же, что и № 1, но все в нижнем регистре, 3) добавление имени политики в качестве строки запроса ?p=XXXX в исходном смешанном регистре при использовании Метод POST, 4) такой же, как № 3, но с использованием метода GET, поэтому «код» также входит в строку запроса. Все заканчивается общим сообщением «Произошло исключение», возвращаемым в клиентское приложение, и ошибкой «Служба получила неверный запрос» в журнале аудита B2C. P.S: Я не просто переключил POST на GET - еще и поправил настройку в настройках Idp.

Roman Polunin 10.02.2023 01:31

Кстати, служба поддержки Azure уведомила нас о том, что наш запрос поступил в группу разработки продукта, так что, скрестив пальцы, кто-то там даст нам авторитетный ответ.

Roman Polunin 10.02.2023 01:32

По крайней мере, эти "исключения произошли" указывают мне, что вы ближе к успеху. У нас он работает с IdentityServer с политикой в ​​пути. Не уверен, как я мог бы помочь дальше. Будет интересно услышать, если это будет окончательно решено, удачи.

Alex AIT 10.02.2023 17:02

Верно. Я пытался ввести имя политики в URI ответа на очень раннем этапе разработки, попал в ту же ситуацию и отказался от нее. Похоже, имеет смысл углубиться в устранение неполадок, используя этот подход.

Roman Polunin 10.02.2023 18:31
Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
В предыдущей статье мы завершили установку базы данных, для тех, кто не знает.
Как установить LAMP Stack 1/2 на Azure Linux VM
Как установить LAMP Stack 1/2 на Azure Linux VM
В дополнение к нашему предыдущему сообщению о намерении Azure прекратить поддержку Azure Database для MySQL в качестве единого сервера после 16...
0
11
218
3
Перейти к ответу Данный вопрос помечен как решенный

Ответы 3

Я попытался воспроизвести сценарий в своей среде: Убедитесь, что конечная точка, для которой я запросил URL-адрес авторизации

Он включает в себя политику и с URI перенаправления = https://kavyasarabojub2c.b2clogin.com/kavyasarabojub2c.onmicrosoft.com/oauth2/authresp

User Flow относится к SignupSignin, а не только к Signin

Не забудьте включить все необходимые разрешения API, особенно обязательно включите openid , profile

Я настраиваю idp таким образом, чтобы userId сопоставлялся с oid.

URL-адрес авторизации должен включать политику.

Здесь у меня установлена ​​политика B2C_1_SignupSignin для пользовательского потока.

URI перенаправления = https://kavyasarabojub2c.b2clogin.com/kavyasarabojub2c.onmicrosoft.com/oauth2/authresp

URL-адрес авторизации:

https://kavyasarabojub2c.b2clogin.com/kavyasarabojub2c.onmicrosoft.com/oauth2/v2.0/authorize?p=B2C_1_newSignupSignin&client_id=xxx&nonce=defaultNonce&redirect_uri=https%3A%2F%2Fxxxb2c.b2clogin.com%2Fxxxb2c.onmicrosoft. com%2Foauth2%2Fauthresp&scope=openid&response_type=id_token&prompt=login

Когда область профиля не указана, я получил неверный запрос

Но когда включены openid и profile вместе с Directory.Read.All разрешениями API, запрос выполняется успешно.

Примечание: URL-адрес метаданных должен быть: https://login.microsoftonline.com/<tenantId>/v2.0/.well-known/openid-configuration

Успешно вошли в систему и получили токен, содержащий idp_access_token

Маркер доступа поставщика удостоверений расшифрован и получен от пользователя:

Спасибо за подробный репортаж. К сожалению, это не относится к нашему случаю, так как ошибка 404, а не 400. Я полагаю, что другие точки данных соответствуют вашему сценарию. УДАЛЕНО.b2clogin.com/УДАЛЕНО.onmicrosoft.com/oauth2/v2.0/…

Roman Polunin 04.02.2023 19:11

@Roman Polunin Можете ли вы предоставить журналы ошибки 404, которые вы получили, и еще несколько подробностей, таких как проблема с брандмауэром или что-то для расследования, поскольку я не сталкивался с ошибкой 404 с заданными перенаправлениями.

kavyaS 08.02.2023 12:39

Кавья, подробные трассировки содержат некоторую относительно конфиденциальную информацию, которую я должен тщательно очистить, прежде чем опубликовать здесь. Я надеялся увидеть ответ, который укажет мне, как устранить эту ошибку 404 на конечной точке authresp самостоятельно или во время работы с поддержкой MS в режиме реального времени. Я не ожидаю, что пользователи SO смогут дать мне точный ответ.

Roman Polunin 08.02.2023 17:43
Ответ принят как подходящий

Ответ должен включать предоставленный одноразовый номер в качестве утверждения внутри полезной нагрузки id_token и предоставленное состояние в качестве параметра HTTP-запроса или строки запроса.

https://openid.net/specs/openid-connect-basic-1_0.html

У меня была та же проблема (ошибка 404 в результате POST /authresp от моего пользовательского IdP OIDC обратно в Azure AD B2C с использованием URI перенаправления, который Azure AD B2C только что предоставил в качестве параметра запроса в запросе /authorize к моему IdP: redirect_uri=https://mytenant.b2login.com/mytenant.onmicrosoft.com/oauth2/authresp

В моем случае (с использованием неявного потока) речь шла о правильной обработке параметра запроса «одноразовый номер» во входящем запросе /авторизации (от Azure AD B2C к моему поставщику удостоверений) путем обеспечения того, чтобы сгенерированный id_token, который он возвращал, включал одноразовый номер в качестве утверждения.

В вашем случае (используя поток кода авторизации... и предполагая, что вы также возвращаете id_token на основе возвращаемых вами утверждений "sub" и "name"), ваша конечная точка /token должна включать одноразовый номер внутри id_token.. .so распространите одноразовый номер (и состояние) в качестве параметров запроса на вашу конечную точку /token с помощью используемого вами метода перенаправления /authorize to /token.

Если федеративный IdP не включает одноразовый номер в качестве утверждения в полезные данные id_token, которые он возвращает, Azure AD B2C вернет ошибку 404 из запроса /authresp.

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

В спецификации OpenID Connect описание nonce (под IDToken) гласит (жирным шрифтом выделено мной):

Строковое значение, используемое для связывания сеанса клиента с токеном идентификатора и для смягчения атак воспроизведения. Значение передается без изменений из запроса аутентификации в токен идентификатора. Клиенты, если они присутствуют в токене идентификатора, ДОЛЖНЫ убедиться, что значение утверждения одноразового номера равно значению параметра одноразового номера, отправленному в запросе аутентификации. При наличии в запросе аутентификации серверы авторизации ДОЛЖНЫ включать утверждение одноразового номера в токен идентификатора, при этом значение утверждения является значением одноразового номера, отправленным в запросе аутентификации. Серверы авторизации НЕ ДОЛЖНЫ выполнять никакую другую обработку используемых значений nonce. Значение nonce является строкой с учетом регистра.

Хотя спецификация указывает, что одноразовый номер является необязательным, Microsoft следует передовым методам, предоставляя его... и поскольку Azure AD B2C (как сервер авторизации) получает id_token от IdP, для игры по тому же правилу требуется федеративный OIDC IdP. .

Если это поможет другим, конечная точка /.well-known/openid-configuration моего пользовательского IdP возвращает:

 {
  "authorization_endpoint": "https://myidp.azurewebsites.net/oauth2/authorize",
  "authorization_response_iss_parameter_supported": true,
  "claims_parameter_supported": false,
  "claims_supported": [
    "aud",
    "idp",
    "iss",
    "iat",
    "exp",
    "nonce",
    "s-hash",
    "sid",
    "sub",
    "auth_time",
    "email",
    "family_name",
    "given_name",
    "locale",
    "name",
    "updated_at",
    "user_id"
  ],
  "claim_types_supported": ["normal"],
  "grant_types_supported": ["implicit"],
  "id_token_signing_alg_values_supported": ["RS256"],
  "issuer": "https://myidp.azurewebsites.net",
  "jwks_uri": "https://myidp.azurewebsites.net/oauth2/jwks",
  "response_modes_supported": ["form_post"],
  "response_types_supported": ["id_token"],
  "scopes_supported": ["openid"]
}

(Да, мой IdP работает на сервере приложений Azure... но "myidp" не является моим настоящим именем клиента.)

p.s. В настоящее время мой IdP используется исключительно в федерации с AzureAD B2C (который действует как сервер авторизации для моего клиентского приложения через библиотеку MSAL), поэтому мой IdP просто поддерживает только неявный поток и три конечные точки (/.well-known/openid -configuration, /jwks и /authorize). Если бы это был IdP общего назначения или разрешались прямые клиентские запросы, он поддерживал бы другие потоки (например, поток кода авторизации), дополнительные области действия (помимо «openid»… например, «профиль») и дополнительные конечные точки (например, /token и /информация о пользователе). Однако, независимо от потока, пока возвращается id_token, он должен включать одноразовый номер в свою полезную нагрузку.

Теперь проведем диагностику содержимого токена. Я также проверил, что другой экземпляр B2C возвращает ту же ошибку 404 с моим настраиваемым IdP, поэтому причиной, вероятно, является мой настраиваемый IdP.

Roman Polunin 14.02.2023 02:31

Таким образом, вы были правы, предположив, что мой id_token не имеет одноразового значения. К сожалению, изменив конечную точку, чтобы включить одноразовое утверждение в полезную нагрузку токена, authresp B2C по-прежнему возвращает 404. Ответ, отправленный в B2C, содержит единственный параметр «id_token», а тип содержимого запроса — «application/x-www-form-urlencoded». '. Можете ли вы прикрепить полный список имен утверждений, которые ваш собственный IDP включает в id_token? P.S.: это решение также предназначено исключительно для интеграции с B2C.

Roman Polunin 14.02.2023 04:04

Итак, последней недостающей частью был отсутствующий параметр состояния. B2C посылает ему запрос на авторизацию. Как только я правильно вернул и nonce, и состояние, 404 ушел.

Roman Polunin 14.02.2023 06:47

Я рад, что смог помочь!... и спасибо за дополнительную информацию о "состоянии". Я только что провел еще один тест и могу подтвердить, что возврат состояния также является обязательным (иначе вы получите 404). Одноразовый номер входит в id_token, но состояние возвращается как параметр запроса (можно включить утверждение s_hash в id_token, которое является хэшем состояния, но я не включаю это утверждение в свой id_token).

puckdangler 15.02.2023 03:12

Да, большое спасибо за подсказку, решение готово. Кстати, поддержка Azure все еще висит и тянет время — и мы используем платный уровень. Интересно, придут ли они когда-нибудь с какой-либо значимой рекомендацией по нашему билету, и, к счастью, нас уже не волнует, будут ли они это делать.

Roman Polunin 16.02.2023 18:55

Чтобы устранить проблему, я бы рекомендовал следующие шаги:

  1. Убедитесь, что используемый вами URI перенаправления правильный и соответствует указанный Azure AD B2C.

  2. Убедитесь, что тип ответа и режим ответа, указанные в вашем пользовательский поставщик удостоверений соответствует значениям, ожидаемым Azure AD B2C.

  3. Убедитесь, что претензии, которые вы отправляете в ответе (например, "sub" и "имя") соответствуют ожидаемому формату и значениям для Azure AD B2C.

  4. Проверьте журналы сетевых запросов на наличие дополнительной информации, которая может помочь определить проблему.

  5. Если возможно, попытайтесь изолировать проблему, проверив аутентификацию поток с минимальной конфигурацией, чтобы определить, является ли проблема с вашим настраиваемым поставщиком удостоверений или с Azure AD B2C.

Если проблема не устранена после выполнения этих шагов, вы можете обратиться в службу поддержки Microsoft за дополнительной помощью.

Другие вопросы по теме