谷歌为OAuth 2.0刷新令牌引入DPoP防护

谷歌 OAuth 平台近日新增对 DPoP（Demonstrating Proof-of-Possession）的支持，用于缓解 OAuth 2.0 令牌遭窃取和重放的问题。传统持有者令牌遵循“持有即可使用”的规则，可能被 RedLine、NodeStealer 等信息窃取恶意软件或中间人攻击者获取并滥用。DPoP 会将令牌与客户端生成的非对称密钥对绑定，即使令牌泄露，缺少对应私钥的攻击者也无法完成有效重放。

目前该机制仅应用于刷新令牌，寿命较短的访问令牌仍保持标准持有者模式。谷歌的取舍是优先保护长期有效、容易成为持续身份冒用入口的刷新令牌，同时避免让每次 API 请求都承担非对称密码校验带来的性能成本。启用 DPoP 后，客户端需要自行生成并安全保存密钥，还要正确处理时间戳和随机数，构造符合要求的 HTTP 请求头及 DPoP 证明 JWT。

DPoP 主要保护 API 令牌，并不能解决标准 Web 会话 Cookie 被盗的问题。针对 Infostealer 窃取 Cookie 的风险，谷歌与 Web 孵化器社区组正在开发设备绑定会话凭证（DBSC）。该方案在浏览器和网络层工作，计划利用 TPM 等硬件能力，把会话 Cookie 通过密码学方式绑定到具体设备。DPoP 与 DBSC 可分别覆盖 API 凭证和 Web 会话，形成纵深防御。

谷歌同时指出，DPoP 不适合多智能体工作流中的直接委托。若第二个智能体代表第一个智能体签名，就必须获得第一个智能体的私钥，这与密钥不可转交的设计目标冲突。更合适的做法是通过谷歌云安全令牌服务（STS）完成令牌交换：中间智能体将上游令牌换成新的短期联邦令牌，并使用自身密钥对进行绑定，从而避免暴露上游私钥。

由于 DPoP 私钥保存在客户端，整体安全性仍取决于客户端环境。浏览器中的单页应用无法完全阻止密钥被恶意代码滥用，因此面向浏览器应用的 IETF 指南建议采用 Backend-for-Frontend 架构，把令牌和加密密钥置于浏览器之外；在服务器基础设施暂时不可用的场景，也可考虑零持久化方案。