Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Это важно
Начиная с 1 мая 2025 г. Azure AD B2C больше не будет доступен для приобретения для новых клиентов. Дополнительные сведения см. в разделе "Вопросы и ответы".
Во многих современных приложениях есть интерфейс одностраничного приложения (SPA), написанный главным образом на JavaScript. Часто приложение записывается с помощью платформы, например React, Angular или Vue.js. SpAs и другие приложения JavaScript, которые выполняются в основном в браузере, имеют некоторые дополнительные проблемы для проверки подлинности:
Характеристики безопасности этих приложений отличаются от традиционных серверных веб-приложений.
Многие серверы авторизации и поставщики удостоверений не поддерживают запросы для совместного использования ресурсов между источниками (CORS).
Полностраничные перенаправления браузера от приложения могут быть назойливыми для пользовательского опыта.
Предупреждение
Корпорация Майкрософт рекомендует не использовать неявный поток предоставления. Рекомендуемый способ поддержки spAs — поток кода авторизации OAuth 2.0 (с PKCE). Для определенных конфигураций этого потока требуется очень высокий уровень доверия к приложению и риск, который не присутствует в других потоках. Этот поток следует использовать только при невозможности использовать другие, более безопасные потоки. Дополнительные сведения см. в проблемах безопасности с неявным потоком предоставления.
Некоторые фреймворки, такие как MSAL.js 1.x, поддерживают только неявный поток грантов. В этих случаях Azure Active Directory B2C (Azure AD B2C) поддерживает неявный поток предоставления авторизации OAuth 2.0. Поток описан в разделе 4.2 спецификации OAuth 2.0. В неявном потоке приложение получает токены непосредственно из конечной точки авторизации Azure AD B2C без обмена между серверами. Все действия по логике проверки подлинности и обработке сеансов полностью выполняются в клиенте JavaScript с перенаправлением страницы или всплывающего окна.
Azure AD B2C расширяет стандартный поток OAuth 2.0 до более простой проверки подлинности и авторизации. В Azure AD B2C представлен параметр политики. С помощью параметра политики можно использовать OAuth 2.0 для добавления политик в приложение, таких как регистрация, вход и потоки пользователей управления профилями. В примере HTTP-запросов в этой статье мы используем {tenant}.onmicrosoft.com для иллюстрации. Замените {tenant} на имя вашего арендатора, если он у вас есть. Кроме того, необходимо создать поток пользователя.
На следующем рисунке показан неявный поток входа. Каждый шаг подробно описан далее в статье.
Отправка запросов проверки подлинности
Когда веб-приложение должно пройти проверку подлинности пользователя и запустить поток пользователя, он направляет пользователя в конечную точку Azure AD B2C /authorize . Пользователь принимает меры в зависимости от потока пользователя.
В этом запросе клиент указывает разрешения, необходимые для получения от пользователя в параметре scope, и пользовательский поток для выполнения. Чтобы получить представление о том, как работает запрос, попробуйте вставить запрос в браузер и запустить его. Замените:
{tenant}с именем клиента Azure AD B2C.00001111-aaaa-2222-bbbb-3333cccc4444с идентификатором приложения, которое вы зарегистрировали в вашем клиенте.{policy}с именем политики, созданной в вашей среде, напримерb2c_1_sign_in.
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&response_mode=fragment
&scope=openid%20offline_access
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
Параметры в HTTP-запросе GET описаны в таблице ниже.
| Параметр | Обязательно | Описание |
|---|---|---|
| {арендатор} | Да | Имя клиента Azure AD B2C |
| {политика} | Да | Имя потока пользователя, который требуется запустить. Укажите имя потока пользователя, созданного в клиенте Azure AD B2C. Например: b2c_1_sign_in, b2c_1_sign_up, или b2c_1_edit_profile. |
| идентификатор клиента | Да | Идентификатор приложения, который портал Azure назначил вашему приложению. |
| тип_ответа | Да | Необходимо включить id_token для входа OpenID Connect. Он также может включать тип tokenответа. Если вы используете token, приложение может немедленно получить маркер доступа из конечной точки авторизации, не выполняя второй запрос к конечной точке авторизации. Если вы используете token тип ответа, параметр scope должен содержать область, указывающую, для какого ресурса следует выдать токен. |
| redirect_uri (URI перенаправления) | нет | Универсальный код ресурса (URI) перенаправления приложения, на который можно отправлять ответы аутентификации для их получения приложением. Он должен точно соответствовать одному из URI перенаправления, добавленных в зарегистрированное приложение на портале, за исключением того, что он должен быть закодирован URL-адресом. |
| режим_ответа | нет | Задает метод, используемый для отправки полученного маркера обратно в приложение. Для неявных потоков используйте fragment. |
| охват | Да | Список областей, разделённый пробелами. Одно значение области указывает Microsoft Entra ID все запрашиваемые разрешения. Область openid указывает разрешение на вход пользователя и получение данных о пользователе в виде маркеров идентификатора. Область offline_access является необязательной для веб-приложений. Это означает, что приложению требуется маркер обновления для долгосрочного доступа к ресурсам. |
| государство | нет | Значение, которое включается в запрос и также возвращается в ответе токена. Это может быть строка любого содержимого, которое вы хотите использовать. Обычно используется уникальное значение, сгенерированное случайным образом, чтобы предотвратить межсайтовую подделку запроса. Состояние также используется для кодирования сведений о состоянии пользователя в приложении до того, как произошел запрос на проверку подлинности, например страница, на которой был включен пользователь, или выполняемый поток пользователя. |
| данный случай | Да | Значение, включенное в запрос (созданное приложением), которое включается в итоговый токен идентификатора в виде утверждения. Приложение может проверить это значение для предотвращения атак повторного использования токена. Обычно это значение является случайной уникальной строкой, которая может использоваться для идентификации источника запроса. |
| подсказка | нет | Тип необходимого взаимодействия с пользователем. В настоящее время единственным допустимым значением является login. Этот параметр заставляет пользователя вводить свои учетные данные по этому запросу. Одиночный Sign-On не действует. |
Это интерактивная часть процесса. Пользователю предлагается завершить рабочий процесс политики. Пользователю может потребоваться ввести имя пользователя и пароль, войти с помощью социального удостоверения, зарегистрироваться для локальной учетной записи или любое другое количество шагов. Действия пользователей зависят от того, как определен поток пользователя.
После завершения пользовательского сценария Azure AD B2C возвращает ответ вашему приложению через redirect_uri. Он использует метод, указанный в параметре response_mode . Ответ точно совпадает с каждым из сценариев действий пользователя, независимо от выполняемого потока пользователя.
Успешный ответ
Успешный ответ, который использует response_mode=fragment и response_type=id_token+token выглядит следующим образом, с разрывами строк для удобочитаемости:
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
| Параметр | Описание |
|---|---|
| маркер доступа (access_token) | Маркер доступа, запрошенный приложением из Azure AD B2C. |
| тип токена | Значение типа токена. Единственным типом, поддерживаемым Azure AD B2C, является Bearer-токен. |
| срок действия истечет через | Срок действия маркера доступа (в секундах). |
| охват | Области, на которые распространяется действие маркера. Вы также можете использовать области для кэширования токенов для последующего использования. |
| идентификационный_токен | Маркер идентификации, запрошенный приложением. Вы можете использовать маркер идентификации для проверки личности пользователя и запуска сеанса пользователя. Дополнительные сведения о маркерах идентификаторов и их содержимом см. в справочнике по маркерам Azure AD B2C. |
| государство | Если запрос содержит параметр state, то в ответе должно отображаться то же значение. Приложение должно убедиться, что state значения в запросе и ответе идентичны. |
Ответ на ошибку
Ответы об ошибках также могут быть отправлены на URI перенаправления, чтобы приложение могло обработать их надлежащим образом.
GET https://aadb2cplayground.azurewebsites.net/#
error=access_denied
&error_description=the+user+canceled+the+authentication
&state=arbitrary_data_you_can_receive_in_the_response
| Параметр | Описание |
|---|---|
| ошибка | Код, используемый для классификации типов ошибок, возникающих. |
| описание ошибки | Конкретное сообщение об ошибке, с помощью которого можно определить первопричину возникновения ошибки аутентификации. |
| государство | Если запрос содержит параметр state, то в ответе должно отображаться то же значение. Приложение должно убедиться, что state значения в запросе и ответе идентичны. |
Проверка маркера идентификации
Получение токена идентификатора недостаточно для аутентификации пользователя. Проверьте подпись токена идентификатора и убедитесь, что утверждения в токене соответствуют требованиям вашего приложения. Azure AD B2C использует веб-маркеры JSON (JWTs) и криптографию открытого ключа для подписывания маркеров и проверки их допустимости.
Многие библиотеки с открытым кодом доступны для проверки JWT в зависимости от языка, который вы предпочитаете использовать. Рассмотрите возможность изучения доступных библиотек с открытым исходным кодом, а не реализации собственной логики проверки. Сведения, приведенные в этой статье, помогут вам узнать, как правильно использовать эти библиотеки.
Azure AD B2C имеет конечную точку метаданных OpenID Connect. Приложение может использовать конечную точку для получения сведений о Azure AD B2C во время выполнения. Эта информация включает точки подключения, содержимое токенов и ключи подписи токенов. Существует документ метаданных JSON для каждого потока пользователя в клиенте Azure AD 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заявление вid_token. Сведения о том, как анализировать утверждения из токена идентификатора, см. в справочнике по токенам Azure AD B2C.Зашифруйте поток пользователя в значении параметра
stateпри выполнении запроса. Затем декодируйте параметрstate, чтобы определить, какой сценарий пользователя использовался.
После получения документа метаданных из конечной точки метаданных OpenID Connect можно использовать открытые ключи RSA-256 (расположенные на этой конечной точке), чтобы проверить подпись маркера идентификатора. В каждый момент времени на этой конечной точке может быть представлено несколько ключей, каждый из которых идентифицирован kid. Заголовок id_token также содержит kid утверждение. Указывает, какой из этих ключей использовался для подписи ID-токена. Дополнительные сведения, включая изучение проверки маркеров, см. в справочнике по маркерам Azure AD B2C.
После проверки подписи токена идентификатора некоторые утверждения требуют проверки. Рассмотрим пример.
Валидируйте утверждение
nonce, чтобы предотвратить атаки повторного воспроизведения токенов. Его значение должно быть тем, что вы указали в запросе на вход.audПроверьте утверждение, чтобы убедиться, что маркер идентификатора был выдан для вашего приложения. Его значение должно быть идентификатором вашего приложения.Проверьте
iatиexpутверждения, чтобы убедиться, что токен идентификатора не истек.
Несколько дополнительных проверок, которые необходимо выполнить, подробно описаны в спецификации OpenID Connect Core. Также может потребоваться проверить дополнительные утверждения в зависимости от вашего сценария. Ниже приведены некоторые распространенные проверки:
Убедитесь, что пользователь или организация зарегистрировались в приложении.
Убедитесь, что у пользователя есть правильная авторизация и привилегии.
Убедитесь, что выполнена проверка подлинности на определенном уровне, например, с помощью многофакторной аутентификации Microsoft Entra.
Дополнительные сведения о утверждениях в токене идентификации см. в справочнике по токенам Azure AD B2C.
После проверки токена идентификатора вы можете начать сеанс с пользователем. В вашем приложении используйте утверждения в ID-токене для получения сведений о пользователе. Эти сведения можно использовать для отображения, записей, авторизации и т. д.
Получение токенов доступа
Если только веб-приложения должны выполнять потоки пользователей, можно пропустить следующие несколько разделов. Сведения в следующих разделах применимы только к веб-приложениям, которые должны выполнять прошедшие проверку подлинности вызовы к веб-API, защищенному самим Azure AD B2C.
После входа пользователя в SPA вы можете получить маркеры доступа для вызова веб-API, защищенных идентификатором Microsoft Entra. Даже если вы уже получили маркер с помощью token типа ответа, этот метод можно использовать для получения маркеров для дополнительных ресурсов без перенаправления пользователя для повторного входа.
В типичном потоке веб-приложения вы бы сделали запрос к конечной точке /token. Однако конечная точка не поддерживает запросы CORS, поэтому выполнение вызовов AJAX для получения маркера обновления не является вариантом. Вместо этого можно использовать неявный поток в скрытом элементе iframe HTML для получения новых маркеров для других веб-API. Ниже приведен пример с разрывами строк для удобочитаемости:
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
&response_mode=fragment
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
&prompt=none
| Параметр | Обязательно? | Описание |
|---|---|---|
| {арендатор} | Обязательно | Имя клиента Azure AD B2C |
| {политика} | Обязательно | Поток пользователя, который будет выполняться. Укажите имя потока пользователя, созданного в клиенте Azure AD B2C. Например: b2c_1_sign_in, b2c_1_sign_up, или b2c_1_edit_profile. |
| идентификатор клиента | Обязательно | Идентификатор приложения, назначенный приложению на портале Azure. |
| тип_ответа | Обязательно | Должен включать id_token для входа в OpenID Connect. Он также может включать тип tokenответа. Если вы используете token здесь, приложение может немедленно получить маркер доступа из конечной точки авторизации, не выполняя второй запрос к конечной точке авторизации. Если вы используете token тип ответа, параметр scope должен содержать область, указывающую, для какого ресурса следует выдать токен. |
| redirect_uri (URI перенаправления) | Рекомендуется | Универсальный код ресурса (URI) перенаправления приложения, на который можно отправлять ответы аутентификации для их получения приложением. Он должен в точности соответствовать одному из универсальных кодов ресурса (URI) перенаправления, зарегистрированных на портале, но иметь форму URL-адреса. |
| охват | Обязательно | Список областей, разделённый пробелами. Для получения маркеров включите все области, необходимые для предполагаемого ресурса. |
| режим_ответа | Рекомендуется | Указывает метод, используемый для отправки полученного маркера обратно в приложение. Для неявного потока используйте fragment. Можно указать два других режима, queryform_postно не работать в неявном потоке. |
| государство | Рекомендуется | Значение, включенное в запрос, возвращаемое в ответе токена. Это может быть строка любого содержимого, которое вы хотите использовать. Обычно используется уникальное значение, сгенерированное случайным образом, чтобы предотвратить межсайтовую подделку запроса. Состояние также используется для кодирования сведений о состоянии пользователя в приложении перед выполнением запроса проверки подлинности. Например, страница или экран, на котором был пользователь. |
| данный случай | Обязательно | Значение, включенное в запрос, созданное приложением, которое входит в полученный маркер идентификатора в качестве утверждения. Приложение может проверить это значение для предотвращения атак повторного использования токена. Обычно это значение является случайной уникальной строкой, определяющей источник запроса. |
| подсказка | Обязательно | Чтобы обновить и получить маркеры в скрытом iframe, используйте, prompt=none чтобы убедиться, что iframe не зависает на странице входа и возвращается немедленно. |
| подсказка для входа | Обязательно | Чтобы обновить и получить токены в скрытом iframe, добавьте имя пользователя в эту подсказку, чтобы различать несколько сеансов, которые пользователь может иметь в любой момент времени. Вы можете извлечь имя пользователя из предыдущего входа с помощью preferred_username утверждения ( profile область требуется для получения preferred_username утверждения). |
| подсказка_домена | Обязательно | Может иметь значение consumers или organizations. Для обновления и получения токенов в скрытом iframe, добавьте domain_hint значение в запрос. Извлеките утверждение tid из маркера идентификатора предыдущего входа, чтобы определить, какое значение следует использовать (область profile требуется для получения утверждения tid).
tid Если значение утверждения равно9188040d-6c67-4c5b-b112-36a304b66dad, используйте domain_hint=consumers. В противном случае используйте domain_hint=organizations. |
Задав prompt=none параметр, этот запрос завершается успешно или завершается сбоем немедленно и возвращается в приложение. Успешный ответ отправляется приложению через URI перенаправления с помощью метода, указанного в параметре response_mode .
Успешный ответ
Успешный ответ с использованием response_mode=fragment следующего примера:
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
| Параметр | Описание |
|---|---|
| маркер доступа (access_token) | Маркер, запрошенный приложением. |
| тип токена | Тип токена всегда будет Bearer. |
| государство | Если запрос содержит параметр state, то в ответе должно отображаться то же значение. Приложение должно убедиться, что state значения в запросе и ответе идентичны. |
| срок действия истечет через | Срок действия токена доступа (в секундах). |
| охват | Области, допустимые для маркера доступа. |
Ответ на ошибку
Ответы об ошибках также можно отправлять на URI перенаправления, чтобы приложение могло обработать их соответствующим образом. Для prompt=none, ожидаемая ошибка выглядит так, как показано в этом примере:
GET https://aadb2cplayground.azurewebsites.net/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently
| Параметр | Описание |
|---|---|
| ошибка | Строка кода ошибки, которую можно использовать для классификации типов ошибок, возникающих. Можно также использовать строку для реагирования на ошибки. |
| описание ошибки | Конкретное сообщение об ошибке, с помощью которого можно определить первопричину возникновения ошибки аутентификации. |
После появления этой ошибки в запросе iframe пользователю необходимо войти еще раз в интерактивном режиме для получения нового маркера.
Маркеры обновления
Токены идентификации и токены доступа истекают через короткий период времени. Ваше приложение должно периодически обновлять эти маркеры. Неявные потоки не позволяют получить маркер обновления из-за причин безопасности. Чтобы обновить любой тип токена, используйте неявный поток в скрытом элементе HTML iframe. В запросе авторизации включите prompt=none параметр. Чтобы получить новое значение id_token, обязательно используйте response_type=id_token и scope=openidпараметр nonce .
Отправка запроса на выход
Если вы хотите выйти из приложения, перенаправьте пользователя в конечную точку выхода Azure AD B2C. Затем вы можете очистить сеанс пользователя в приложении. Если вы не перенаправите пользователя, он, возможно, сможет снова пройти аутентификацию в вашем приложении, не вводя учетные данные повторно, поскольку у него есть действительный разовый сеанс Sign-On с 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%2Faadb2cplayground.azurewebsites.net%2F
| Параметр | Обязательно | Описание |
|---|---|---|
| {арендатор} | Да | Имя клиента Azure AD B2C. |
| {политика} | Да | Поток пользователя, который вы хотите использовать для выхода пользователя из приложения. Это должен быть тот же сценарий взаимодействия пользователя, который использовало приложение для входа пользователя. |
| URI перенаправления после выхода из системы | нет | URL-адрес, на который пользователь должен быть перенаправлен после успешного выхода. Если он не включен, Azure AD B2C отображает пользователю универсальное сообщение. |
| государство | нет | Если запрос содержит параметр state, то в ответе должно отображаться то же значение. Приложение должно убедиться, что state значения в запросе и ответе идентичны. |
Замечание
При направлении пользователя к end_session_endpoint очистке некоторых состояний Single Sign-On пользователя с помощью Azure AD B2C. Однако он не выходит из сеанса поставщика социальной идентификации пользователя. Если пользователь выбирает тот же поставщик удостоверений во время последующего входа, пользователь повторно проходит проверку подлинности без ввода учетных данных. Если пользователь хочет выйти из приложения Azure AD B2C, это не обязательно означает, что они хотят полностью выйти из своей учетной записи Facebook, например. Однако для локальных учетных записей сеанс пользователя будет завершен должным образом.
Дальнейшие шаги
См. пример кода: вход с помощью Azure AD B2C в SPA JavaScript.