Google OAuth 支持刷新令牌密钥绑定

传统的 OAuth Bearer token 采用“谁捡到就归谁”的模式，因此容易受到 Infostealer 恶意软件（例如 RedLine、NodeStealer）和 Adversary-in-the-Middle（AiTM，中间人对手）攻击。

DPoP（Demonstrating Proof-of-Possession，持有证明）是一种应用层 OAuth 2.0 安全规范（RFC 9449）。它在应用层通过密码学方式，将 token 与客户端生成的非对称密钥对绑定，从而化解 token 窃取和重放攻击：即使 token 被盗，没有对应的私钥，也无法重放使用。

本文将介绍在哪些场景下、如何采用 DPoP，并说明 Google 的具体 DPoP 实现。我们还提供了一份用于采用 DPoP 的 SKILL.md，帮助你完成实现。

RFC 9449 将部分可选功能和实现决策交由 Google 这样的授权提供方决定。Google Identity 及其 OAuth Platform 是面向开发者的服务，工程师可以通过它们实现 OAuth 2.0，以及 DPoP 这类密码学安全控制，保护 API 集成。另外，Google Workspace Context-Aware Access（CAA）也利用 DPoP，在 Agent Gateway 通过密码学方式验证 Agent 身份，从而保护 Gemini Enterprise Agent Platform 上的企业 AI 工作负载。

Google 的 OAuth Platform 专门支持将 refresh token 与 DPoP 绑定。这一设计体现了务实的工程权衡：对长期有效的 refresh token 施加发送方约束，可以消除攻击者持续离线冒充身份的主要途径。与此同时，短期有效的 access token 仍采用标准 Bearer token，确保高 QPS 的资源 API 不必为每次请求承担 DPoP 非对称密码学验证的开销。这种方式既能为最敏感的凭据提供有力保护，也能保持 Google API 集成的高性能和低延迟。

与标准 Bearer token 流程不同，DPoP 要求客户端生成密码学密钥、严格处理时间戳和 nonce、计算特定的 claim（htm、htu、iat、jti）、精确构造 header，并构建 DPoP proof JWT。这些变化可能带来额外的系统约束，以支持安全的计算、处理和存储。

架构考量

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

遵循这些指导，Google 建议在上述模型中使用 DPoP，为 refresh token 施加发送方约束。

传输层 token 绑定机制（例如 mTLS/RFC 8705）经常会在现代云代理和负载均衡器处失效或终止，而 DPoP 工作在 HTTP header 层面。因此，它能够很好地适应复杂的多跳环境，包括正在兴起的 Model Context Protocol（MCP）和自主 Agent 架构。

深入架构：性能与安全之间的权衡

安全架构师经常会问：既然 DPoP 的设计目的是为 token 施加发送方约束，为什么 Google 的 access token 仍然是标准 Bearer token？

答案在于 Google 规模下的运行扩展能力和性能。验证非对称密码学签名（例如 ES256）需要消耗大量 CPU 周期。如果对高吞吐量 Google 资源服务器（例如 Gmail、Calendar 或 Drive API）的每次 API 调用，都要求验证 DPoP proof，那么 API Gateway 层的计算开销将非常庞大，带来可观测的延迟和扩容成本。

通过将 DPoP 绑定严格限定在 refresh token 上，Google 的架构取得了以下平衡：

• **保护长期有效的凭据：**高度敏感、长期有效的 refresh token 可以用于不断获取新的 access token。通过密码学方式将它绑定到客户端密钥对后，即使被窃取，攻击者也无法使用。
• **保持高性能的请求处理：**短期有效的 access token（有效期通常为 1 小时或更短）仍然采用标准 Bearer token。这确保了绝大多数 API 请求无需承担任何密码学验证开销，保持开发者期望的 Google API 高性能和低延迟。

互补的保护机制：DPoP 与 DBSC

DPoP 是保护 OAuth 2.0 token 的强大工具，但也需要理解它的保护边界。

DPoP 不保护标准 Web 应用的会话 cookie，而这些 cookie 仍是 Infostealer 恶意软件的主要攻击目标。为应对 cookie 窃取问题，Google 和 Web Incubator Community Group（WICG）正在积极开发 Device Bound Session Credentials（DBSC）。DPoP 工作在应用层，为公开客户端和机密客户端的 API token 提供保护；DBSC 则工作在浏览器和网络层，通过密码学方式，将浏览器会话 cookie 绑定到设备硬件（例如 TPM）。DPoP 与 DBSC 相互配合，构成全面的纵深防御策略，抵御针对 API 会话和 Web 用户会话的凭据窃取。

多 Agent 委托与 Model Context Protocol（MCP）

随着自主 AI Agent 和 Model Context Protocol（MCP）架构的兴起，保护工具调用所用的 token 变得至关重要。尽管 DPoP 在客户端到服务器的单跳连接中适应性很强，多 Agent 工作流仍然会带来委托难题，例如 Agent A 将任务委托给 Agent B，再由 Agent B 调用 Resource C。

在多 Agent 调用链中，如果无法访问 Agent A 的私钥，Agent B 就不能代表 Agent A 签署 DPoP proof，而共享私钥又违背了 DPoP 的核心安全原则。由于 Google 面向普通用户的核心 OAuth 端点（oauth2.googleapis.com）不支持 OAuth 2.0 Token Exchange（RFC 8693），构建多 Agent 或联合云工作负载的开发者应考虑使用 Google Cloud Secure Token Service（STS）。通过 STS 进行委托，中间 Agent 可以将上游 token 换成一个新的、短期有效的联合 token，并通过密码学方式将其绑定到自身的本地密钥对。这样就能在不暴露密钥的前提下，让整个 Agent 调用链始终保持发送方约束的安全模型。

请参阅我们的 DPoP Adoption Guide 和用于采用 DPoP 的 SKILL.md，从今天开始提升平台安全性。