Google Adopts DPoP to Strengthen OAuth 2.0 Against Token Theft and Replay Attacks

Traditional OAuth bearer tokens operate on a "finders-keepers" model, making them vulnerable to Infostealer malware (e.g. RedLine, NodeStealer) and Adversary-in-the-Middle (AiTM) attacks.

To prevent this types of attacks, DPoP uses cryptography to bind tokens to an asymmetric key pair generated by the client. Consequently, a stolen token cannot be replayed without the corresponding private key, which remains under the client’s control.

Google OAuth platform supports DPoP only for refresh tokens, while access tokens, which are shorter-lived, remain standard Bearer tokens. This decision is motivated by the fact that long-lived refresh tokens are "the primary vector for persistent online impersonation", whereas applying DPoP to access tokens would introduce "asymmetric cryptographic verification overhead" for each request.

It is worth noting that adopting DPoP adds several client-side requirements, including generating cryptographic keys, handling timestamps and nonces correctly, generating the appropriate HTTP headers and the required DPoP proof JWTs.

Google also notes that DPoP is not appropriate for multi-agent workflows, as one agent cannot easily delegate a task to another agent. This would in fact require the second agent to sign requests on behalf of the first. However, this in not possible without accessing the private key generated by the first agent, which would violate DPoP. As an alternative, Google recommends developers to consider Google Cloud Secure Token Service (STS).

By routing delegation through STS, the intermediate agent can exchange the upstream token for a new, short-lived federated token cryptographically bound to its own local key pair, preserving the sender-constrained security model across the entire agent chain without key exposure.

Since the DPoP private key is stored client-side, its security ultimately depends on the security of the client itself. However, as Dhruv Agnihotri argues, single-page-apps (SPAs) running inside a browser are not entirely protected against misuse of the key. The IETF's guidance for browser-based applications therefore recommends adopting the Backend-for-Frontend pattern to keep tokens and cryptographic keys out of the browser. Agnihotri also proposes a zero-persistence approach, which may be useful when server-side infrastructure is unavailable.

Explore how Azul helps Java teams reduce JVM vulnerability risk, strengthen application security, and prepare their Java environments for agentic AI. Discover practical strategies for securing Java workloads while maintaining performance and reliability. Learn more.