# Google adds DPoP support to its OAuth platform for refresh tokens

published: 2026-10-15T19:06:10.939Z
topic: identity
source: https://developers.googleblog.com/announcing-dpop-support-for-google-oauth-securing-refresh-tokens/
url: https://aiagentnews.io/stories/google-adds-dpop-support-to-its-oauth-platform-for-refresh-tokens

Google's OAuth Platform now supports DPoP, the RFC 9449 proof-of-possession profile, for binding refresh tokens to a client-held key pair. Access tokens remain standard Bearer tokens to avoid per-request signature checks on high-volume APIs.

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.

## Why it matters if you build agents

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.