Bearer 令牌(持有者令牌).

Bearer 令牌仅凭"持有"完成认证:任何能向 API 出示该令牌的人都能获得其代表的访问权限。它通常承载在 HTTP Authorization: Bearer 头中,由 RFC 6750 在 OAuth 2.0 框架下定义。由于不存在持有证明,Bearer 令牌必须经 TLS 传输、谨慎存储、范围最小、且生命周期较短。更强的替代是与发送方绑定的令牌,如 DPoP、mTLS 绑定令牌或 Token Binding。泄露的 Bearer 令牌在被撤销或过期之前可被即时滥用。

为什么"仅凭持有"的凭据屡屡失守

2023 年的两起事件说明了风险。在 Okta 支持系统入侵事件中(初始访问约在 2023 年 9 月 28 日),攻击者读取了客户上传的 HAR 文件,其中仍包含有效的会话 Cookie 与令牌,并将其重放,进而横向渗透到 BeyondTrust(10 月 2 日)和 Cloudflare(10 月 18 日)等客户。另外,Storm-0558 行动利用窃取的微软签名密钥伪造 Azure AD/MSA 的 Bearer 令牌,悄然访问约 25 家组织的 Exchange Online 邮箱,其中包括美国国务院和商务部。两起事件中,令牌之所以有效正是因为它本身"合法"——这恰恰是 Bearer 语义的根本弱点。

更强的设计能让被窃令牌失效。与发送方绑定(持有证明)的令牌会把凭据绑定到客户端每次调用都必须证明拥有的密钥:应用层的 DPoP(RFC 9449)通过签名的 JWT 头实现,传输层的 mTLS 证书绑定令牌(RFC 8705)通过 cnf.x5t#S256 声明实现。二者都是 FAPI 2.0 规范的强制要求。配套措施包括:短 TTL 配合刷新轮换、限制受众/范围、绑定设备或网络上下文,以及在检测到异常时立即撤销。

flowchart TD
  C[Client] -->|Authorization: Bearer token| API[Resource server]
  API -->|token valid?| API
  API -->|yes| G[Grant access]
  L[Attacker steals token] -->|replays same token| API
  API -.no possession proof.-> G
  subgraph Mitigation
    D["DPoP / mTLS binds token to client key"] --> R[Stolen token rejected]
  end