Microsoft 标识平台和 OAuth 2.0 代理流

项目
04/08/2024

代理 (OBO) 流描述了 Web API 使用其自身以外的标识来调用另一个 Web API 的方案。在 OAuth 中称为委派，目的是通过请求链传递用户的标识和权限。

要使中间层服务向下游服务发出身份验证请求，该服务需要保护 Microsoft 标识平台提供的访问令牌。它仅使用委派范围，而不使用应用程序角色。角色仍然依附于主体（用户），而不依附于代表用户操作的应用程序。这是为了防止用户获得他们无权访问的资源的权限。

本文介绍如何在应用程序中直接针对协议进行编程。如果可能，建议你改用受支持的 Microsoft 身份验证库 (MSAL) 来获取令牌并调用受保护的 Web API。有关示例，另请参阅使用 MSAL 的示例应用。

客户端限制

如果服务主体请求仅限应用的令牌并将其发送到 API，则该 API 将交换不代表原始服务主体的令牌。这是因为 OBO 流仅适用于用户主体。而它必须使用客户端凭据流来获取仅限应用的令牌。对于单页应用 (SPA)，应改为将访问令牌传递给中间层机密客户端，才能执行 OBO 流。

如果客户端使用隐式流来获取 id_token，且在回复 URL 中也具有通配符，id_token 就无法用于 OBO 流。通配符是以 * 字符结尾的 URL。例如，如果 https://myapp.com/* 是回复 URL，就无法使用 id_token，因为它不够具体，无法识别客户端。这将阻止颁发令牌。但是，即使发起客户端已注册通配符回复 URL，通过隐式授予流获取的访问令牌仍由机密客户端兑换。这是因为机密客户端可以识别获取访问令牌的客户端。然后，机密客户端可以使用访问令牌为下游 API 获取新的访问令牌。

此外，具有自定义签名密钥的应用程序不能用作 OBO 流中的中间层 API。这包括为单一登录配置的企业应用程序。如果中间层 API 使用自定义签名密钥，下游 API 将不会验证向其传递的访问令牌的签名。这将导致错误，因为无法安全地接受使用客户端控制的密钥签名的令牌。

协议图

假设用户使用 OAuth 2.0 授权代码授权流或其他登录流对应用程序进行了身份验证。此时，应用程序已获得 API A 的访问令牌（令牌 A），其中包含用户对访问中间层 Web API (API A) 的声明和许可。现在，API A 需要向下游 Web API (API B) 发出身份验证请求。

接下来的步骤构成了 OBO 流，并在下图中进行说明。

显示 OAuth2.0 代理流

客户端应用程序使用令牌 A（其中包含 API A 的 aud 声明）向 API A 发出请求。
API A 向 Microsoft 标识平台令牌颁发终结点进行身份验证并请求访问 API B 的令牌。
Microsoft 标识平台令牌颁发终结点使用令牌 A 验证 API A 的凭据，并颁发供 API B（令牌 B）访问 API A 的访问令牌。
令牌 B 由 API A 在向 API B 发出的请求的 authorization 标头中设置。
受保护资源中的数据将通过 API B 返回到 API A，然后返回到客户端。

在此方案中，中间层服务无需用户干预，即可获取用户对访问下游 API 的同意。因此，在身份验证过程的许可步骤中会提前显示授权访问下游 API 的选项。若要了解如何在应用中实现此目的，请参阅为中间层应用程序获得许可。

中间层访问令牌请求

若要请求访问令牌，请使用以下参数向特定于租户的 Microsoft 标识平台令牌终结点发出 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`	必须	Microsoft Entra 管理中心 - 应用注册页分配给应用的“应用程序（客户端）ID”。
`client_secret`	必须	你在 Microsoft Entra 管理中心 - 应用注册页中为应用生成的客户端密码。还支持根据 RFC 6749 在授权标头中提供凭据的基本身份验证模式。
`assertion`	必须	已发送到中间层 API 的访问令牌。此令牌必须包含发出此 OBO 请求的应用（由 `client-id` 字段表示的应用）的受众 (`aud`) 声明。应用程序无法兑换其他应用的令牌（例如，如果客户端向 API 发送用于 Microsoft Graph 的令牌，该 API 无法使用 OBO 兑换该令牌。它应改为拒绝该令牌）。
`scope`	必须	空格分隔的令牌请求作用域的列表。有关详细信息，请参阅作用域。
`requested_token_use`	必选	指定应如何处理请求。在 OBO 流中，该值必须设置为 `on_behalf_of`。

示例

以下 HTTP POST 通过 user.read 作用域请求 https://graph.microsoft.com Web API 的访问令牌和刷新令牌。请求使用客户端密码进行签名，并由机密客户端发出。

//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=00001111-aaaa-2222-bbbb-3333cccc4444
&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`	必须	Microsoft Entra 管理中心 - 应用注册页分配给应用的“应用程序（客户端）ID”。
`client_assertion_type`	必须	值必须是 `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`。
`client_assertion`	必选	断言（JSON Web 令牌），需使用作为凭据向应用程序注册的证书进行创建和签名。若要了解如何注册证书以及断言的格式，请参阅证书凭据。
`assertion`	必须	已发送到中间层 API 的访问令牌。此令牌必须包含发出此 OBO 请求的应用（由 `client-id` 字段表示的应用）的受众 (`aud`) 声明。应用程序无法兑换其他应用的令牌（例如，如果客户端向 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 作用域请求具有证书的 https://graph.microsoft.com Web API 的访问令牌。请求使用客户端密码进行签名，并由机密客户端发出。

// 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=11112222-bbbb-3333-cccc-4444dddd5555
&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`	指示令牌类型值。 Microsoft 标识平台支持的唯一类型是 `Bearer`。有关持有者令牌的详细信息，请参阅 OAuth 2.0 授权框架：持有者令牌用法 (RFC 6750)。
`scope`	令牌中授予的访问权限的范围。
`expires_in`	访问令牌有效的时间长度（以秒为单位）。
`access_token`	请求的访问令牌。调用方服务可以使用此令牌向接收方服务进行身份验证。
`refresh_token`	所请求的访问令牌的刷新令牌。当前访问令牌过期后，调用方服务可以使用此令牌请求另一个访问令牌。仅当已请求 `offline_access` 作用域时提供刷新令牌。

成功响应示例

以下示例演示对 https://graph.microsoft.com Web API 的访问令牌请求的成功响应。响应包含访问令牌和刷新令牌，并使用证书的私钥进行签名。

{
    "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}"
}

此访问令牌是 v1.0 格式的 Microsoft Graph 令牌。这是因为令牌格式基于所访问的资源，而与请求它时使用的终结点无关。 Microsoft Graph 设置为接受 v1.0 令牌，因此当客户端请求 Microsoft Graph 的令牌时，Microsoft 标识平台会生成 v1.0 访问令牌。其他应用可能指示它们需要 v2.0 格式的令牌、1.0 格式的令牌甚至专用或加密格式的令牌。 v1.0 和 v2.0 终结点都可以发出任意一种令牌格式。这样，无论客户端如何或在何处请求令牌，资源始终可以获取正确的令牌格式。

警告

请勿尝试在代码中验证或读取你未拥有的任何 API 的令牌，包括此示例中的令牌。 Microsoft 服务的令牌可以使用将不会作为 JWT 进行验证的特殊格式，还可能会针对使用者（Microsoft 帐户）用户进行加密。虽然可以通过读取令牌的操作进行调试和学习，但请不要在代码中依赖此操作，也不要假定不是你控制的 API 的令牌的相关具体信息。

错误响应示例

如果已对下游 API 设置条件访问策略（如多重身份验证），则在尝试获取下游 API 的访问令牌时，令牌终结点会返回错误响应。中间层服务应向客户端应用程序显示此错误，以便客户端应用程序可以提供用户交互，以满足条件访问策略。

为了向客户端返回此错误，中间层服务会使用“HTTP 401 未授权”以及包含错误和声明质询的 WWW-Authenticate HTTP 标头进行答复。客户端必须解析此标头并通过提出声明质询（如果存在）从令牌颁发者处获取新令牌。客户端不应重新尝试使用缓存的访问令牌访问中间层服务。

{
    "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 'aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb'.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: 2017-05-01 22:43:20Z",
    "error_codes":[50079],
    "timestamp":"2017-05-01 22:43:20Z",
    "trace_id":"0000aaaa-11bb-cccc-dd22-eeeeee333333",
    "correlation_id":"aaaa0000-bb11-2222-33cc-444444dddddd",
    "claims":"{\"access_token\":{\"polids\":{\"essential\":true,\"values\":[\"00aa00aa-bb11-cc22-dd33-44ee44ee44ee\"]}}}"
}

使用访问令牌访问受保护资源

现在，中间层服务可以通过在 Authorization 标头中设置令牌，使用之前获取的令牌向下游 Web API 发出身份验证请求。

示例

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

使用 OAuth2.0 OBO 流获得的 SAML 断言

某些基于 OAuth 的 Web 服务需要访问在非交互式流中接受 SAML 断言的其他 Web 服务 API。 Microsoft Entra ID 可以提供 SAML 断言，以响应将基于 SAML 的 Web 服务用作目标资源的代理流。

这是非标准的 OAuth 2.0 代理流扩展，它允许基于 OAuth2 的应用程序访问使用 SAML 令牌的 Web 服务 API 终结点。

提示

当从前端 Web 应用程序调用受 SAML 保护的 Web 服务时，只需调用 API 并使用用户的现有会话启动正常的交互式身份验证流。当服务到服务调用需要 SAML 令牌来提供用户上下文时，只需使用 OBO 流。

使用带共享密钥的 OBO 请求获取 SAML 令牌

SAML 断言的服务到服务请求包含以下参数：

参数	类型	说明
grant_type	必需	令牌请求的类型。对于使用 JWT 的请求，该值必须是 `urn:ietf:params:oauth:grant-type:jwt-bearer`。
assertion	必需	请求中使用的访问令牌值。
client_id	（必需）	在注册到 Microsoft Entra ID 期间分配给调用服务的应用 ID。要在 Microsoft Entra 管理中心内查找应用 ID，请浏览至“标识”>“应用程序”>“应用注册”，然后选择应用程序名称。
client_secret	（必需）	在 Microsoft Entra ID 中为调用服务注册的密钥。注册时应已记下此值。还支持根据 RFC 6749 在授权标头中提供凭据的基本身份验证模式。
scope	必需	空格分隔的令牌请求范围的列表。有关详细信息，请参阅作用域。 SAML 本身没有范围的概念，但可用于标识你要接收令牌的目标 SAML 应用程序。对于此 OBO 流，范围值必须始终为追加有 `/.default` 的 SAML 实体 ID。例如，如果 SAML 应用程序的实体 ID 为 `https://testapp.contoso.com`，则请求的范围应为 `https://testapp.contoso.com/.default`。如果实体 ID 不是以 URI 方案开头（例如，`https:`），则 Microsoft Entra 用 `spn:` 作为实体 ID 的前缀。在这种情况下，必须请求范围 `spn:<EntityID>/.default`，例如，如果实体 ID 为 `testapp`，则请求的范围为 `spn:testapp/.default`。此处请求的范围值用于确定 SAML 令牌中生成的 `Audience` 元素，这对于接收令牌的 SAML 应用程序可能非常重要。
requested_token_use	必需	指定应如何处理请求。在代理流中，该值必须是 `on_behalf_of`。
requested_token_type	必需	指定请求令牌的类型。值可以是 `urn:ietf:params:oauth:token-type:saml2` 或 `urn:ietf:params:oauth:token-type:saml1`，具体取决于所访问资源的要求。

响应包含以 UTF8 和 Base 64url 编码的 SAML 令牌。

源自 OBO 调用的 SAML 断言的 SubjectConfirmationData：如果目标应用程序需要 SubjectConfirmationData 中的 Recipient 值，则该值必须配置为资源应用程序配置中的非通配符回复 URL。由于默认回复 URL 不用于确定 Recipient 值，因此可能必须在应用程序配置中对回复 URL 进行重新排序，以确保使用第一个非通配符回复 URL。有关详细信息，请参阅回复 URL。
SubjectConfirmationData 节点：此节点不能包含 InResponseTo 属性，因为它不是 SAML 响应的一部分。接收 SAML 令牌的应用程序必须能够在没有 InResponseTo 属性的情况下接受 SAML 断言。
API 权限：必须在中间层应用程序上添加必要的 API 权限以允许访问 SAML 应用程序，使它可以为 SAML 应用程序的 /.default 范围请求令牌。
许可：必须授予许可，才能接收包含 OAuth 流上用户数据的 SAML 令牌。有关信息，请参阅获取中间层应用程序的同意。

使用 SAML 断言进行响应

参数	说明
token_type	指示令牌类型值。 Microsoft Entra ID 支持的唯一类型是 Bearer。有关持有者令牌的详细信息，请参阅 OAuth 2.0 授权框架：持有者令牌用法 (RFC 6750)。
scope	令牌中授予的访问权限的范围。
expires_in	访问令牌有效的时间长度（以秒为单位）。
expires_on	访问令牌的过期时间。该日期表示为自 1970-01-01T0:0:0Z UTC 至过期时间的秒数。此值用于确定缓存令牌的生存期。
resource	接收服务（受保护资源）的应用 ID URI。
access_token	返回 SAML 断言的参数。
refresh_token	刷新令牌。当前 SAML 断言过期后，调用方服务可以使用此令牌请求另一个访问令牌。

token_type：持有者
expires_in：3296
ext_expires_in：0
expires_on：1529627844
资源：https://api.contoso.com
access_token：<SAML 断言>
issued_token_type: urn:ietf:params:oauth:token-type:saml2
refresh_token：<刷新令牌>

OBO 流的目标是确保获得相应许可，以便客户端应用可以调用中间层应用，并且中间层应用有权调用后端资源。根据应用程序的体系结构或使用情况，应该考虑以下各项来确保 OBO 流的成功：

中间层应用程序将客户端添加到其清单中的已知客户端应用程序列表 (knownClientApplications) 中。如果客户端触发了同意提示，则同意流程将同时用于其自身和中间层应用程序。在 Microsoft 标识平台中，此功能是使用 .default 范围实现的。 .default 范围是一个特殊范围，用于请求同意访问应用程序有权访问的所有范围。当应用程序需要访问多个资源，但只应提示用户同意一次时，这很有用。

当使用已知的客户端应用程序和 .default 触发同意屏幕时，同意屏幕将显示客户端到中间层 API 的权限，同时还会请求中间层 API 所需的任何权限。用户同意这两个应用程序，接着 OBO 流便开始工作。

请求中标识的资源服务 (API) 应该是客户端应用程序因用户登录而请求访问令牌的 API。例如，scope=openid https://middle-tier-api.example.com/.default（为中间层 API 请求访问令牌）或 scope=openid offline_access .default（当未识别资源时，默认为 Microsoft Graph）。

无论在授权请求中标识了哪个 API，许可提示都将与为客户端应用配置的所有所需权限相结合。还包括为客户端所需权限列表中列出的每个中间层 API 配置的所有所需权限，这些权限已将客户端标识为已知客户端应用程序。

预授权的应用程序

资源可以指示给定应用程序始终具有接收某些范围的权限。这用于使前端客户端和后端资源之间的连接更顺畅。资源可以在其清单中声明多个预授权应用程序 (preAuthorizedApplications)。任何此类应用程序都可以在 OBO 流中请求这些权限，并在未经用户同意的情况下接收这些权限。

租户管理员可以通过为中间层应用程序提供管理员同意，保证应用程序有权调用其所需的 API。为此，管理员可以在其租户中找到中间层应用程序，打开“所需的权限”页面，然后选择为应用授予权限。若要详细了解管理员同意功能，请参阅同意和权限文档。

使用单一应用程序

在某些情况下，可能只有一对中间层和前端客户端。在这种情况下，你可能会发现将其作为单一应用程序更轻松，完全无需使用中间层应用程序。若要在前端和 Web API 之间进行身份验证，可以使用 cookie、id_token 或为应用程序本身请求的访问令牌。然后，从此单一应用程序请求同意后端资源。

另请参阅

详细了解 OAuth 2.0 协议和使用客户端凭据执行服务到服务身份验证的其他方法。

通过

Microsoft 标识平台和 OAuth 2.0 代理流

客户端限制

协议图

中间层访问令牌请求

第一种情况：使用共享机密访问令牌请求

示例

第二种情况：使用证书访问令牌请求

示例

中间层访问令牌响应

成功响应示例

错误响应示例

使用访问令牌访问受保护资源

示例

使用 OAuth2.0 OBO 流获得的 SAML 断言

使用带共享密钥的 OBO 请求获取 SAML 令牌

使用 SAML 断言进行响应

预授权的应用程序

使用单一应用程序

另请参阅

反馈

其他资源

通过

Microsoft 标识平台和 OAuth 2.0 代理流

客户端限制

协议图

中间层访问令牌请求

第一种情况：使用共享机密访问令牌请求

示例

第二种情况：使用证书访问令牌请求

示例

中间层访问令牌响应

成功响应示例

错误响应示例

使用访问令牌访问受保护资源

示例

使用 OAuth2.0 OBO 流获得的 SAML 断言

使用带共享密钥的 OBO 请求获取 SAML 令牌

使用 SAML 断言进行响应

为中间层应用程序获得同意

.default 和组合同意

预授权的应用程序

管理员同意

使用单一应用程序

另请参阅

反馈

其他资源