Веб-вход с помощью OpenID Connect в Azure Active Directory B2C

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

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

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

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

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

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

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

• {tenant} с именем арендатора.
• 00001111-aaaa-2222-bbbb-3333cccc4444 с идентификатором приложения, зарегистрированного в арендаторе.
• {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=00001111-aaaa-2222-bbbb-3333cccc4444
&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

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

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

Azure AD B2C имеет конечную точку метаданных OpenID Connect, которая позволяет приложению получать сведения о Azure AD B2C во время выполнения. Эта информация включает точки подключения, содержимое токенов и ключи подписи токенов. Существует документ метаданных JSON для каждого потока пользователя в клиенте B2C. Например, документ метаданных для пользовательского потока 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 Connect, можно использовать открытые ключи RSA 256 для проверки подписи токена удостоверения. На этой конечной точке может быть указано несколько ключей, каждый из которых подтверждается утверждением kid. Заголовок токена идентификатора также содержит kid утверждение, указывающее, какой из этих ключей использовался для подписи токена идентификатора.

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

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

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

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

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

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

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

Если вам нужно, чтобы веб-приложение выполняло только потоки пользователей, можно пропустить следующие несколько разделов. Эти разделы применимы только к веб-приложениям, которые должны выполнять прошедшие проверку подлинности вызовы к веб-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=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

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

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 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=00001111-aaaa-2222-bbbb-3333cccc4444
&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": "00001111-aaaa-2222-bbbb-3333cccc4444 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.

Чтобы выйти из учетной записи пользователя, перенаправьте пользователя по адресу, указанному в документе метаданных 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 аннулирует сеанс на основе файлов cookie Azure AD B2C и пытается выйти из систем федеративных поставщиков удостоверений. Дополнительные сведения см. в разделе "Единый выход".

Обезопасьте перенаправление после выхода

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