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

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

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

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

После завершения потока пользователя ответ возвращается в приложение по указанному 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

Сообщения об ошибках также можно отправлять в параметр 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

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

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

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

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

{
    "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...",
}

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

{
    "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"
}

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

После успешного получения маркера доступа можно использовать маркер в запросах к внутренним веб-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

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

{
    "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"
}

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

{
    "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",
}

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

Для выхода пользователя из приложения недостаточно очистить файлы 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

При запросе на выход 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.