Google OAuth DPoP for refresh tokens: What it protects and how to adopt

Google’s OAuth platform now offers optional DPoP support that binds refresh tokens to a client-generated key pair, preventing stolen refresh tokens from being used without the corresponding private key, while leaving short-lived access tokens as conventional bearer tokens. The approach reduces the risk of persistent account access after refresh-token theft but does not prevent replay of compromised access tokens, which typically remain valid for about an hour. Adoption requires clients to generate and securely retain an ES256 key pair, create signed DPoP JWT proofs for authorization-code and refresh-token exchanges, manage single-use nonces, and implement automatic retry handling for nonce challenges. Google recommends the feature across several OAuth architectures, although browser-only single-page applications cannot use it directly because of client-secret and CORS constraints and must place a confidential backend in front of the browser. DPoP can operate through proxy-heavy environments and is relevant to agent systems, but multi-agent delegation requires separate keys and token exchanges rather than sharing a private key; Google directs applicable cloud workloads to its Secure Token Service because consumer OAuth does not support the standard token-exchange specification. The feature does not protect session cookies, native and mobile implementation guidance remains absent, and organizations are advised to prioritize DPoP where refresh tokens are exposed while recognizing that other defenses remain necessary for access-token theft and browser-based attacks.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.