Google OAuth 宣布支持 DPoP：保护刷新令牌安全
英文标题：Announcing DPoP Support for Google OAuth: Securing Refresh Tokens
Google OAuth Platform 现已支持 DPoP（Demonstrating Proof-of-Possession），可将刷新令牌与客户端生成的非对称密钥对进行加密绑定，以抵御 Infostealer 恶意软件和中间对手（AiTM）攻击带来的令牌窃取与重放风险。Google 选择仅对长期有效的刷新令牌实施发送方约束，而短期访问令牌继续采用标准 Bearer Token，以避免高 QPS API 在每次请求中承担非对称签名验证开销。对于多 Agent 和 MCP 场景，Google 建议开发者通过 Google Cloud Secure Token Service（STS）进行令牌委派与交换，而非共享私钥。该能力为 API 集成、企业 AI 工作负载及自主 Agent 架构提供了更强的凭据保护，同时维持 Google API 的性能与低延迟。
11.7 KB
93.0 KB
68.4 KB
64.8 KB
66.5 KB
47.0 KB
39.4 KB
中文
传统 OAuth Bearer Token 遵循“先到先得”的模式，因此容易受到 Infostealer 恶意软件（例如 RedLine、NodeStealer）以及中间对手（Adversary-in-the-Middle，AiTM）攻击的影响。
DPoP（Demonstrating Proof-of-Possession，持有证明）是一种应用层 OAuth 2.0 安全配置文件（RFC 9449）。它通过在应用层将令牌以加密方式绑定至客户端生成的非对称密钥对，消除令牌窃取和重放攻击：即使令牌被盗，攻击者在没有对应私钥的情况下也无法重放该令牌。
本文旨在介绍应在何处以及如何采用 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，在 Gemini Enterprise Agent Platform 的 Agent Gateway 上通过加密验证 Agent 身份，以保护企业 AI 工作负载。
Google OAuth Platform 专门支持对刷新令牌进行 DPoP 绑定。该设计选择体现了一项务实的工程权衡：通过对长期有效的刷新令牌施加发送方约束，我们消除了持续离线冒充攻击的主要途径。与此同时，短期访问令牌仍保持为标准 Bearer Token，确保高 QPS 的资源 API 无需承担每次请求进行 DPoP 非对称加密验证的开销。这种方式既为最敏感的凭据提供了强健保护，又保持了 Google API 集成的高性能和低延迟。
与标准 Bearer Token 流程不同，DPoP 要求客户端生成加密密钥、严格处理时间戳和 nonce、计算特定声明（htm、htu、iat、jti）、精确构造请求头，并构造 DPoP 证明 JWT。这些变化可能会引入额外的系统要求，以支持安全的计算、处理和存储。
架构考量
IETF 的 OAuth 2.0 安全最佳现行实践（RFC 9700）讨论了具备发送方约束的刷新令牌。此外，IETF 的 OAuth 2.0 for Browser-Based Applications 草案讨论了三种模型：Backend-for-Frontend（BFF）、Token-Mediating Backend，以及 Browser-based OAuth Client。
遵循这些指导建议，Google 建议在这些模型中使用 DPoP 对刷新令牌施加发送方约束。
不同于通常会在现代云代理和负载均衡器处中断或终止的传输层令牌绑定机制（例如 mTLS/RFC 8705），DPoP 在 HTTP 请求头层面运行。这使其能够很好地适应复杂的多跳环境，包括新兴的 Model Context Protocol（MCP） 和自主 Agent 架构。
架构深入解析：性能与安全之间的权衡
安全架构师经常提出一个问题：如果 DPoP 的设计目标是对令牌施加发送方约束，为什么 Google 的访问令牌仍然是标准 Bearer Token？
答案在于 Google 规模下的运营扩展性和性能。验证非对称加密签名（例如 ES256）需要大量 CPU 周期。如果对高吞吐量 Google 资源服务器（例如 Gmail、Calendar 或 Drive API）的每一次 API 调用都要求验证 DPoP 证明，API Gateway 层的计算开销将十分庞大，并会带来可测量的延迟和扩展成本。
通过将 DPoP 绑定严格限定在刷新令牌上，Google 的架构实现了以下平衡：
长期凭据受到保护： 高度敏感且长期有效的刷新令牌（可无限期用于获取新的访问令牌）会以加密方式绑定至客户端的密钥对。即使该令牌被窃取，对攻击者也没有用处。
高性能服务： 短期访问令牌（通常有效期为 1 小时或更短）仍是标准 Bearer Token。这确保绝大多数 API 请求不会产生加密验证开销，维持开发者对 Google API 所期待的高性能和低延迟。
互补保护：DPoP 与 DBSC
DPoP 是保护 OAuth 2.0 令牌的强大工具，但理解其保护边界同样重要。
DPoP 不保护标准 Web 应用会话 Cookie，而后者仍是 Infostealer 恶意软件的主要攻击目标。为应对 Cookie 窃取问题，Google 与 Web Incubator Community Group（WICG）正在积极开发 Device Bound Session Credentials（DBSC）。DPoP 在应用层运行，为公共客户端和机密客户端保护 API 令牌；而 DBSC 则在浏览器和网络层运行，将浏览器会话 Cookie 以加密方式绑定至设备硬件（例如 TPM）。DPoP 与 DBSC 共同构成纵深防御策略，保护 API 与基于 Web 的用户会话中的凭据免遭窃取。
多 Agent 委派与 Model Context Protocol（MCP）
随着自主 AI Agent 和 Model Context Protocol（MCP） 架构的发展，保护工具调用令牌变得至关重要。尽管 DPoP 在单跳客户端到服务器连接中具有很强的韧性，但多 Agent 工作流——例如 Agent A 将任务委派给 Agent B，后者再调用资源 C——会带来委派挑战。
在多 Agent 链路中，Agent B 若无法访问 Agent A 的私钥，便无法代表 Agent A 签署 DPoP 证明；而共享私钥又违反 DPoP 的核心安全原则。由于 Google 的核心消费者 OAuth 端点 oauth2.googleapis.com 不支持 OAuth 2.0 Token Exchange（RFC 8693），构建多 Agent 或联邦云工作负载的开发者应考虑使用 Google Cloud Secure Token Service（STS）。通过经由 STS 路由委派流程，中间 Agent 可以将上游令牌交换为一个新的、短期有效的联邦令牌，并将其以加密方式绑定至自身的本地密钥对；这样无需暴露密钥，即可在整个 Agent 链路中保持具备发送方约束的安全模型。
English / 原文
Traditional OAuth bearer tokens operate on a "finders-keepers" model, making them vulnerable to Infostealer malware (e.g. RedLine, NodeStealer) and Adversary-in-the-Middle (AiTM) attacks.
DPoP (Demonstrating Proof-of-Possession) is an application-layer OAuth 2.0 security profile (RFC 9449) that neutralizes token theft and replay attacks by cryptographically binding tokens to a client-generated asymmetric keypair at the application layer, ensuring that even if a token is stolen, it cannot be replayed without the corresponding private key.
This article is meant to inform you on where and how to adopt DPoP and describes Google's specific DPoP implementation. A DPoP adoption SKILL.md is also available to help implement DPoP.
Some optional features and implementation decisions in RFC 9449 are delegated to Google as an authorization provider. Google Identity, and its OAuth Platform, function as a developer-facing service where engineers implement OAuth 2.0 and cryptographic security controls like DPoP to protect API integrations. Separately, Google Workspace Context-Aware Access (CAA) leverages DPoP to secure enterprise AI workloads on the Gemini Enterprise Agent Platform by cryptographically validating agent identities at the Agent Gateway.
Google's OAuth Platform supports DPoP binding specifically for refresh tokens. This design choice reflects a pragmatic engineering tradeoff: by sender-constraining the long-lived refresh token, we neutralize the primary vector for persistent offline impersonation. Meanwhile, short-lived access tokens remain standard Bearer tokens, ensuring that high-QPS resource APIs do not incur the per-request asymmetric cryptographic verification overhead of DPoP. This approach delivers robust protection for your most sensitive credentials while maintaining the high performance and low latency of Google API integrations.
Unlike standard Bearer token flows, DPoP requires client-side cryptographic key generation, strict timestamp and nonce handling, specific claim computation (htm, htu, iat, jti), exact header construction, and DPoP proof JWT construction. These changes may introduce additional system constraints to support secure computation, handling, and storage.
Architectural considerations
The IETF’s Best Current Practice for OAuth 2.0 Security (RFC 9700) discusses sender-constrained refresh tokens. Additionally, the OAuth 2.0 for Browser-Based Applications IETF draft discusses three models: Backend-for-Frontend (BFF), Token-Mediating Backend, and Browser-based OAuth Client.
Following this guidance, Google recommends using DPoP to sender-contrain refresh tokens in these models.
Unlike transport-layer token binding (e.g., mTLS/RFC 8705) which often breaks or terminates at modern cloud proxies and load balancers, DPoP operates at the HTTP header level. This makes it highly resilient for complex, multi-hop environments, including emerging Model Context Protocol (MCP) and autonomous agent architectures.
Architectural Deep-Dive: The Performance-vs-Security Tradeoff
A common question from security architects is: If DPoP is designed to sender-constrain tokens, why are Google's access tokens still standard Bearer tokens?
The answer lies in operational scaling and performance at Google's scale. Verifying asymmetric cryptographic signatures (such as ES256) requires significant CPU cycles. If every API call to high-throughput Google resource servers (like Gmail, Calendar, or Drive APIs) required verifying a DPoP proof, the compute overhead at the API Gateway layer would be massive, introducing measurable latency and scaling costs.
By constraining DPoP binding strictly to the refresh token, Google's architecture achieves a balance:
Long-Lived Credentials Protected: The highly sensitive, long-lived refresh token (which can be used to obtain new access tokens indefinitely) is cryptographically bound to the client's key pair. If exfiltrated, it is useless to an attacker.
High-Performance Serving: Short-lived access tokens (typically valid for 1 hour or less) remain standard Bearer tokens. This ensures that the vast majority of API requests incur zero cryptographic verification overhead, maintaining the high performance and low latency developers expect from Google APIs.
Complementary Protections: DPoP and DBSC
DPoP is a powerful tool for securing OAuth 2.0 tokens, but it is important to understand its boundaries.
DPoP does not protect standard web application session cookies, which remain a primary target for Infostealer malware. To address cookie theft, Google and the Web Incubator Community Group (WICG) are actively developing Device Bound Session Credentials (DBSC). While DPoP operates at the application layer to secure API tokens for public and confidential clients, DBSC operates at the browser and network layer to cryptographically bind browser session cookies to the device's hardware (such as TPM). Together, DPoP and DBSC form a comprehensive defense-in-depth strategy against credential theft across both API and web-based user sessions.
Multi-Agent Delegation & Model Context Protocol (MCP)
As autonomous AI agents and Model Context Protocol (MCP) architectures emerge, securing tool-use tokens becomes critical. While DPoP is highly resilient in single-hop client-to-server connections, multi-agent workflows (where Agent A delegates a task to Agent B, which calls Resource C) introduce delegation challenges.
In a multi-agent chain, Agent B cannot sign a DPoP proof on behalf of Agent A without access to Agent A's private key—and sharing private keys violates the core security principles of DPoP. Because Google's core consumer OAuth endpoint (oauth2.googleapis.com) does not support OAuth 2.0 Token Exchange (RFC 8693), developers building multi-agent or federated cloud workloads should consider Google Cloud Secure Token Service (STS). By routing delegation through STS, the intermediate agent can exchange the upstream token for a new, short-lived federated token cryptographically bound to its own local key pair, preserving the sender-constrained security model across the entire agent chain without key exposure.
See our DPoP Adoption Guide, our DPoP adoption SKILL.md, and improve your platform security today.