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

Статья
11/21/2023

Для начала с помощью селектора Choose a policy type (Выбрать тип политики) выберите тип пользовательской политики. 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, предоставленные приложению.

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

Diagram of a web app with web A P I call registrations and tokens.

Шаг 1. Регистрация веб-ПРИЛОЖЕНИЯ API

На этом шаге вы регистрируете веб-API (App 2) со своими область. Позже вы предоставляете приложению разрешение (App 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. Создание секрета клиента

Создайте секрет клиента для зарегистрированного приложения. Приложение использует секрет клиента для подтверждения подлинности при запросе маркеров.

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

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

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

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

Ключ	Значение
grant_type	`client_credentials`
client_id	Идентификатор клиента из шага 2 "Регистрация приложения".
client_secret	Значение Секрет клиента из шага 2.1 "Создание секрета клиента".
область	URI идентификатора приложения из шага 1.1 "Определение ролей веб-API (областей)" и `.default`. например `https://contoso.onmicrosoft.com/api/.default` или `https://contoso.onmicrosoft.com/12345678-0000-0000-0000-000000000000/.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=33333333-0000-0000-0000-000000000000
&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": "33333333-0000-0000-0000-000000000000"
}

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

Утверждение	Description	Значение
`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>

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

Узнайте, как настроить поток учетных данных пароля для владельца ресурса в Azure AD B2C.

Поделиться через