谷歌采用 DPoP 增强 OAuth 2.0，抵御令牌窃取与重放攻击

谷歌 OAuth 平台最近新增了对 Demonstrating Proof-of-Possession（DPoP）的支持，这是一种 OAuth 2.0 安全机制，用于缓解令牌盗取和重放攻击。

传统的 OAuth 持有者令牌（Bearer Token）遵循“谁拿到、谁可用”的模式，容易遭到信息窃取恶意程序（例如 RedLine、NodeStealer）以及中间人攻击者（AiTM）的攻击。

为防范这类攻击，DPoP 通过密码学将令牌绑定到客户端生成的一对非对称密钥上。因此，就算令牌被盗，攻击者没有对应的私钥也无法重放使用，而私钥始终由客户端保管。

谷歌 OAuth 平台仅对刷新令牌启用 DPoP，寿命较短的访问令牌仍然使用标准的持有者令牌。之所以这样设计，是因为长效刷新令牌是“长期在线身份冒用的主要攻击入口”，而如果给访问令牌也加上 DPoP，会让每一次请求都产生非对称密码校验开销。

值得注意的是，启用 DPoP 增加了几个客户端要求，包括生成加密密钥、正确处理时间戳和随机数、生成适当的 HTTP 请求头和所需的 DPoP 证明 JWT。

虽然 DPoP 为 API 令牌提供了保护，但它并不能保护标准的 Web 应用程序会话 Cookie，Cookie 仍然容易受到 Infostealer 恶意软件的攻击。为了应对 Cookie 盗窃的威胁，谷歌和 Web 孵化器社区组（WICG）正在开发设备绑定会话凭证（Device-Bound Session Credentials，DBSC）。

DBSC 在浏览器和网络层运行，通过密码学将浏览器会话 Cookie 绑定到设备的硬件（如 TPM）。DPoP 和 DBSC 共同构成了针对 API 和 Web 用户会话凭证盗窃的纵深防御策略。

谷歌还指出，DPoP 不适用于多智能体工作流，因为一个智能体很难把任务委托给另一个智能体。这要求第二个智能体代表第一个智能体对请求进行签名，必须拿到第一个智能体生成的私钥，而这违反了 DPoP。作为替代方案，谷歌建议开发者使用谷歌云安全令牌服务（STS）。

通过 STS 路由委托，中间智能体可以将上游令牌交换为新的、短期的联邦令牌，这个新令牌绑定到它自己的本地密钥对，从而在整个智能体链中保持发送者约束的安全模型，而不用暴露私钥。

由于 DPoP 私钥保存在客户端，安全性最终取决于客户端本身的安全性。然而，正如 Dhruv Agnihotri 所论证的，在浏览器中运行的单页应用（SPA）并不能完全防止密钥被滥用。因此，IETF 针对浏览器端应用的指南建议采用 Backend-for-Frontend 模式，将令牌和加密密钥保存在浏览器之外。Agnihotri 还提出了一种_零持久化方法_，当服务器端基础设施不可用时，这可能很有用。

查看英文原文：https://www.infoq.com/news/2026/10/google-dpop-oauth2/