OAuth 2.0.

OAuth 2.0(RFC 6749)将参与方划分为四种角色:资源所有者(用户)、客户端(应用)、签发令牌的授权服务器,以及承载 API 的资源服务器。客户端通过特定的授权许可(grant)获取访问令牌——交互式应用使用带 PKCE 的授权码(RFC 7636),服务间调用使用 client credentials,输入受限的设备使用 device code(RFC 8628)——之后以 bearer 凭据的形式携带该令牌调用 API。Scope 与 audience 约束令牌能够执行的操作。

安全指引与常见隐患

RFC 9700(BCP 240,发布于 2025 年 1 月)整合了 OAuth 的安全实践:它废弃了 implicit grant 以及 resource owner password credentials grant,要求每一个使用授权码的客户端都必须采用 PKCE,并要求对 redirect URI 进行精确匹配,以挫败授权码截获与开放重定向(open-redirect)攻击。由于访问令牌属于 bearer 凭据,使用 DPoP 或双向 TLS 对其进行发送方绑定(sender-constraining)可以在令牌被窃取后限制重放。

现实中最主要的滥用手法是 OAuth 同意钓鱼(非法同意授权,illicit consent grant):攻击者不去窃取密码,而是注册一个恶意应用并诱骗用户批准广泛的 scope。2017 年 5 月的 "Google Docs" 蠕虫正是通过这种方式在约一小时内扩散,而 APT29/Nobelium 也曾多次滥用 Microsoft 365 的同意授权,以绕过 MFA 实现持久化。防御手段包括管理员同意工作流、发布者验证、短生命周期令牌,以及撤销未使用的授权。

flowchart LR
  U[资源所有者] -->|1 授权 + code_challenge| AS[授权服务器]
  AS -->|2 通过重定向返回授权码| C[客户端应用]
  C -->|3 授权码 + code_verifier| AS
  AS -->|4 访问令牌| C
  C -->|5 bearer 令牌| RS[资源服务器 / API]
  RS -->|6 受保护数据| C