Google adds DPoP support to its OAuth platform for refresh tokens

Bearer tokens can be stolen by infostealer malware or adversary-in-the-middle attacks and then reused. DPoP counters this by tying a token to an asymmetric key pair generated by the client, so a stolen token cannot be replayed without the matching private key. Google says it supports DPoP binding specifically for refresh tokens, since those long-lived credentials allow persistent offline impersonation.

Implementing DPoP requires client-side key generation, strict timestamp and nonce handling, and construction of the htm, htu, iat and jti claims and the DPoP proof JWT. Google recommends DPoP for sender-constraining refresh tokens in the backend-for-frontend, token-mediating backend and browser-based client models described in the IETF draft. Google also points to its DPoP adoption guide and a DPoP adoption SKILL.md file.

Google says DPoP does not cover browser session cookies, which it is addressing separately with Device Bound Session Credentials (DBSC). For multi-agent chains, the post notes that Google's consumer OAuth endpoint does not support RFC 8693 token exchange, and suggests Google Cloud Secure Token Service for delegation.

If you build agents that hold Google refresh tokens, you can now ask for sender-constrained refresh tokens, so a copied token is useless without the client's private key. Plan for added key management and proof generation in the client code.

Agent B cannot sign a DPoP proof for Agent A without Agent A's private key, so multi-agent designs need a different delegation path. Google points to Cloud STS for that case, and the consumer endpoint lacks token exchange support.