Настройка потока учетных данных клиента OAuth 2.0 в Azure Active Directory B2C

Это важно

Начиная с 1 мая 2025 г. Azure AD B2C больше не будет доступен для приобретения для новых клиентов. Дополнительные сведения см. в разделе "Вопросы и ответы".

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

Поток предоставления учетных данных клиента OAuth 2.0 позволяет приложению (конфиденциальному клиенту) использовать собственные учетные данные вместо того, чтобы выдавать себя за пользователя, для проверки подлинности при вызове веб-ресурса, такого как REST API. Этот тип предоставления разрешения часто используется для взаимодействия между серверами, которое должно выполняться в фоновом режиме без непосредственного взаимодействия с пользователем. Такие типы приложений часто называют управляющими программами или учетными записями служб.

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

Замечание

Этот компонент находится в состоянии общедоступной предварительной версии.

Обзор регистрации приложения

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

Регистрация приложения позволяет приложению входить в систему с помощью Azure AD B2C. В процессе регистрации приложения создается идентификатор приложения, который также называется идентификатором клиента. Он однозначно идентифицирует ваше приложение. Кроме того, создается секрет клиента, который используется приложением для безопасного получения маркеров.
Регистрация веб-API позволяет приложению вызывать безопасный веб-API. Регистрация включает области веб-API. Области предоставляют возможностью управления разрешениями для защищенных ресурсов, например веб-API. Затем вы предоставляете приложению разрешения для областей веб-API. При запросе токена доступа ваше приложение указывает .default параметр области. Azure AD B2C возвращает области веб-API, предоставленные приложению.

Архитектура и регистрация приложения показаны на следующей схеме:

Схема веб-приложения с регистрациями вызовов web API и токенами.

Шаг 1: Зарегистрируйте приложение веб-API

На этом шаге вы регистрируете веб-API (App 2) с его областями действия. Позже вы предоставляете приложению (приложению 1) разрешение на доступ к этим областям. Если у вас уже есть регистрация такого приложения, пропустите этот шаг, а затем перейдите к следующему, Шаг 1.1 Определение ролей (областей) веб-API.

Чтобы создать регистрацию приложения веб-API (идентификатор приложения: 2), выполните следующие действия.

Войдите на портал Azure.
Убедитесь, что вы используете каталог, содержащий арендатора Azure AD B2C. На панели инструментов портала выберите значок Каталоги и подписки.
В настройках портала на странице Каталоги и подписки найдите свой каталог Azure AD B2C в списке Имя каталога и выберите Переключить.
В портале Azure найдите и выберите Azure AD B2C.
Выберите регистрации приложений и нажмите кнопку "Создать регистрацию".
В поле Имя введите имя приложения (например, my-api1). Оставьте значения по умолчанию для URI перенаправления и поддерживаемых типов учетных записей.
Выберите Зарегистрировать.
Когда регистрация приложения завершится, выберите Обзор.
Запишите значение идентификатора приложения (клиента) для дальнейшего использования при настройке веб-приложения.

Шаг 1.1 Определение ролей (областей) веб-API

На этом шаге вы настраиваете URI идентификатора приложения веб-API, а затем определяете роли приложений. Роли приложений, используемые областями OAuth 2.0 и определенные в регистрации приложения, представляющей ваш API. Приложение использует URI идентификатора приложения с областью действия .default. Чтобы определить роли в приложении, выполните следующие действия.

Выберите созданный вами веб-API, например my-api1.
В разделе "Управление" выберите "Предоставить API".
Рядом с полем URI идентификатора приложения щелкните ссылку Задать. Замените значение по умолчанию (GUID) уникальным именем (например, api), а затем нажмите кнопку Сохранить.
Скопируйте URI идентификатора приложения. На следующем снимке экрана показано, как скопировать URI идентификатора приложения.
В разделе Управление выберите Манифест , чтобы открыть редактор манифестов приложений. В редакторе найдите appRoles параметр и определите роли приложений, предназначенные для applications. Каждое определение роли приложения должно иметь глобальный уникальный идентификатор (GUID) для своего id значения. Создайте новый идентификатор GUID, выполнив new-guidкоманду в Microsoft PowerShell или в интерактивном генераторе идентификаторов GUID. Свойство value каждого определения роли приложения отображается в области (утверждении scp ). Свойство value не может содержать пробелы. В следующем примере показаны две роли приложения: чтение и запись:
```
"appRoles": [
{
  "allowedMemberTypes": ["Application"],
  "displayName": "Read",
  "id": "d6a15e20-f83c-4264-8e61-5082688e14c8",
  "isEnabled": true,
  "description": "Readers have the ability to read tasks.",
  "value": "app.read"
},
{
  "allowedMemberTypes": ["Application"],
  "displayName": "Write",
  "id": "204dc4ab-51e1-439f-8c7f-31a1ebf3c7b9",
  "isEnabled": true,
  "description": "Writers have the ability to create tasks.",
  "value": "app.write"
}],
```
В верхней части страницы нажмите кнопку Сохранить , чтобы сохранить изменения манифеста.

Шаг 2: Зарегистрируйте заявку

Чтобы разрешить приложению входить в Azure AD B2C с помощью потока учетных данных клиента, можно использовать существующее приложение или зарегистрировать новое (приложение 1).

Если вы используете существующее приложение, убедитесь, что в приложении элемент accessTokenAcceptedVersion установлен на значение 2:

В портале Azure найдите и выберите Azure AD B2C.
Выберите Регистрации приложений, а затем выберите существующее приложение из списка.
В меню слева в разделе Управление выберите Манифест , чтобы открыть редактор манифеста.
Найдите accessTokenAcceptedVersion элемент и задайте для него значение .2
В верхней части страницы нажмите кнопку Сохранить , чтобы сохранить изменения.

Чтобы создать новую регистрацию веб-приложения, выполните следующие действия:

На портале Azure найдите и выберите Azure AD B2C
Выберите регистрации приложений и нажмите кнопку "Создать регистрацию".
Введите имя приложения. Например, ClientCredentials_app.
Оставьте остальные значения как есть, а затем выберите Зарегистрировать.
Запишите идентификатор приложения (клиента) для использования на следующем шаге.

Шаг 2.1 Создание секрета клиента

Создайте секрет клиента для зарегистрированного приложения. Ваше приложение использует ключ клиента для подтверждения своей личности при запросе токенов.

В разделе Управление, выберите Сертификаты и секреты.
Выберите новый секрет клиента.
В поле "Описание " введите описание секрета клиента (например, clientecret1).
В разделе Истекает выберите срок действия секрета, а затем выберите Добавить.
Запишите значение секрета. Это значение используется для настройки на следующем шаге.

Шаг 2.2 Предоставьте приложению разрешения для веб-API

Чтобы предоставить приложению (приложению 1) разрешения, выполните следующие действия.

Выберите Регистрации приложений, а затем выберите созданное вами приложение (Приложение 1).
В разделе Управление выберите Разрешения API.
В разделе Настроенные разрешения выберите Добавить разрешение.
Выберите вкладку Мои API.
Выберите API (App 2), к которому веб-приложению должен быть предоставлен доступ. Например, введите my-api1.
Выберите Разрешение приложения.
В разделе Разрешение разверните приложение, а затем выберите области, которые вы определили ранее (например, app.read и app.write).
Выберите Добавить разрешения.
Выберите Предоставить согласие администратора для <имя арендатора>.
Выберите Да.
Выберите Обновить, а затем убедитесь, что Разрешено для... отображается в разделе Состояние для обеих областей.

Шаг 3: Получите токен доступа

Нет никаких конкретных действий для включения учетных данных клиента для потоков пользователей или настраиваемых политик. Потоки пользователей Azure AD B2C и настраиваемые политики поддерживают поток учетных данных клиента. Если вы еще этого не сделали, создайте поток пользователя или настраиваемую политику. Затем используйте свое любимое приложение для разработки API для генерации запроса на авторизацию. Создайте вызов, подобный этому примеру, со следующими сведениями в качестве текста запроса POST:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy>/oauth2/v2.0/token

Замените <tenant-name>именем вашего клиента Azure AD B2C. Например: contoso.b2clogin.com.
Замените <policy> его полным именем потока пользователя или пользовательской политикой. Обратите внимание, что все типы потоков пользователей и настраиваемые политики поддерживают поток учетных данных клиента. Вы можете использовать любой поток пользователя или настраиваемую политику или создать новую, например для регистрации или входа.

Ключ	Ценность
тип предоставления	`client_credentials`
идентификатор клиента	Идентификатор клиента из шага 2 Зарегистрировать заявку.
секрет_клиента	Значение секрета клиента из шага 2.1 Создание секрета клиента.
охват	URI идентификатора приложения из шага 1.1 Определение ролей (области) веб-API и `.default`. Например `https://contoso.onmicrosoft.com/api/.default`, или `https://contoso.onmicrosoft.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/.default`.

Фактический запрос POST выглядит следующим образом:

Запрос:

POST /<tenant-name>.onmicrosoft.com/B2C_1A_SUSI/oauth2/v2.0/token HTTP/1.1
Host: <tenant-name>.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=11112222-bbbb-3333-cccc-4444dddd5555
&client_secret=FyX7Q~DuPJ...
&scope=https%3A%2F%2Fcontoso.onmicrosoft.com%2Fapi%2F.default

Ответ.

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IlBFcG5OZDlnUkNWWUc2dUs...",
    "token_type": "Bearer",
    "not_before": 1645172292,
    "expires_in": 3600,
    "expires_on": 1645175892,
    "resource": "11112222-bbbb-3333-cccc-4444dddd5555"
}

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

Требование	Описание	Ценность
`aud`	Определяет целевого получателя маркера.	Идентификатор клиента API.
`sub`	Субъект-служба связывается с приложением, инициировавшим запрос.	Это основной элемент `client_id` запроса на авторизацию.
`azp`	Авторизованная сторона - сторона, которой был выдан токен доступа.	Идентификатор клиента приложения, инициировавшего запрос. Это то же значение, которое вы указали в `client_id` запросе на авторизацию.
`scp`	Набор областей, предоставляемых API приложения (разделитель пространства).	В потоке учетных данных клиента запрос авторизации запрашивает `.default` область, а токен содержит список областей, открытых API (и одобренных администратором приложения). Например: `app.read app.write`.

Шаг 3.1 Получение токена доступа с помощью скрипта

Используйте следующий скрипт PowerShell для проверки конфигурации:

$appId = "<client ID>"
$secret = "<client secret>"
$endpoint = "https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy>/oauth2/v2.0/token"
$scope = "<Your API id uri>/.default"
$body = "grant_type=client_credentials&scope=" + $scope + "&client_id=" + $appId + "&client_secret=" + $secret

$token = Invoke-RestMethod -Method Post -Uri $endpoint -Body $body

Используйте следующий скрипт cURL для проверки конфигурации:

curl --location --request POST 'https://<your-tenant>.b2clogin.com/<your-tenant>.onmicrosoft.com/<policy>/oauth2/v2.0/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--form 'grant_type="client_credentials"' \
--form 'client_id="<client ID>"' \
--form 'client_secret="<client secret>"' \
--form 'scope="<Your API id uri>/.default"'

Шаг 4: Настройте токен

Эта функция доступна только для пользовательских политик. Для действий по настройке выберите пользовательскую политику в предыдущем селекторе.

Пользовательские политики позволяют расширить процесс выдачи токенов. Чтобы настроить путь пользователя для учетных данных клиента OAuth 2.0, следуйте инструкциям по настройке пути пользователя для учетных данных клиента. Затем в JwtIssuer техническом профиле добавьте ClientCredentialsUserJourneyId метаданные со ссылкой на созданный вами путь пользователя.

В следующем примере показано, как добавить ClientCredentialsUserJourneyId в технический профиль эмитента токенов.

<TechnicalProfile Id="JwtIssuer">
  <Metadata>
    <Item Key="ClientCredentialsUserJourneyId">ClientCredentialsJourney</Item>
  </Metadata>
</TechnicalProfile>

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

<UserJourneys>
  <UserJourney Id="ClientCredentialsJourney">
    <OrchestrationSteps>
      <!-- [Required] Do the client credentials -->
      <OrchestrationStep Order="1" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="ClientCredSetupExchange" TechnicalProfileReferenceId="ClientCredentials_Setup" />
        </ClaimsExchanges>
      </OrchestrationStep>

      <!-- [Optional] Call a REST API or claims transformation -->
      <OrchestrationStep Order="2" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="TokenAugmentation" TechnicalProfileReferenceId="TokenAugmentation" />
        </ClaimsExchanges>
      </OrchestrationStep>

      <!-- [Required] Issue the access token -->
      <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys>

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-05-03