Google OAuth Now Supports DPoP for Refresh Tokens. What It Binds, What It Leaves Alone, and the Agent Delegation Gap

If your agent holds a Google refresh token, that token is a long-lived bearer credential. Whoever copies it can use it. On October 15, Google announced DPoP support for its OAuth platform, which is meant to stop that for refresh tokens.

Everything below comes from Google's announcement and the DPoP adoption guide. I have not implemented it, so nothing here is tested.

What Google announced

DPoP (Demonstrating Proof-of-Possession) is defined in RFC 9449. The client generates an asymmetric keypair, and tokens are bound to it. Google says that even if a token is stolen, it cannot be replayed without the private key. It names infostealer malware and adversary-in-the-middle attacks as the threats.

The key design choice, in Google's words: DPoP binding is supported specifically for refresh tokens. Access tokens, which are short-lived (Google says typically an hour or less), stay standard bearer tokens. Google's stated reason is cost: verifying an asymmetric signature on every call to high-throughput APIs like Gmail, Calendar or Drive would add CPU load and latency at the gateway. The refresh token is the one that can mint new access tokens indefinitely, so Google treats it as the main target.

That means a stolen access token is still usable until it expires. DPoP here protects the long-lived credential, not every request.

What the client has to do

From the adoption guide:

• Generate an EC P-256 (ES256) keypair. RSA is possible but not recommended for higher compute cost.
• Build a DPoP proof JWT with a header carrying the public key in jwk and a payload with htm (POST), htu (https://oauth2.googleapis.com/token), iat and jti.
• For the authorization code exchange, jti is the base64url SHA-256 hash of the authorization code.
• Send the proof in a DPoP HTTP header on the token requests. The refresh token is then bound to that proof.

The authorization request itself is created normally. Google also warns about the extra work: key generation, timestamp and nonce handling, exact header construction, and secure storage for the key.

Pure client-side single-page apps cannot use DPoP directly, according to the guide, because of the client_secret requirement and CORS limits on the DPoP-Nonce header. Its answer is a Backend-for-Frontend acting as a confidential client that binds the refresh token server-side.

What it does not cover

• Session cookies. Google says DPoP does not protect web session cookies, which remain a primary infostealer target. It points to Device Bound Session Credentials (DBSC), which it says is in development with the WICG, as the complement.
• Access tokens. As above, they remain bearer tokens.
• Everything outside Google's OAuth endpoint. The announcement is about Google as the authorization provider.

Agents, MCP and delegation

This is the part that matters for agent builders. Google says DPoP works well for single-hop client to server connections and, because it operates at the HTTP header level rather than the transport layer, holds up through proxies and load balancers, unlike mTLS (RFC 8705) which often breaks at cloud proxies.

Multi-agent chains are harder. If Agent A delegates to Agent B, which calls a resource, Agent B cannot sign a proof for Agent A without Agent A's private key, and sharing that key defeats the point. Google also says its consumer OAuth endpoint (oauth2.googleapis.com) does not support OAuth 2.0 Token Exchange (RFC 8693). For multi-agent or federated cloud workloads, it suggests Google Cloud Secure Token Service (STS), where the intermediate agent exchanges the upstream token for a short-lived federated token bound to its own key.

The announcement also says Workspace Context-Aware Access uses DPoP to validate agent identities at the Agent Gateway on the Gemini Enterprise Agent Platform. I did not look into that product, so I cannot say more than Google does.

What I would check

These are my own untested suggestions.

1. List where your agents store Google refresh tokens today, and who or what can read that storage.

2. Check whether your key storage can keep a private key that the agent process can use but not export.

3. If you chain agents, decide up front how identity passes along the chain, since DPoP alone does not answer that.

4. Read the adoption guide's sections on nonce handling before estimating the work.

What I would not conclude

• That DPoP makes a stolen Google account session harmless. Cookies and access tokens are outside it.
• That it is a drop-in change. Google itself lists new client-side work.
• That it solves delegation between agents. Google's own answer there is a different service.

Frequently asked questions

What is DPoP?

An OAuth 2.0 profile (RFC 9449) that binds tokens to a client-generated keypair so a stolen token cannot be replayed without the private key.

What does Google bind with it?

Refresh tokens only. Access tokens remain bearer tokens.

Why not access tokens too?

Google says per-request signature verification on high-traffic APIs would add heavy compute and latency.

Can a browser-only app use it?

Not directly, per the guide. It recommends a Backend-for-Frontend as a confidential client.

Does it stop cookie theft?

No. Google points to DBSC for that, and describes it as in development.

How does it fit MCP and multi-agent setups?

Google says it works across single hops and proxies, but delegation chains need another approach, and it suggests Google Cloud STS.

Is there a guide for implementing it?

Yes, Google published a DPoP adoption guide, linked below, and mentions a SKILL.md for implementation.

Sources

• Google Developers Blog, Announcing DPoP Support for Google OAuth: Securing Refresh Tokens (October 15, 2026): the design choice, limits, DBSC and agent delegation claims.
• Google for Developers, DPoP Adoption Guide: proof construction and SPA limits. I read the first part of the guide, not all of it.