OAuth 2.0 客户端凭据授予流程

一段话总结

本文主要介绍 OAuth 2.0 客户端凭据授予流程在 Microsoft Entra ID 中的应用，允许应用通过自身凭据（如客户端密钥、证书或联合凭证）获取访问令牌 ，无需用户交互，适用于服务器间后台交互场景。文中详细说明了权限授予方式（ACL 或应用权限） 、** 获取令牌的三种请求方式（共享密钥、证书、联合凭证）** 及请求参数，并提供了代码示例和错误处理说明，强调应优先使用 MSAL 库而非直接调用协议。

思维导图

令牌使用（Authorization: Bearer）

令牌请求（/token endpoint）

管理员同意权限（/adminconsent）

联合凭证（外部IDP生成的JWT）

证书（client_assertion）

共享密钥（client_secret）

应用权限：管理员分配，需暴露app角色

ACL访问控制列表：基于应用ID校验

注意事项：优先使用MSAL库，避免硬编码凭据

关键步骤

令牌获取方式

权限授予方式

适用场景：服务器间无用户交互的后台认证

OAuth 2.0客户端凭据流核心流程

令牌使用（Authorization: Bearer）

令牌请求（/token endpoint）

管理员同意权限（/adminconsent）

联合凭证（外部IDP生成的JWT）

证书（client_assertion）

共享密钥（client_secret）

应用权限：管理员分配，需暴露app角色

ACL访问控制列表：基于应用ID校验

注意事项：优先使用MSAL库，避免硬编码凭据

关键步骤

令牌获取方式

权限授予方式

适用场景：服务器间无用户交互的后台认证

OAuth 2.0客户端凭据流核心流程

详细总结

一、客户端凭据流概述

OAuth 2.0 客户端凭据授予流程 允许机密客户端（如 Web 服务）通过自身凭据（非用户身份）访问资源，适用于服务器间后台交互（如守护进程、服务账户）。核心特点包括：

无用户交互：通过管理员预先授予应用权限，无需用户登录。
权限类型 ：支持ACL（访问控制列表）或应用权限（App Roles） ，后者需在 API 注册中暴露角色并由管理员分配。
凭据类型 ：支持客户端密钥（Shared Secret） 、证书（Certificate）或联合凭证（Federated Credential） ，需严格保护凭据安全。

二、权限授予方式

方式	原理	适用场景
ACL 访问控制	资源服务器通过应用 ID（`appid`）和颁发者（`iss`）校验权限，不依赖`roles`声明。	个人微软账户数据访问、测试环境。
应用权限	管理员为应用分配 API 暴露的`app角色`，令牌包含`roles`声明。	企业数据访问（如 Microsoft Graph）。

管理员同意流程 ：

通过/adminconsent端点请求权限，示例 URL：

http

bash 复制代码

GET https://login.microsoftonline.com/{tenant}/adminconsent?client_id=xxx&redirect_uri=xxx

成功响应：返回tenant、state、admin_consent=True。
错误响应：返回error=permission_denied等信息。

三、令牌获取方式

1. 共享密钥（Client Secret）

请求示例：

http

bash 复制代码

POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded
client_id=xxx&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&client_secret=xxx&grant_type=client_credentials

关键参数：

scope：需为资源 ID+.default（如https://graph.microsoft.com/.default），仅支持单一资源。
client_secret：需 URL 编码，或通过 Basic Auth 传递。

2. 证书（Certificate）

请求示例：

http

ini 复制代码

POST ...
client_id=xxx&scope=...&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion=JWT_TOKEN&grant_type=client_credentials

关键参数：

client_assertion：需用注册证书签名的 JWT 令牌，包含sub（客户端 ID）、aud（令牌颁发者）等声明。

3. 联合凭证（Federated Credential）

请求示例 ：

与证书方式类似，但client_assertion由外部身份提供者（如 Kubernetes）生成，适用于跨云场景。

四、令牌使用与响应

成功响应：

json

json 复制代码

{
  "access_token": "JWT_TOKEN",
  "token_type": "Bearer",
  "expires_in": 3599 // 有效期1小时
}

错误响应示例：

json

json 复制代码

{
  "error": "invalid_scope",
  "error_description": "无效的scope参数",
  "error_codes": [70011]
}

五、最佳实践与注意事项

优先使用 MSAL 库：避免直接调用协议，MSAL 自动处理令牌缓存、更新等细节。
凭据安全：禁止硬编码密钥，使用环境变量或密钥管理服务（如 Azure Key Vault）。
权限最小化：仅请求必要权限，定期轮换凭据。

关键问题

1. 客户端凭据流与用户凭据流的核心区别是什么？

答案：客户端凭据流使用应用自身凭据 （如密钥、证书）进行认证，无需用户参与，适用于服务器间交互；而用户凭据流（如授权码流）依赖用户登录并授权，适用于需要用户身份的场景。

2. 为什么推荐使用应用权限而非 ACL？

答案：应用权限通过 Microsoft Entra ID 集中管理，支持角色 - Based 访问控制（RBAC），适合企业场景；ACL 需资源服务器自行维护应用 ID 列表，扩展性较差，且不支持roles声明，安全性较低。

3. 使用证书进行令牌请求时，JWT 断言需包含哪些关键声明？

答案：

sub：客户端 ID（client_id）。
aud：令牌颁发者（如https://login.microsoftonline.com/{tenant}/v2.0）。
iss：证书持有者（通常与sub一致）。
exp：过期时间（建议不超过 10 分钟）。
jti：唯一标识符，防止重放攻击。