Вход в веб-приложения с помощью OpenID Connect — Azure Active Directory B2C

Статья
01/11/2024

OpenID Connect — это протокол проверки подлинности на основе OAuth 2.0, который можно использовать для безопасного входа пользователей в веб-приложения. С помощью реализации OpenID Подключение Azure Active Directory B2C (Azure AD B2C) вы можете аутсорсинг регистрации, входа и других возможностей управления удостоверениями в веб-приложениях в Идентификатор Microsoft Entra. В этом руководстве показано, как это сделать (независимо от языка программирования). и описывает, как отправлять и получать сообщения HTTP, не используя ни одну из наших библиотек с открытым исходным кодом.

Примечание.

Большинство библиотек проверки подлинности с открытым исходным кодом получают и проверяют маркеры JWT для вашего приложения. Мы рекомендуем изучить различные библиотеки, а не реализовывать логику в своем коде. Дополнительные сведения см. в статьях Обзор библиотеки проверки подлинности Майкрософт (MSAL) и Библиотеки веб-аутентификации Microsoft Identity.

OpenID Connect расширяет возможности протокола авторизации OAuth 2.0 и позволяет использовать его в качестве протокола проверки подлинности, Этот протокол проверки подлинности позволяет выполнять единый вход. В этом протоколе вводится понятие токена идентификации. Это токен безопасности, который позволяет клиенту выполнять идентификацию пользователя и получать основные сведения о профиле пользователя.

OpenID Подключение также позволяет приложениям безопасно получать маркеры доступа. Маркеры доступа можно использовать для доступа к ресурсам, защищенным сервером авторизации. Мы рекомендуем Подключение OpenID, если вы создаете веб-приложение, размещенное на сервере, и обращаетесь через браузер. Дополнительные сведения о маркерах см. в статье с обзором маркеров в Azure Active Directory B2C

В Azure AD B2C стандартный протокол OpenID Connect выходит за рамки простой проверки подлинности и авторизации. В нем появляется параметр потока пользователя, который позволяет использовать OpenID Connect для добавления в ваше приложение таких возможностей пользовательского интерфейса, как регистрация, вход и управление профилями.

Отправка запросов проверки подлинности

Если веб-приложению требуется проверить подлинность пользователя и выполнить рабочий процесс пользователя, оно может направить его к конечной точке /authorize. Пользователь предпринимает действие в зависимости от потока пользователя.

В этом запросе клиент указывает разрешения, которые необходимо получить от пользователя в параметре scope, и поток пользователя, который нужно выполнить. Чтобы понять, как работает запрос, вставьте его в браузер и запустите. Замена:

{tenant} на имя вашего клиента.
90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 с идентификатором приложения, зарегистрированного в клиенте.
{application-id-uri}/{scope-name}с URI идентификатора приложения и область приложения, зарегистрированного в клиенте.
{policy} на имя политики, использующейся в клиенте, например b2c_1_sign_in.

GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com

client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345

Параметр	Обязательное поле	Описание
{tenant}	Да	Имя клиента Azure AD B2C. Если вы используете личный домен, укажите имя этого домена вместо `tenant.b2clogin.com`, например `fabrikam.com`.
{policy}	Да	Поток пользователя или политика, запущенная приложением. Укажите имя потока пользователя, создаваемого в клиенте Azure AD B2C. Например, `b2c_1_sign_in`, `b2c_1_sign_up`или `b2c_1_edit_profile`.
client_id	Да	Идентификатор приложения, который портал Azure назначил вашему приложению.
nonce	Да	Значение, включенное в запрос (созданное приложением), которое входит в состав полученного маркера идентификации в качестве утверждения. Затем приложение может проверить это значение, чтобы устранить атаки, направленные на воспроизведение маркеров. Это значение обычно представляет собой случайную уникальную строку, которую можно использовать для определения источника запроса.
response_type	Да	Необходимо включить маркер идентификации для OpenID Connect. Если веб-приложению также потребуются маркеры для вызова веб-API, вы можете использовать `code+id_token`.
область	Да	Список областей с разделителями-пробелами. Область `openid` определяет разрешение на вход пользователя и получение данных о пользователе в форме маркеров идентификации. Область `offline_access` для веб-приложений является необязательной. Оно указывает, что приложению нужен маркер обновления для расширенного доступа к ресурсам. Область `https://{tenant-name}/{app-id-uri}/{scope}` определяет разрешение для защищенных ресурсов, таких как веб-API. Дополнительные сведения см. в статье Запрос маркера доступа.
prompt	No	Тип необходимого взаимодействия с пользователем. Сейчас единственное допустимое значение — `login`, при котором пользователю приходится вводить учетные данные по запросу.
redirect_uri	Да	Параметр `redirect_uri` приложения, где сервер отправляет ответы проверки подлинности приложению. Он должен в точности соответствовать одному из параметров `redirect_uri`, зарегистрированных на портале Azure, но иметь форму закодированного URL-адреса.
response_mode	No	Метод, который используется для отправки полученного кода авторизации приложению. Это может быть `query`, `form_post` или `fragment`. Мы рекомендуем использовать режим отклика для оптимальной `form_post` безопасности.
state	No	Значение, которое можно включить в запрос, возвращаемое сервером авторизации в ответе маркера. Это может быть строка любого контента. Как правило, для предотвращения подделки межсайтовых запросовиспользуется генерируемое случайным образом уникальное значение. Этот параметр также включает информацию о состоянии пользователя в приложении перед созданием запроса на проверку подлинности (например, об открытой в тот момент странице). Если вы не хотите регистрировать несколько URL-адресов перенаправления на портале Azure, воспользуйтесь параметром `state` для разделения ответов различных запросов от службы Azure AD B2C в приложении.
login_hint	No	Можно использовать для предварительного заполнения поля имени входа на странице входа. Дополнительные сведения см. в разделе Предварительное заполнение имени для входа.
domain_hint	No	Предоставляет подсказку для Azure AD B2C о поставщике удостоверений в социальных сетях, который должен использоваться для входа в систему. Если включено допустимое значение, пользователь переходит непосредственно на страницу входа поставщика удостоверений. Дополнительные сведения см. в статье Перенаправление входа в поставщика социальных сетей.
Настраиваемые параметры	No	Пользовательские параметры, которые можно использовать с пользовательскими политиками. Например, URL-адрес динамического содержимого пользовательской страницы или сопоставитель утверждений "ключ — значение".

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

После завершения потока пользователя ответ возвращается в приложение по указанному redirect_uri параметру с помощью метода, указанного в параметре response_mode . Во всех вышеперечисленных случаях ответ будет одинаковым независимо от потока пользователя.

Успешный ответ с использованием метода response_mode=fragment выглядит следующим образом:

GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response

Параметр	Описание
id_token	Маркер идентификации, запрошенный приложением. Вы можете использовать маркер идентификации для проверки личности пользователя и запуска сеанса пользователя.
кодом	Запрашиваемый приложением код авторизации, если вы используете `response_type=code+id_token`. Приложение может использовать код авторизации для запроса маркера доступа к целевому ресурсу. Срок действия кодов авторизации обычно истекает через 10 минут.
state	Если запрос содержит параметр `state`, то в ответе должно отображаться то же значение. Приложение должно проверять идентичность значений `state` состояния в запросе и ответе.

Сообщения об ошибках также можно отправлять в параметр redirect_uri, чтобы приложение обрабатывало их должным образом:

GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response

Параметр	Описание
error	Код, который можно использовать для классификации типов возникающих ошибок.
error_description	Конкретное сообщение об ошибке, с помощью которого можно определить первопричину возникновения ошибки аутентификации.
state	Если запрос содержит параметр `state`, то в ответе должно отображаться то же значение. Приложение должно проверять идентичность значений `state` состояния в запросе и ответе.

Проверка маркера идентификации

Просто получение маркера идентификатора недостаточно для проверки подлинности пользователя. Проверьте подпись маркера идентификации и утверждения в маркере на соответствие требованиям приложения. В Azure AD B2C для подписи маркеров и проверки их правильности используются веб-маркеры JSON Web Token (JWT) и шифрование с открытым ключом.

Примечание.

Большинство библиотек проверки подлинности с открытым исходным кодом проверяют токены JWT для вашего приложения. Мы рекомендуем изучить различные библиотеки, а не реализовывать логику проверки самостоятельно. Дополнительные сведения см. в статьях Обзор библиотеки проверки подлинности Майкрософт (MSAL) и Библиотеки веб-аутентификации Microsoft Identity.

Azure AD B2C имеет конечную точку метаданных OpenID Connect, которая позволяет приложению получать сведения о Azure AD B2C во время выполнения. Эти сведения включают конечные точки, содержимое маркеров и ключи подписи маркеров. Для каждого потока пользователя в клиенте B2C есть собственный документ метаданных JSON. Например, документ метаданных для потока пользователя b2c_1_sign_in в fabrikamb2c.onmicrosoft.com находится в каталоге:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration

Одно из свойств этого документа конфигурации — jwks_uri, значение которого для точно такого же потока пользователя будет следующим:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys

Чтобы определить, какой поток пользователя использовался для подписи маркера идентификатора, у вас есть два варианта. Первый — имя потока пользователя включается в утверждение acr в маркере идентификации, см. утверждение, представляющее поток пользователя. Другой вариант — закодировать поток пользователя в значении параметра state при отправке запроса, а затем декодировать его, чтобы определить используемый поток. Каждый из этих методов является допустимым.

После получения документа метаданных из конечной точки метаданных OpenID Подключение можно использовать открытые ключи RSA 256 для проверки подписи маркера идентификатора. В этой конечной точке может находиться множество ключей, каждый из которых определяется утверждением kid. Заголовок маркера идентификации также содержит утверждение kid, указывающее на ключ, который был использован для подписывания маркера идентификации.

Чтобы проверить маркеры от Azure AD B2C, необходимо создать открытый ключ с помощью экспоненты (e) и модуля (n). Для этого необходимо узнать, как создать открытый ключ на выбранном языке программирования. Официальную документацию по созданию открытого ключа с помощью протокола RSA можно найти здесь: https://tools.ietf.org/html/rfc3447#section-3.1

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

Проверьте утверждение nonce во избежание атак с использованием воспроизведения маркеров. Его значение должно совпадать с указанным вами в запросе на вход.
Проверьте утверждение aud, чтобы убедиться, что для вашего приложения был выдан маркер идентификации. Это должен быть идентификатор приложения вашего приложения.
Проверьте утверждения iat и exp, чтобы убедиться, что срок действия маркера идентификации не истек.

Также существуют некоторые дополнительные проверки, которые необходимо выполнить. Проверки подробно описаны в спецификации OpenID Подключение Core. Также может потребоваться проверить больше утверждений в зависимости от вашего сценария. Ниже приведены некоторые из стандартных проверок:

Убедитесь, что пользователь или организация зарегистрировались в приложении.
Убедитесь, что у пользователя есть правильная авторизация или привилегии.
Убедитесь, что произошла определенная сила проверки подлинности, например многофакторная проверка подлинности Microsoft Entra.

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

Получение маркера

Если требуется, чтобы веб-приложение выполняло только потоки пользователей, можно пропустить несколько следующих разделов. Эти разделы применимы только к веб-приложениям, которые должны выполнять проверку подлинности вызовов к веб-API, защищенному Azure AD B2C.

Чтобы воспользоваться кодом авторизации маркера для необходимого ресурса (полученным с помощью response_type=code+id_token), отправьте запрос POST на конечную точку /token. В Azure AD B2C можно запросить маркеры доступа для других API обычным образом, указав их области в запросе.

Вы также можете запросить маркер доступа для собственного внутреннего веб-API приложения. В этом случае идентификатор клиента приложения используется в качестве запрошенного область, что приводит к маркеру доступа с таким идентификатором клиента в качестве аудитории:

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Параметр	Обязательное поле	Описание
{tenant}	Да	Имя клиента Azure AD B2C
{policy}	Да	Поток пользователя, который использовался для получения кода авторизации. В этом запросе нельзя использовать другой поток пользователя. Добавьте этот параметр в строку запроса, а не в тело сообщения POST.
client_id	Да	Идентификатор приложения, который портал Azure назначил вашему приложению.
client_secret	Да, в веб-приложениях	Секрет приложения, созданный на портале Azure. Секреты клиента используются в этом потоке для сценариев веб-приложений, где клиент может безопасно хранить секрет клиента. В сценариях машинного приложения (общедоступного клиента) секреты клиента не могут быть безопасно сохранены, поэтому не используются в этом потоке. При использовании секрета клиента периодически изменяйте его.
кодом	Да	Код авторизации, полученный в начале потока пользователя.
grant_type	Да	Тип предоставления. Для потока кода авторизации это должен быть тип `authorization_code`.
redirect_uri	No	Параметр `redirect_uri` приложения, в котором вы получили код авторизации.
область	No	Список областей с разделителями-пробелами. Область `openid` определяет разрешение на вход пользователя и получение данных о пользователе в форме маркеров идентификации. Ее можно использовать для получения маркеров для веб-API серверной части приложения, идентификатор приложения которого совпадает с идентификатором приложения клиента. Область `offline_access` означает, что вашему приложению потребуется маркер обновления для продолжительного доступа к ресурсам.

Успешный ответ маркера выглядит следующим образом:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "expires_on": "1644254945",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

Параметр	Описание
not_before	Эпоха, в которой маркер становится допустимым.
token_type	Значение типа маркера. `Bearer` — единственный поддерживаемый тип.
access_token;	Подписанный маркер JWT, который вы запрашивали.
область	Допустимые область для маркера.
expires_in	Срок действия маркера доступа (в секундах).
expires_on;	Эпоха, когда маркер доступа становится недействительным.
refresh_token	Маркер обновления OAuth 2.0. Приложение может использовать этот маркер для получения дополнительных маркеров после истечения срока действия текущего маркера. Маркеры обновления можно использовать, чтобы надолго сохранять доступ к ресурсам. Для получения маркера обновления необходимо использовать область `offline_access` как в запросе авторизации, так и в запросе маркера.

Сообщения об ошибках выглядят следующим образом:

{
    "error": "invalid_grant",
    "error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}

Параметр	Описание
error	Код, который можно использовать для классификации типов произошедших ошибок.
error_description	Сообщение, которое может помочь определить основную причину ошибки проверки подлинности.

Использование маркера

После успешного получения маркера доступа можно использовать маркер в запросах к внутренним веб-API, включив его в Authorization заголовок:

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

Обновление маркера

Срок действия маркеров доступа и маркеров идентификации крайне мал. Для сохранения доступа к ресурсам маркеры с истекшим сроком действия необходимо обновлять. При обновлении маркера доступа Azure AD B2C возвращает новый маркер. Обновленный маркер доступа обновит значения утверждений nbf (не раньше), iat (выдан в) и exp (истечение срока действия). Все остальные значения утверждений похожи на значения в предыдущем маркере доступа.

Обновите маркер, отправив еще один запрос POST в конечную точку /token. На этот раз укажите параметр refresh_token вместо параметра code:

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Параметр	Обязательное поле	Описание
{tenant}	Да	Имя клиента Azure AD B2C
{policy}	Да	Поток пользователя, который использовался для получения исходного маркера обновления. В этом запросе нельзя использовать другой поток пользователя. Добавьте этот параметр в строку запроса, а не в тело сообщения POST.
client_id	Да	Идентификатор приложения, который портал Azure назначил вашему приложению.
client_secret	Да, в веб-приложениях	Секрет приложения, созданный на портале Azure. Секреты клиента используются в этом потоке для сценариев веб-приложений, где клиент может безопасно хранить секрет клиента. В сценариях машинного приложения (общедоступного клиента) секреты клиента не могут быть безопасно сохранены, поэтому не используются для этого вызова. При использовании секрета клиента следует периодически менять его.
grant_type	Да	Тип предоставления. Для этого участка потока кода авторизации это должен быть тип `refresh_token`.
refresh_token	Да	Исходный маркер обновления, полученный во второй части последовательности. Для получения маркера обновления необходимо использовать область `offline_access` как в запросе авторизации, так и в запросе маркера.
redirect_uri	No	Параметр `redirect_uri` приложения, в котором вы получили код авторизации.
область	No	Список областей с разделителями-пробелами. Область `openid` определяет разрешение на вход пользователя и получение данных о пользователе в форме маркеров идентификации. Ее можно использовать для отправки маркеров для веб-API серверной части приложения, идентификатор приложения которого совпадает с идентификатором приложения клиента. Область `offline_access` означает, что вашему приложению потребуется маркер обновления для продолжительного доступа к ресурсам.

Успешный ответ маркера выглядит следующим образом:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
    "refresh_token_expires_in": "1209600"
}

Параметр	Описание
not_before	Эпоха, в которой маркер становится допустимым.
token_type	Значение типа маркера. `Bearer` — единственный поддерживаемый тип.
access_token;	Подписанный маркер JWT, который вы запрашивали.
область	Допустимые область для маркера.
expires_in	Срок действия маркера доступа (в секундах).
refresh_token	Маркер обновления OAuth 2.0. Приложение может использовать этот маркер для получения дополнительных маркеров по истечении срока действия текущего маркера. Маркеры обновления можно использовать, чтобы надолго сохранять доступ к ресурсам.
refresh_token_expires_in	Срок действия маркера обновления (в секундах).

Сообщения об ошибках выглядят следующим образом:

{
    "error": "invalid_grant",
    "error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}

Параметр	Описание
error	Код, который можно использовать для классификации типов произошедших ошибок.
error_description	Сообщение, которое может помочь определить основную причину ошибки проверки подлинности.

Отправка запроса на выход

Для выхода пользователя из приложения недостаточно очистить файлы cookie или каким-то другим образом завершить сеанс пользователя. Перенаправьте пользователя в Azure AD B2C для выхода. Если этого не сделать, пользователь может выполнить повторную проверку подлинности в приложении без повторного ввода учетных данных. Дополнительные сведения см. в разделе о поведении сеанса Azure AD B2C.

Чтобы выйти из учетной записи пользователя, перенаправьте пользователя на end_session_endpoint, которая указана в документе метаданных OpenID Connect, описанном ранее:

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F

Параметр	Обязательное поле	Описание
{tenant}	Да	Имя клиента Azure AD B2C. Если вы используете личный домен, укажите имя этого домена вместо `tenant.b2clogin.com`, например `fabrikam.com`.
{policy}	Да	Поток пользователя, указанный в запросе авторизации. Например, если пользователь вошел в систему с потоком пользователя `b2c_1_sign_in`, укажите `b2c_1_sign_in` в запросе на выход.
id_token_hint	No	Ранее выданный маркер идентификатора для передачи в конечную точку выхода в качестве подсказки о текущем сеансе проверки подлинности конечного пользователя с клиентом. `id_token_hint` гарантирует, что `post_logout_redirect_uri` представляет собой зарегистрированный URL-адрес ответа в ваших параметрах приложения Azure AD B2C. Дополнительные сведения см. в разделе Защита перенаправления выхода.
client_id	Нет*	Идентификатор приложения, который портал Azure назначил вашему приложению. Это необходимо при использовании `Application` конфигурации изоляции единого входа и параметра Требовать маркер идентификатора* в запросе на выход, направленном в `No`.
post_logout_redirect_uri	No	URL-адрес, по которому необходимо перенаправить пользователя после успешного выхода. Если он не указан, Azure AD B2C показывает пользователю универсальное сообщение. Если вы не указали `id_token_hint`этот URL-адрес, этот URL-адрес не следует зарегистрировать в качестве URL-адреса ответа в параметрах приложения Azure AD B2C.
state	No	Если включить `state` параметр в запрос авторизации, сервер авторизации возвращает то же значение в ответе `post_logout_redirect_uri`. Приложение должно убедиться, что `state` значение в запросе и ответе идентичны.

При запросе на выход Azure AD B2C делает недействительным сеанс Azure AD B2C на основе файла cookie и пытается выйти из федеративных поставщиков удостоверений. См. сведения о едином выходе.

Защита перенаправления выхода

После выхода пользователь перенаправляется в URI, указанный в параметре post_logout_redirect_uri , независимо от URL-адресов ответа, указанных для приложения. Однако если передано допустимое значение id_token_hint, и включен параметр Требовать токен идентификатора в запросах выхода, Azure AD B2C проверяет, соответствует ли значение post_logout_redirect_uri одному из настроенных URI перенаправления приложения перед выполнением перенаправления. Если для приложения не настроен соответствующий URL-адрес ответа, отображается сообщение об ошибке и пользователь не перенаправляется.

Сведения о задании требуемого маркера идентификации в запросах выхода см. в разделе Настройка поведения сеанса в Azure Active Directory B2C.

Следующие шаги

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

Вход в веб-приложения с помощью OpenID Connect в Azure Active Directory B2C