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

Google announced OAuth 2.0 support for Demonstrating Proof-of-Possession (DPoP), a cryptographic mechanism that binds tokens to client-generated asymmetric key pairs, blocking stolen tokens from being replayed without the private key.

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

Google has introduced support for Demonstrating Proof-of-Possession (DPoP) within its OAuth platform, a security mechanism designed to mitigate token theft and replay attacks. Traditional OAuth bearer tokens operate on a "finders-keepers" model, leaving them vulnerable to Infostealer malware such as RedLine and NodeStealer as well as Adversary-in-the-Middle (AiTM) attacks. DPoP addresses these threats by binding tokens to an asymmetric key pair generated by the client. A stolen token cannot be replayed without the corresponding private key, which remains under the client's control.

Google supports DPoP only for refresh tokens, not access tokens. The decision reflects a practical trade-off: long-lived refresh tokens represent "the primary vector for persistent online impersonation," while applying DPoP to access tokens would introduce "asymmetric cryptographic verification overhead" on every request. Access tokens, which are shorter-lived, therefore remain standard Bearer tokens.

Adopting DPoP imposes several client-side requirements. Developers must generate cryptographic keys, handle timestamps and nonces correctly, construct the appropriate HTTP headers, and produce the required DPoP proof JWTs. These additions increase implementation complexity on the client side.

DPoP does not protect standard web application session cookies, which remain vulnerable to Infostealer malware. To address this gap, 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 a TPM module. Together, DPoP and DBSC form a defense-in-depth strategy covering both API tokens and web-based user sessions.

Google also notes that DPoP is unsuitable for multi-agent workflows. One agent cannot delegate a task to another agent without the second agent signing requests on behalf of the first. That delegation would require accessing the private key of the upstream agent, violating DPoP's security model. As an alternative, Google recommends routing delegation through Google Cloud Secure Token Service (STS). An intermediate agent exchanges an upstream token for a new, short-lived federated token cryptographically bound to its own local key pair, preserving sender-constrained security across the entire agent chain without exposing the upstream private key.

Since the DPoP private key is stored client-side, its security ultimately depends on the security of the client itself. Dhruv Agnihotri argues that single-page applications running inside a browser are not fully protected against misuse of the key. The IETF's guidance for browser-based applications 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.

Refresh tokens now carry DPoP proof. Access tokens remain standard Bearer tokens.

Client-side requirements include key generation, timestamp and nonce handling, HTTP header construction, and DPoP proof JWT generation.

DBSC complements DPoP by binding browser session cookies to hardware-backed device credentials.

Multi-agent delegation requires Google Cloud STS rather than direct DPoP delegation.

SPAs should use Backend-for-Frontend to isolate cryptographic keys from the browser environment.

Google OAuth Platform Documentation

WICG Device Bound Session Credentials Proposal

IETF Browser Security Guidance