Google has added a security feature that binds refresh tokens, which sustain an app's service access, to a cryptographic key held by the app. Developers integrating Google services can reduce token theft and reuse attacks. The mechanism for access tokens used in actual service calls remains unchanged.
1. Protecting long-lived credentials first
A refresh token is a long-lived credential used to obtain new access tokens. An access token is a credential used when making service requests. Google describes its typical lifetime as 1 hour or less.
The newly added DPoP is an application-layer security mechanism defined in RFC 9449. It binds tokens to a public and private key pair created by the client. If a token is an admission ticket, the corresponding private key is a separate key proving ownership. Leaking the token alone does not enable reuse.
Google applies this binding only to refresh tokens. This protects the route for continually obtaining new access, aiming to reduce the risk of attackers using stolen credentials to impersonate users over long periods.
2. Avoiding verification costs on every call
Access tokens retain the Bearer mechanism, allowing whoever holds them to use them. Google says verifying asymmetric signatures on every request increases computing load, latency, and scaling costs for high-traffic APIs. This is a design rationale, with no measured performance comparison provided.
The benefits and costs fall in different places. Long-lived credentials gain protection without requiring proof-of-possession verification for every service call. Clients, however, take on secure key generation, storage, and proof generation. Existing token management must also account for cryptographic operations and storage constraints.
3. Adoption requires a proof generation path
Beyond generating keys, clients must strictly handle time information and a one-time value called a nonce. They must correctly construct claims and headers containing request information and create a JWT carrying proof of possession. This processing is added to the existing flow of simply sending tokens.
The announcement provides no implementation code examples. Google points to a separate adoption guide and a SKILL.md document to help with implementation. The announcement alone therefore cannot establish specific request formats or library usage.
4. Maintaining the binding through intermediary servers
Google cites the refresh token protection discussion in RFC 9700 and a draft standard for browser apps. It recommends sender-constraining refresh tokens in three models: backends for frontends, token-mediating backends, and browser-based clients.
With mTLS, which binds tokens at the transport layer, connections can terminate or break at cloud proxies or load balancers. DPoP instead works at the request-header level. Google says this also helps agent architectures that pass through multiple intermediary servers.
5. Cookie protection and agent delegation are separate issues
Session cookies in ordinary web apps are not protected by this feature. Google and the Web Incubator Community Group are developing DBSC to bind cookies to device hardware. API tokens and browser sessions need separate, complementary protections.
Delegating work between agents also requires care. An agent receiving work cannot sign proof of possession on the previous agent's behalf without that agent's private key. Sharing private keys goes against the principles of this security mechanism.
The consumer authentication endpoint oauth2.googleapis.com does not support token exchange. Google recommends considering Google Cloud Secure Token Service for multi-agent or federated cloud work. This lets an intermediary agent exchange an upstream token for a short-lived federated token bound to its own key.
This change strengthens long-lived credentials while leaving service calls unchanged, and the key adoption question is whether key management and delegation paths are manageable.