Loading post…
GoogleSergei Akulich, Brian DaughertyAnnouncement
Announcing DPoP Support for Google OAuth: Securing Refresh Tokens
Summary
Google announced DPoP (RFC 9449) support for its OAuth platform, specifically binding refresh tokens to a client-generated asymmetric keypair to neutralize token theft and replay attacks from Infostealer malware and AiTM threats. Access tokens remain standard bearer tokens to avoid the per-request asymmetric cryptographic verification overhead on high-QPS APIs like Gmail and Drive, delivering a pragmatic tradeoff between security and performance. The implementation follows RFC 9700 best practices for sender-constrained refresh tokens and is recommended for Backend-for-Frontend (BFF) and Token-Mediating Backend architectures. DPoP operates at the HTTP header level, making it resilient in multi-hop environments such as Model Context Protocol (MCP) agent chains, though multi-agent delegation requires Google Cloud Secure Token Service (STS) to preserve key isolation. Complementary protections against cookie theft are offered by Device Bound Session Credentials (DBSC), which cryptographically binds browser session cookies to device hardware for a defense-in-depth strategy.
Context
The post explains Google’s DPoP implementation for its OAuth platform, describing the design choice to bind only refresh tokens while keeping access tokens as bearer tokens for performance. It discusses the security tradeoff, architectural recommendations, and complementary protections like DBSC.
Approach / What changed
Google’s OAuth platform now supports DPoP binding for refresh tokens, using client-generated asymmetric keypairs to cryptographically bind tokens. Access tokens remain standard bearer tokens to avoid per-request cryptographic verification. The implementation requires client-side key generation, strict timestamp and nonce handling, and specific JWT construction. Google recommends using DPoP for sender-constraining refresh tokens in BFF, Token-Mediating Backend, and Browser-based OAuth Client architectures. For multi-agent delegation, Google Cloud STS is recommended instead of sharing private keys.
Takeaways
Google’s DPoP implementation binds only refresh tokens to a client keypair, preventing replay of long-lived credentials while avoiding cryptographic overhead on high-throughput resource APIs.
DPoP operates at the HTTP header level, making it resilient in multi-hop environments like MCP agent chains, unlike transport-layer token binding which can break at proxies.
For multi-agent workflows where delegation requires sharing tokens, Google Cloud STS allows exchanging tokens for new short-lived tokens bound to the intermediate agent’s keypair, preserving sender-constrained security.
FAQ
Why are Google access tokens still standard bearer tokens?
To avoid the CPU overhead of verifying asymmetric signatures on every API call to high-throughput services like Gmail and Drive. DPoP verification is only required during refresh token exchange, keeping the common case fast.
How does DPoP differ from DBSC?
DPoP secures OAuth tokens at the application layer by binding them to a client keypair, while DBSC secures browser session cookies at the browser/network layer by binding them to device hardware like TPM. They are complementary defense-in-depth mechanisms.
How to handle DPoP in multi-agent MCP architectures?
Direct delegation by sharing private keys violates DPoP security. Google recommends using Cloud STS to exchange the upstream token for a new short-lived token bound to the intermediate agent's own keypair, preserving sender-constrained security.
Source and freshness
- Source
- developers.googleblog.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.