Google OAuth 支持 DPoP，为 refresh token 增加持有证明绑定

传统的 OAuth 持有者令牌（bearer token）遵循“谁捡到归谁”的模式，使其容易受到 Infostealer 恶意软件（例如 RedLine、NodeStealer）和中间人对手（AiTM）攻击的侵害。

DPoP（Demonstrating Proof-of-Possession，证明持有权）是一种应用层 OAuth 2.0 安全配置文件（RFC 9449），它通过在应用层将令牌与客户端生成的非对称密钥对进行加密绑定，从而中和令牌窃取和重放攻击，确保即使令牌被盗，没有相应的私钥也无法重放。

本文旨在向你说明在何处以及如何采用 DPoP，并介绍 Google 具体的 DPoP 实现。此外还提供了一份 DPoP 采用SKILL.md，以帮助实现 DPoP。

RFC 9449 中的一些可选功能和实现决策被委托给作为授权提供方的 Google。Google Identity 及其 OAuth Platform 作为面向开发者的服务运行，工程师在其中实现 OAuth 2.0 以及诸如 DPoP 之类的加密安全控制，以保护 API 集成。另外，Google Workspace Context-Aware Access（CAA）利用 DPoP 在 Gemini Enterprise Agent Platform 上保护企业 AI 工作负载，通过在 Agent Gateway 对代理身份进行加密验证。

Google 的 OAuth Platform 专门针对刷新令牌支持 DPoP 绑定。这一设计选择反映了一种务实的工程权衡：通过对长期有效的刷新令牌进行发送方约束，我们消除了持久离线冒充的主要途径。同时，短期访问令牌仍为标准持有者令牌，确保高 QPS 的资源 API 不会承担 DPoP 每次请求的非对称加密验证开销。这种方法为你最敏感的凭据提供了强有力的保护，同时保持 Google API 集成的高性能和低延迟。

与标准持有者令牌流程不同，DPoP 需要客户端生成加密密钥、严格处理时间戳和 nonce、计算特定声明（htm、htu、iat、jti）、精确构造标头以及构造 DPoP 证明 JWT。这些变更可能会引入额外的系统约束，以支持安全的计算、处理和存储。

架构考量

IETF 的 OAuth 2.0 安全最佳当前实践（RFC 9700）讨论了发送方约束的刷新令牌。此外，OAuth 2.0 for Browser-Based Applications IETF 草案讨论了三种模型：Backend-for-Frontend（BFF）、Token-Mediating Backend 和 Browser-based OAuth Client。

遵循这一指导，Google 建议在这些模型中使用 DPoP 对刷新令牌进行发送方约束。

与传输层令牌绑定（例如 mTLS/RFC 8705）不同——后者在现代云代理和负载均衡器处常常中断或终止——DPoP 在 HTTP 标头层面运行。这使其在复杂的多跳环境中具有高度韧性，包括新兴的模型上下文协议（MCP）和自主代理架构。

架构深入探讨：性能与安全的权衡

安全架构师常问的一个问题是：如果 DPoP 旨在对令牌进行发送方约束，为什么 Google 的访问令牌仍然是标准持有者令牌？

答案在于 Google 规模下的运维扩展与性能。验证非对称加密签名（如 ES256）需要大量 CPU 周期。如果对高吞吐量 Google 资源服务器（如 Gmail、Calendar 或 Drive API）的每次 API 调用都需要验证 DPoP 证明，那么 API 网关层的计算开销将非常巨大，带来可观的延迟和扩展成本。

通过将 DPoP 绑定严格限制在刷新令牌上，Google 的架构实现了平衡：

长期凭证受保护： 高度敏感、长期有效的刷新令牌（可用于无限期获取新的访问令牌）被加密绑定到客户端的密钥对。即使被窃取，对攻击者来说也毫无用处。

高性能服务： 短期访问令牌（通常有效期为 1 小时或更短）仍为标准 Bearer 令牌。这确保绝大多数 API 请求不产生任何加密验证开销，保持开发者期望的 Google API 高性能和低延迟。

互补保护：DPoP 与 DBSC

DPoP 是保护 OAuth 2.0 令牌的强大工具，但了解其边界很重要。

DPoP 不保护标准 Web 应用程序会话 Cookie，而后者仍是 Infostealer 恶意软件的主要目标。为应对 Cookie 窃取，Google 和 Web 孵化器社区组（WICG）正在积极开发 设备绑定会话凭证（DBSC）。DPoP 在应用层运行，为公共和机密客户端保护 API 令牌；而 DBSC 在浏览器和网络层运行，将浏览器会话 Cookie 加密绑定到设备硬件（如 TPM）。DPoP 和 DBSC 共同构成纵深防御策略，全面抵御 API 和基于 Web 的用户会话中的凭证窃取。

多代理委托与模型上下文协议（MCP）

随着自主 AI 代理和 模型上下文协议（MCP） 架构的出现，保护工具使用令牌变得至关重要。虽然 DPoP 在单跳客户端到服务器连接中具有高度弹性，但多代理工作流（其中代理 A 将任务委托给代理 B，代理 B 再调用资源 C）引入了委托挑战。

在多代理链中，代理 B 无法在未访问代理 A 私钥的情况下代表代理 A 签署 DPoP 证明——而共享私钥违反了 DPoP 的核心安全原则。由于 Google 的核心消费者 OAuth 端点（oauth2.googleapis.com）不支持 OAuth 2.0 令牌交换（RFC 8693），构建多代理或联合云工作负载的开发者应考虑 Google Cloud 安全令牌服务（STS）。通过 STS 路由委托，中间代理可以将上游令牌交换为新的、短期有效的联合令牌，并将其加密绑定到自己的本地密钥对，从而在整个代理链中保持发送方约束的安全模型，且不会暴露密钥。

请参阅我们的 DPoP 采用指南、我们的 DPoP 采用 SKILL.md，立即提升您的平台安全性。