# Implementing DPoP for Google OAuth Refresh Token Security Google adopts DPoP to mitigate token theft through cryptographic sender-constraining. - **Source:** [Google Developers Blog](https://brifing.si/source/1e914d4a-9164-4a1a-82cb-3d169fbad877) - **Topic:** [Software & Engineering](https://brifing.si/c/engineering) - **Original article:** - **On Brifing:** https://brifing.si/s/5d5182e0-0c85-4f3b-a494-66d920fcc417 ## The DPoP Security Mechanism DPoP, defined in RFC 9449, introduces an application-layer security profile for OAuth 2.0. By cryptographically binding tokens to a client-generated asymmetric keypair, it neutralizes token replay attacks. This ensures that even if a bearer token is exfiltrated by Infostealer malware, the attacker cannot utilize it without the corresponding private key. ## Strategic Refresh Token Binding Google has implemented DPoP specifically for refresh tokens to mitigate persistent offline impersonation risks. By sender-constraining these long-lived credentials, Google secures the primary vector for unauthorized access. This pragmatic approach focuses protection on the most sensitive tokens while maintaining standard Bearer token flows for high-frequency, short-lived access token requests. ## Performance and Scaling Tradeoffs Google maintains standard Bearer tokens for access tokens to avoid the massive CPU overhead of verifying asymmetric signatures on every API call. Verifying DPoP proofs at the scale of Google’s resource servers would introduce unacceptable latency. This architecture ensures high-performance API serving while keeping sensitive refresh tokens cryptographically protected and secure. ## Implementation and System Constraints Adopting DPoP requires significant client-side changes, including cryptographic key generation and strict handling of timestamps and nonces. Developers must compute specific claims like htm, htu, iat, and jti to construct valid DPoP proof JWTs. These requirements introduce new system constraints regarding secure computation, token handling, and local storage management. ## Resilience in Complex Environments Unlike transport-layer binding like mTLS, which often fails at cloud proxies or load balancers, DPoP operates at the HTTP header level. This makes it highly resilient for multi-hop environments and emerging architectures. It provides robust security for complex setups, including Model Context Protocol integrations and modern autonomous agent workflows. ## Defense-in-Depth with DBSC DPoP secures API tokens but does not protect standard web session cookies from Infostealer malware. To address this, Google is developing Device Bound Session Credentials (DBSC). While DPoP protects API-level tokens, DBSC binds browser session cookies to hardware-backed keys, creating a comprehensive defense-in-depth strategy for both API and web-based user sessions. ## Delegation in Multi-Agent Workflows Multi-agent chains present delegation challenges because agents cannot share private keys without violating DPoP security principles. Since Google’s consumer OAuth endpoint lacks native Token Exchange support, developers should utilize Google Cloud Secure Token Service. This allows intermediate agents to exchange tokens for new, locally bound credentials, maintaining security across the chain. ## Enterprise AI and Security Google Workspace Context-Aware Access now leverages DPoP to secure enterprise AI workloads on the Gemini Enterprise Agent Platform. By cryptographically validating agent identities at the Agent Gateway, Google ensures that sensitive AI interactions remain protected. Developers are encouraged to consult the DPoP adoption guide and SKILL.md to integrate these controls. ## Sources covering this story - https://developers.googleblog.com/announcing-dpop-support-for-google-oauth-securing-refresh-tokens/ — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._