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

Google's OAuth Platform has recently introduces support for Demonstrating Proof-of-Possession (DPoP), an OAuth 2.0 security mechanism designed to mitigate 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.

While DPoP provides protection for API tokens, it does not protect standard web application session cookies, which remain vulnerable to Infostealer malware. To address the threat of cookie theft, Google and the Web Incubator Community Group (WICG) are developing Device Bound Session Credentials (DBSC).

DBSC operates at the browser and network layer to cryptographically bind browser session cookies to the device's hardware (such as TPM). Together, DPoP and DBSC form a comprehensive defense-in-depth strategy against credential theft across both API and web-based user sessions.

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.