1. OAuth2.0 协议基础

1.1 四种授权模式概述

OAuth2.0 协议定义了四种核心授权模式,分别适用于不同的客户端类型与安全场景。下表从客户端类型、安全等级、典型场景三个维度进行对比:

授权模式 客户端类型 安全等级 典型场景
授权码模式(Authorization Code) Web 服务端应用 高 用户登录第三方网站(如 GitHub 登录)
隐式模式(Implicit) 纯前端 SPA 中 浏览器单页应用(已逐步被 PKCE 替代)
密码模式(Resource Owner Password Credentials) 受信任第一方应用 低 自有移动端 App 直接登录(不推荐)
客户端凭证模式(Client Credentials) 后端服务 / 机器对机器 高 微服务间 API 调用、定时任务、后台批处理
安全提示: 隐式模式因 access_token 直接暴露在 URL 片段中,已被 IETF 安全最佳实践(RFC 9700)标记为不推荐。密码模式因需要收集用户明文密码,仅在高度信任的遗留系统中使用。客户端凭证模式是唯一不涉及用户委托的纯后端模式。

1.2 客户端凭证模式(Client Credentials)

适用场景

客户端凭证模式专为机器对机器(M2M)通信设计,适用于以下场景:

  • 微服务间内部 API 调用:服务 A 需要调用服务 B 的受保护资源,无需用户上下文。
  • 后台定时任务与批处理:如数据同步、报表生成、日志归档等自动化作业。
  • API 网关与第三方平台集成:后端服务向外部 API 发起认证请求,如支付网关、消息推送。
  • CLI 工具与运维脚本:通过 client_id + client_secret 获取临时令牌执行管理操作。
核心特征: 客户端凭证模式不涉及最终用户(Resource Owner),客户端直接使用自身凭证向授权服务器请求 access_token。该模式要求客户端能够安全保管 client_secret,因此仅适用于后端机密型客户端。

核心流程

客户端凭证模式的完整交互流程包含以下 5 个步骤:

  1. 客户端注册:后端服务在授权服务器注册,获取 client_id 和 client_secret。
  2. 发起令牌请求:客户端使用 client_id 和 client_secret 向授权服务器的 /token 端点发送 POST 请求。
  3. 授权服务器验证:服务器验证客户端凭证有效性,确认客户端有权访问指定 scope。
  4. 下发 access_token:验证通过后,服务器返回 access_token 及可选的 expires_in、token_type。
  5. 访问受保护资源:客户端在 HTTP 请求头中携带 Authorization: Bearer <access_token> 调用目标 API。
客户端凭证模式核心流程 后端服务(客户端) 授权服务器 资源服务器(API) ① 注册 client_id/secret ② POST /token (client_id, client_secret, grant_type=client_credentials) ③ 验证凭证与 scope ④ 返回 access_token + expires_in ⑤ GET /api/resource (Authorization: Bearer <access_token>)

令牌请求示例

客户端向授权服务器发起令牌请求的 HTTP 报文如下:

POST /oauth/token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=your_client_id
&client_secret=your_client_secret
&scope=read write

授权服务器成功响应示例:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "read write"
}
安全合规要点:
  • client_secret 必须存储在服务端环境变量或密钥管理服务(KMS)中,禁止硬编码在代码仓库。
  • 令牌请求必须使用 HTTPS 传输,防止中间人窃听凭证。
  • access_token 应设置合理的过期时间(通常 15 分钟~1 小时),避免长期有效令牌泄露风险。
  • scope 遵循最小权限原则,仅申请当前服务实际需要的权限范围。

与其它模式的对比

对比维度 客户端凭证模式 授权码模式 密码模式
用户参与 无用户交互 需要用户授权 需要用户密码
凭证类型 client_id + client_secret 授权码 + client_secret 用户名 + 密码
刷新令牌 通常不支持(可重新请求) 支持 refresh_token 支持 refresh_token
适用客户端 机密型后端服务 Web 服务端应用 受信任第一方应用
安全风险 凭证泄露、令牌滥用 CSRF、授权码拦截 密码泄露、暴力破解
客户端凭证模式在微服务架构中的位置 订单服务 (客户端) 授权服务器 (OAuth 2.0) 库存服务 (资源服务器) 请求令牌 携带令牌调用 架构说明 订单服务作为客户端,使用 client_credentials 获取令牌后调用库存服务 API。 整个过程无用户参与,令牌仅代表订单服务自身的身份与权限。
压测关注点: 客户端凭证模式在压测中需重点关注授权服务器的令牌颁发吞吐量、令牌缓存策略、client_secret 轮换机制以及 access_token 的过期重试逻辑。这些指标直接影响后端服务的可用性与合规性。