Поток On-Behalf-Of в OAuth 2.0 и платформа удостоверений Майкрософт

Статья
12/05/2022
Чтение занимает 14 мин

Поток on-behalf-of (OBO) описывает сценарий использования веб-API с использованием удостоверения, отличного от собственного, для вызова другого веб-API. В OAuth называется делегированием, цель заключается в передаче удостоверения и разрешений пользователя через цепочку запросов.

Чтобы служба среднего уровня выполняла аутентифицированные запросы к подчиненной службе, ей необходимо защитить маркер доступа от платформа удостоверений Майкрософт. В нем используются только делегированные области, а не роли приложения. Роли остаются присоединенными к субъекту (пользователю) и никогда не к приложению, работающему от имени пользователя. Это происходит, чтобы предотвратить получение пользователем разрешений на ресурсы, к которых у него не должно быть доступа.

В этой статье описывается, как программировать непосредственно в протокол в приложении. По возможности рекомендуется использовать поддерживаемые библиотеки проверки подлинности Майкрософт (MSAL) вместо получения маркеров и вызова защищенных веб-API. Также ознакомьтесь с примерами приложений, использующих MSAL .

Совет

Попробуйте выполнить этот запрос и многое другое в Postman — не забудьте заменить токены и идентификаторы!

Ограничения клиентов

Если субъект-служба запросил маркер только для приложения и отправил его в API, этот API обменивается маркером, который не представляет исходный субъект-службу. Это связано с тем, что поток OBO работает только для субъектов-пользователей. Вместо этого он должен использовать поток учетных данных клиента для получения маркера только для приложения. В случае одностраничных приложений они должны передавать маркер доступа в конфиденциальный клиент среднего уровня для выполнения потоков OBO.

Если клиент использует неявный поток для получения id_token и имеет подстановочные знаки в URL-адресе ответа, id_token нельзя использовать для потока OBO. Подстановочный знак — это URL-адрес, заканчивающийся символом * . Например, если https://myapp.com/* был URL-адрес ответа, id_token нельзя использовать, так как он недостаточно специфичный для идентификации клиента. Это предотвратит выдачу маркера. Однако маркеры доступа, полученные через поток неявного предоставления, могут быть активированы конфиденциальным клиентом, даже если у инициирующего клиента зарегистрирован URL-адрес ответа с подстановочными знаками. Это связано с тем, что конфиденциальный клиент может идентифицировать клиента, который получил маркер доступа. Затем конфиденциальный клиент может использовать маркер доступа для получения нового маркера доступа для подчиненного API.

Кроме того, приложения с пользовательскими ключами подписывания нельзя использовать в качестве API среднего уровня в потоке OBO. Сюда входят корпоративные приложения, настроенные для единого входа. Если API среднего уровня использует пользовательский ключ подписывания, подчиненный API не сможет проверить сигнатуру маркера доступа, передаваемого ему. Это приведет к ошибке, так как маркеры, подписанные с помощью ключа, управляемого клиентом, не могут быть безопасно приняты.

Схема протокола

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

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

Показывает поток On-Behalf-Of в OAuth 2.0

Клиентское приложение отправляет запрос к API A с маркером A (с утверждением aud API А).
API A выполняет проверку подлинности на конечной точке выдачи маркера платформы удостоверений Майкрософт и запрашивает маркер доступа к API B.
Конечная точка выдачи маркера платформы удостоверений Майкрософт проверяет учетные данные API A и маркер A и выдает маркера доступа для API B (маркер B) к API A.
Маркер B задается API A в заголовке авторизации запроса к API B.
Данные из защищенного ресурса возвращаются API B в API A, а затем клиенту.

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

Запрос маркера доступа среднего уровня

Чтобы запросить маркер доступа, отправьте HTTP-запрос POST к конечной точке маркера платформы удостоверений Майкрософт для конкретного клиента с указанными ниже параметрами.

https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token

Предупреждение

НЕ отправляйте маркеры доступа, выданные для среднего уровня, другой стороне. Маркеры доступа, выданные для среднего уровня, предназначены для использования только на этом среднем уровне.

К рискам безопасности при ретрансляции маркеров доступа из ресурса среднего уровня клиенту (вместо получения маркеров доступа самим клиентом) относятся:

Повышенный риск перехвата маркеров через скомпрометированные каналы SSL/TLS.
Невозможность удовлетворения требований для привязки маркера и сценариев условного доступа, требующих повышения уровня утверждения (например, для MFA и частоты входа).
Несовместимость с настроенными администратором политиками на основе устройств (например, MDM и политиками на основе расположения).

Существуют два сценария. Их выбор зависит от типа защиты клиентского приложения — с помощью общего секрета или с помощью сертификата.

Первый вариант. Запрос маркера доступа с помощью общего секрета

При использовании общего секрета запрос маркера взаимного доступа между службами содержит следующие параметры:

Параметр	Тип	Описание
`grant_type`	Обязательно	Тип запроса маркера. Для запроса с использованием JWT нужно указать значение `urn:ietf:params:oauth:grant-type:jwt-bearer`.
`client_id`	Обязательно	Идентификатор приложения (клиента), назначенный вашему приложению на странице регистрации приложений на портале Azure.
`client_secret`	Обязательно	Секрет клиента, созданный для приложения на портале Azure — страница регистрации приложений. Также поддерживается шаблон базовой проверки подлинности вместо предоставления учетных данных в заголовке авторизации согласно RFC 6749.
`assertion`	Обязательно	Маркер доступа, который был отправлен в API среднего уровня. У этого маркера должно быть утверждение `aud` приложения, которое делает этот запрос OBO (приложения, указанного в поле `client-id`). Приложения не могут активировать маркер для другого приложения (например, если клиент отправляет API маркер, предназначенный для Майкрософт Graph, API не может активировать его с помощью OBO. Вместо этого следует отклонить маркер).
`scope`	Обязательно	Список областей для запроса токена, разделенный пробелами. Дополнительные сведения см. в разделе Области.
`requested_token_use`	Обязательно	Указывает, как должен быть обработан запрос. В потоке OBO нужно указать значение `on_behalf_of`.

Пример

Следующий HTTP-запрос POST запрашивает маркер и маркер обновления доступа с областью user.read для веб-API https://graph.microsoft.com. Запрос подписывается секретом клиента и выполняется конфиденциальным клиентом.

//line breaks for legibility only

POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com/<tenant>
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
client_id=535fb089-9ff3-47b6-9bfb-4f1264799865
&client_secret=sampleCredentia1s
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiIyO{a lot of characters here}
&scope=https://graph.microsoft.com/user.read+offline_access
&requested_token_use=on_behalf_of

Второй вариант. Запрос маркера доступа с помощью сертификата

Запрос маркера доступа между службами с сертификатом содержит следующие параметры в дополнение к параметрам из предыдущего примера:

Параметр	Тип	Описание
`grant_type`	Обязательно	Тип запроса токена. Для запроса с использованием JWT нужно указать значение `urn:ietf:params:oauth:grant-type:jwt-bearer`.
`client_id`	Обязательно	Идентификатор приложения (клиента), назначенный вашему приложению на странице регистрации приложений на портале Azure.
`client_assertion_type`	Обязательно	Значение должно быть равно `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.
`client_assertion`	Обязательно	Утверждение (JSON Web Token), которое необходимо создать и подписать с помощью сертификата, зарегистрированного как учетные данные для приложения. Ознакомьтесь с информацией об учетных данных сертификата, чтобы узнать, как зарегистрировать сертификат и задать формат утверждения.
`assertion`	Обязательно	Маркер доступа, который был отправлен в API среднего уровня. У этого маркера должно быть утверждение `aud` приложения, которое делает этот запрос OBO (приложения, указанного в поле `client-id`). Приложения не могут активировать маркер для другого приложения (например, если клиент отправляет API маркер, предназначенный для MS Graph, API не может активировать его с помощью OBO. Вместо этого следует отклонить маркер).
`requested_token_use`	Обязательно	Указывает, как должен быть обработан запрос. В потоке OBO нужно указать значение `on_behalf_of`.
`scope`	Обязательно	Список областей для запроса маркера, разделенный пробелами. Дополнительные сведения см. в разделе Области.

Обратите внимание на то, что параметры являются почти такими же, как и при использовании запроса с помощью общего секрета, за исключением параметра client_secret, который заменяется двумя параметрами: client_assertion_type и client_assertion. Параметру client_assertion_type присваивается значение urn:ietf:params:oauth:client-assertion-type:jwt-bearer , а параметру client_assertion — маркер JWT, подписанный закрытым ключом сертификата.

Пример

Ниже приведен HTTP-запрос POST маркера доступа с областью user.read для веб-API https://graph.microsoft.com с сертификатом. Запрос подписывается секретом клиента и выполняется конфиденциальным клиентом.

// line breaks for legibility only

POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com/<tenant>
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id=625391af-c675-43e5-8e44-edd3e30ceb15
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiO{a lot of characters here}
&requested_token_use=on_behalf_of
&scope=https://graph.microsoft.com/user.read+offline_access

Ответ на запрос маркера доступа среднего уровня

Если доступ предоставлен, ответ будет содержать JSON-файл OAuth 2.0 со следующими параметрами.

Параметр	Описание
`token_type`	Указывает значение типа маркера. Платформа удостоверений Майкрософт поддерживает только тип `Bearer`. Дополнительные сведения о маркерах носителей см. в спецификации OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750) (OAuth2.0 Authorization Framework: использование маркера носителя (RFC 6750)).
`scope`	Область доступа, предоставляемая токеном.
`expires_in`	Срок действия маркера доступа (в секундах).
`access_token`	Запрашиваемый маркер доступа. Вызывающая служба может использовать этот токен для проверки подлинности принимающей службы.
`refresh_token`	Токен обновления для запрошенного токена доступа. Вызывающая служба может использовать этот токен для запроса другого токена доступа после того, как срок действия текущего токена доступа истек. Маркер обновления предоставляется только в том случае, если запрошена область `offline_access`.

Пример ответа с успешным предоставлением доступа

В следующем примере показано сообщение о предоставлении доступа в ответ на запрос маркера доступа к веб-API https://graph.microsoft.com. Ответ содержит маркер доступа и маркер обновления и подписывается закрытым ключом сертификата.

{
  "token_type": "Bearer",
  "scope": "https://graph.microsoft.com/user.read",
  "expires_in": 3269,
  "ext_expires_in": 0,
  "access_token": "eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1tQTZOVGFlN0NkV1c3UWZkQ0NDYy0tY0hGa18wZE50MVEtc2loVzRMd2RwQVZISGpnTVdQZ0tQeVJIaGlDbUN2NkdyMEpmYmRfY1RmMUFxU21TcFJkVXVydVJqX3Nqd0JoN211eHlBQSIsImFsZyI6IlJTMjU2IiwieDV0IjoiejAzOXpkc0Z1aXpwQmZCVksxVG4yNVFIWU8wIiwia2lkIjoiejAzOXpkc0Z1aXpwQmZCVksxVG4yNVFIWU8wIn0.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMWRiNDcvIiwiaWF0IjoxNDkzOTMwMzA1LCJuYmYiOjE0OTM5MzAzMDUsImV4cCI6MTQ5MzkzMzg3NSwiYWNyIjoiMCIsImFpbyI6IkFTUUEyLzhEQUFBQU9KYnFFWlRNTnEyZFcxYXpKN1RZMDlYeDdOT29EMkJEUlRWMXJ3b2ZRc1k9IiwiYW1yIjpbInB3ZCJdLCJhcHBfZGlzcGxheW5hbWUiOiJUb2RvRG90bmV0T2JvIiwiYXBwaWQiOiIyODQ2ZjcxYi1hN2E0LTQ5ODctYmFiMy03NjAwMzViMmYzODkiLCJhcHBpZGFjciI6IjEiLCJmYW1pbHlfbmFtZSI6IkNhbnVtYWxsYSIsImdpdmVuX25hbWUiOiJOYXZ5YSIsImlwYWRkciI6IjE2Ny4yMjAuMC4xOTkiLCJuYW1lIjoiTmF2eWEgQ2FudW1hbGxhIiwib2lkIjoiZDVlOTc5YzctM2QyZC00MmFmLThmMzAtNzI3ZGQ0YzJkMzgzIiwib25wcmVtX3NpZCI6IlMtMS01LTIxLTIxMjc1MjExODQtMTYwNDAxMjkyMC0xODg3OTI3NTI3LTI2MTE4NDg0IiwicGxhdGYiOiIxNCIsInB1aWQiOiIxMDAzM0ZGRkEwNkQxN0M5Iiwic2NwIjoiVXNlci5SZWFkIiwic3ViIjoibWtMMHBiLXlpMXQ1ckRGd2JTZ1JvTWxrZE52b3UzSjNWNm84UFE3alVCRSIsInRpZCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsInVuaXF1ZV9uYW1lIjoibmFjYW51bWFAbWljcm9zb2Z0LmNvbSIsInVwbiI6Im5hY2FudW1hQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJWR1ItdmtEZlBFQ2M1dWFDaENRSkFBIiwidmVyIjoiMS4wIn0.cubh1L2VtruiiwF8ut1m9uNBmnUJeYx4x0G30F7CqSpzHj1Sv5DCgNZXyUz3pEiz77G8IfOF0_U5A_02k-xzwdYvtJUYGH3bFISzdqymiEGmdfCIRKl9KMeoo2llGv0ScCniIhr2U1yxTIkIpp092xcdaDt-2_2q_ql1Ha_HtjvTV1f9XR3t7_Id9bR5BqwVX5zPO7JMYDVhUZRx08eqZcC-F3wi0xd_5ND_mavMuxe2wrpF-EZviO3yg0QVRr59tE3AoWl8lSGpVc97vvRCnp4WVRk26jJhYXFPsdk4yWqOKZqzr3IFGyD08WizD_vPSrXcCPbZP3XWaoTUKZSNJg",
  "refresh_token": "OAQABAAAAAABnfiG-mA6NTae7CdWW7QfdAALzDWjw6qSn4GUDfxWzJDZ6lk9qRw4An{a lot of characters here}"
}

Этот маркер доступа представляет собой маркер в формате 1.0 для Майкрософт Graph. Версия обусловлена тем, что формат маркера основан на ресурсе, к которому осуществляется доступ, и не связан с конечными точками, используемыми для запроса. Майкрософт Graph настроен на прием маркеров версии 1.0, поэтому платформа удостоверений Майкрософт создает маркеры доступа версии 1.0, когда клиент запрашивает маркеры для Майкрософт Graph. Другие приложения могут указывать, что им требуются маркеры формата версии 2.0, маркеры формата версии 1.0 или даже маркеры собственного или зашифрованного формата. Конечные точки версии 1.0 и 2.0 могут выдавать маркеры любого формата. Таким образом, ресурс всегда может получить правильный формат маркера независимо от того, как и где маркер был запрошен клиентом.

Предупреждение

Не пытайтесь проверить или прочесть маркеры для любого API, который вам не принадлежит, включая маркеры в этом примере, в коде. Маркеры для служб Майкрософт могут использовать специальный формат, который не будет проверяться как JWT и может также быть зашифрован для пользователей-потребителей (учетная запись Майкрософт). Несмотря на то, что чтение маркеров является полезным средством отладки и обучения, не задавайте зависимости от него в коде или не опирайтесь на конкретные сведения о токенах, которые не предназначены для контролируемого вами API.

Пример ответа с сообщением об ошибке

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

{
    "error":"interaction_required",
    "error_description":"AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multifactor authentication to access 'bf8d80f9-9098-4972-b203-500f535113b1'.\r\nTrace ID: b72a68c3-0926-4b8e-bc35-3150069c2800\r\nCorrelation ID: 73d656cf-54b1-4eb2-b429-26d8165a52d7\r\nTimestamp: 2017-05-01 22:43:20Z",
    "error_codes":[50079],
    "timestamp":"2017-05-01 22:43:20Z",
    "trace_id":"b72a68c3-0926-4b8e-bc35-3150069c2800",
    "correlation_id":"73d656cf-54b1-4eb2-b429-26d8165a52d7",
    "claims":"{\"access_token\":{\"polids\":{\"essential\":true,\"values\":[\"9ab03e19-ed42-4168-b6b7-7001fb3e933a\"]}}}"
}

Использование токена доступа для доступа к защищенному ресурсу

Теперь служба среднего уровня может использовать полученный выше токен для запросов к веб-API нижнего уровня с проверкой подлинности путем установки токена в заголовке Authorization.

Пример

GET /v1.0/me HTTP/1.1
Host: graph.microsoft.com
Authorization: Bearer eyJ0eXAiO ... 0X2tnSQLEANnSPHY0gKcgw

Утверждения SAML, полученные с помощью потока OBO в OAuth2.0

Некоторые веб-службы на основе OAuth должны получать доступ к другим API веб-служб, получающим утверждения SAML в неинтерактивных потоках. Azure Active Directory может предоставить утверждение SAML в ответ на поток On-Behalf-Of с использованием веб-службы на основе SAML в качестве целевого ресурса.

Это нестандартное расширение для потока On-Behalf-Of в OAuth 2.0, позволяющее приложению на основе OAuth2 получать доступ к конечным точкам API веб-служб, использующим токены SAML.

Совет

Чтобы вызвать защищенную с помощью SAML веб-службу из веб-приложения переднего плана, достаточно вызвать API и инициировать обычный интерактивный поток проверки подлинности в имеющемся сеансе пользователя. Если для предоставления контекста пользователя вызову между службами необходим токен SAML, то достаточно использовать поток OBO.

Получение токена SAML при помощи запроса OBO с общим секретом

Запрос утверждения SAML между службами содержит следующие параметры:

Параметр	Тип	Описание
grant_type	обязательно	Тип запроса токена. Для запроса с использованием JWT это значение должно быть равно `urn:ietf:params:oauth:grant-type:jwt-bearer`.
assertion	обязательно	Значение маркера доступа, используемого в запросе.
client_id	обязательно	Идентификатор приложения, назначенный вызывающей службе при регистрации в Azure AD. Чтобы узнать идентификатор приложения на портале Azure, нажмите Active Directory, выберите каталог, а затем щелкните имя приложения.
client_secret	обязательно	Ключ, зарегистрированный для вызывающей службы в Azure AD. Значение ключа должно было быть записано при регистрации. Также поддерживается шаблон базовой проверки подлинности вместо предоставления учетных данных в заголовке авторизации согласно RFC 6749.
область	обязательно	Список областей для запроса маркера, разделенный пробелами. Дополнительные сведения см. в разделе Области. Сам SAML не имеет понятия областей, но используется для идентификации целевого приложения SAML, для которого требуется получить маркер. Для этого потока OBO в качестве значения области всегда должен выступать идентификатор сущности SAML с добавлением `/.default`. Например, если идентификатор сущности приложения SAML — `https://testapp.contoso.com`, то запрошенной областью должна быть `https://testapp.contoso.com/.default`. Если идентификатор сущности не начинается со схемы универсального кода ресурса (URI), такой как `https:`, Azure AD добавит к идентификатору сущности префикс `spn:`. В этом случае необходимо запросить область `spn:<EntityID>/.default`, например `spn:testapp/.default`, если идентификатор сущности — `testapp`. Запрашиваемое здесь значение области определяет результирующий `Audience` элемент в токене SAML, что может быть важно для приложения SAML, получающего маркер.
requested_token_use	обязательно	Указывает, как должен быть обработан запрос. Для потока On-Behalf-Of это значение должно быть равно `on_behalf_of`.
requested_token_type	обязательно	Задает тип запрашиваемого токена. Можно задать значение `urn:ietf:params:oauth:token-type:saml2` или `urn:ietf:params:oauth:token-type:saml1` в зависимости от требований запрашиваемого ресурса.

Отклик содержит токен SAML с кодировками UTF8 и Base64url.

SubjectConfirmationData для утверждения SAML, полученного из вызова OBO. Если целевому приложению необходимо значение Recipient в параметре SubjectConfirmationData, то необходимо настроить первый URL-адрес ответа без подстановочных знаков в качестве значения в конфигурации приложения-ресурса. Так как URL-адрес ответа по умолчанию не используется для определения Recipient значения, может потребоваться изменить порядок URL-адресов ответа в конфигурации приложения, чтобы убедиться, что используется первый URL-адрес ответа без подстановочного знака. Дополнительные сведения см. в статье URL-адреса ответа.
Узел SubjectConfirmationData. Узел не может содержать атрибут InResponseTo, так как он не входит в состав отклика SAML. Приложение, получающее токен SAML, должно иметь возможность принимать утверждение SAML без атрибута InResponseTo.
Разрешения API: необходимо добавить необходимые разрешения API в приложение среднего уровня, чтобы разрешить доступ к приложению SAML для запроса маркера для области действия /.default приложения SAML.
Согласие. Должно быть предоставлено согласие на получение токена SAML, содержащего данные пользователей в потоке OAuth. Дополнительные сведения см. в разделе Получение согласия для приложения среднего уровня ниже.

Отклик с утверждением SAML

Параметр	Описание
token_type	Указывает значение типа маркера. Единственный тип, поддерживаемый Azure AD — носитель. Дополнительные сведения о маркерах носителей см. в спецификации OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750) (OAuth2.0 Authorization Framework: использование маркера носителя (RFC 6750)).
область	Область доступа, предоставляемая токеном.
expires_in	Срок действия доступа для токена (в секундах).
expires_on	Время истечения срока действия маркера доступа. Дата представляется как количество секунд с 1970-01-01T0:0:0Z в формате UTC до истечения срока действия. Это значение используется для определения времени существования кэшированных маркеров.
ресурс	URI идентификатора приложения принимающей службы (защищенный ресурс).
access_token	Параметр, возвращающий утверждение SAML.
refresh_token	Маркер обновления. Вызывающая служба может использовать этот токен для запроса другого токена доступа по истечении срока действия текущего утверждения SAML.

token_type Носитель
expires_in: 3296.
ext_expires_in: 0
expires_on: 1529627844.
resource: https://api.contoso.com
access_token: <утверждение SAML>.
issued_token_type: urn:ietf:params:oauth:token-type:saml2
refresh_token: <маркер обновления>.

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

Приложение среднего уровня добавляет клиент в список известных клиентских приложений (knownClientApplications) в своем манифесте. Если запрос на предоставление согласия активируется клиентом, поток получения согласия будет создан как для этого клиента, так и для приложения среднего уровня. На платформе удостоверений Майкрософт эта задача выполняется с помощью области . Область .default — это специальная область, которая используется для запроса согласия на доступ ко всем областям, на которые у приложения есть разрешения. Это полезно, если приложению требуется доступ к нескольким ресурсам, но пользователю следует запрашивать согласие только один раз.

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

Определенная в запросе служба ресурсов (API) должна представлять собой API, для которого клиентское приложение запрашивает маркер доступа в ответ на вход пользователя. Например, scope=openid https://middle-tier-api.example.com/.default (чтобы запросить маркер доступа для API среднего уровня) или scope=openid offline_access .default (если ресурс не определен, по умолчанию используется Майкрософт Graph).

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

Предварительно авторизованные приложения

Ресурс может указать, что у заданного приложения всегда есть разрешение на прием определенных областей. Это полезно для упрощения подключений между интерфейсным клиентом и серверным ресурсом. Ресурс может объявлять несколько предварительно авторизованных приложений (preAuthorizedApplications) в своем манифесте. Любое такое приложение может запросить эти разрешения в потоке OBO и получить их без согласия пользователя.

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

Использование одного приложения

В некоторых сценариях может использоваться только одна пара приложения среднего уровня и интерфейсного клиента. В этом случае вам может быть проще создать одно приложение, избавившись от потребности в приложении среднего уровня. Для аутентификации между внешним интерфейсом и веб-API можно использовать файлы cookie, маркер id_token или маркер доступа, запрошенный для приложения. Затем можно запросить согласие у этого приложения для доступа к внутреннему ресурсу.

Дальнейшие действия

Дополнительные сведения о протоколе OAuth 2.0 и другом способе проверки подлинности между службами с использованием учетных данных клиента.

Поток On-Behalf-Of в OAuth 2.0 и платформа удостоверений Майкрософт

Ограничения клиентов

Схема протокола

Запрос маркера доступа среднего уровня

Первый вариант. Запрос маркера доступа с помощью общего секрета

Пример

Второй вариант. Запрос маркера доступа с помощью сертификата

Пример

Ответ на запрос маркера доступа среднего уровня

Пример ответа с успешным предоставлением доступа

Пример ответа с сообщением об ошибке

Использование токена доступа для доступа к защищенному ресурсу

Пример

Утверждения SAML, полученные с помощью потока OBO в OAuth2.0

Получение токена SAML при помощи запроса OBO с общим секретом

Отклик с утверждением SAML

Предварительно авторизованные приложения

Использование одного приложения

Дальнейшие действия

Дополнительные ресурсы

Дополнительные ресурсы

Поток On-Behalf-Of в OAuth 2.0 и платформа удостоверений Майкрософт

Ограничения клиентов

Схема протокола

Запрос маркера доступа среднего уровня

Первый вариант. Запрос маркера доступа с помощью общего секрета

Пример

Второй вариант. Запрос маркера доступа с помощью сертификата

Пример

Ответ на запрос маркера доступа среднего уровня

Пример ответа с успешным предоставлением доступа

Пример ответа с сообщением об ошибке

Использование токена доступа для доступа к защищенному ресурсу

Пример

Утверждения SAML, полученные с помощью потока OBO в OAuth2.0

Получение токена SAML при помощи запроса OBO с общим секретом

Отклик с утверждением SAML

Получение согласия для приложения среднего уровня

Область .default и объединенное согласие

Предварительно авторизованные приложения

Согласие администратора

Использование одного приложения

Дальнейшие действия

Дополнительные ресурсы

Дополнительные ресурсы