Google's OAuth platform has introduced support for Demonstrating Proof-of-Possession (DPoP), a cryptographic mechanism designed to mitigate the replay of stolen tokens by attackers, though the protection currently applies only to refresh tokens, not access tokens or web session cookies.
Traditional OAuth bearer tokens operate on a finders-keepers model, making them vulnerable to malware such as RedLine and NodeStealer. DPoP counters this by binding tokens to an asymmetric key pair generated by the client; a stolen token cannot be used without the corresponding private key, which stays with the client.
Google said it chose to apply DPoP only to refresh tokens because those long-lived credentials are the primary vector for persistent online impersonation. Access tokens, which are shorter-lived, remain standard bearer tokens; applying DPoP to them would introduce the asymmetric cryptographic verification overhead on every request.
The mechanism adds several client-side requirements, including generating cryptographic keys, handling timestamps and nonces correctly, and producing the required HTTP headers and DPoP proof JWTs.
Because the private key is stored on the client, its security depends on that environment. Dhruv Agnihotri has argued that single-page applications running in a browser are not entirely protected against misuse of the key. The IETF's guidance for browser-based applications therefore recommends the Backend-for-Frontend pattern to keep tokens and cryptographic keys out of the browser, and Agnihotri also proposes a zero-persistence approach, which may be useful when server-side infrastructure is unavailable.
DPoP does not protect standard web application session cookies, which remain vulnerable to infostealer malware. To address cookie theft, Google and the Web Incubator Community Group are developing Device Bound Session Credentials, which cryptographically bind browser session cookies to device hardware such as a TPM.
Google also noted that DPoP is not suitable for multi-agent workflows because one agent cannot easily delegate a task to another: the second agent would need to sign requests on behalf of the first, requiring access to the first agent's private key, which would violate DPoP. For such cases, Google recommends developers consider Google Cloud Secure Token Service (STS), through which an intermediate agent can exchange an 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 agent chain.
Analysis
Why this matters
- Token theft from infostealer malware and adversary-in-the-middle attacks has been a persistent security challenge; DPoP raises the bar for attackers by making stolen tokens useless without the client's private key.
- The limited scope (refresh tokens only) means access tokens remain vulnerable, so developers must still treat them as short-lived secrets.
- For web applications, session cookies remain unprotected until browser-level solutions such as Device Bound Session Credentials mature.
Background
OAuth 2.0 has long relied on bearer tokens, which grant access to any entity that presents them. This makes them a prime target for malware that steals credentials from browsers or devices. DPoP, standardised by the IETF, adds a sender-constrained layer by requiring the client to prove possession of the private key associated with the token. Google's implementation is one of the first major platform adoptions of the specification.
Key perspectives
- Google: DPoP is valuable for long-lived refresh tokens because they are the primary vector for persistent impersonation; applying it to access tokens would introduce excessive cryptographic overhead.
- Dhruv Agnihotri (developer): Single-page apps running in a browser are not fully protected against misuse of the DPoP private key, and a Backend-for-Frontend pattern or zero-persistence approach is advisable.
- IETF: Recommends the Backend-for-Frontend pattern to keep tokens and cryptographic keys out of browser environments.
What to watch
- Whether Google extends DPoP to access tokens in the future as cryptographic verification overhead decreases.
- The adoption of Device Bound Session Credentials across browsers to address the cookie-theft gap.
- Developer response to the added client-side complexity, especially in single-page applications.
Checked
12 claims in this story checked against 1 source: 11 supported.
Show each claim
- SupportedGoogle has introduced DPoP support to strengthen OAuth 2.0 against token theft and replay attacks.InfoQ: “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.”
- SupportedGoogle’s DPoP support currently applies only to refresh tokens.InfoQ: “Google OAuth platform supports DPoP only for refresh tokens, while access tokens, which are shorter-lived, remain standard Bearer tokens.”
- SupportedThe cryptographic binding aims to curb persistent impersonation.InfoQ: “This decision is motivated by the fact that long-lived refresh tokens are "the primary vector for persistent online impersonation"”
- SupportedAccess tokens remain vulnerable because they are still standard bearer tokens.InfoQ: “Google OAuth platform supports DPoP only for refresh tokens, while access tokens, which are shorter-lived, remain standard Bearer tokens.”
- SupportedStandard web application session cookies remain vulnerable to infostealer malware.InfoQ: “While DPoP provides protection for API tokens, it does not protect standard web application session cookies, which remain vulnerable to Infostealer malware.”
- SupportedDPoP binds tokens to a client-generated asymmetric key pair, so a stolen token cannot be replayed without the corresponding private key.InfoQ: “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.”
- SupportedTraditional OAuth bearer tokens are vulnerable to malware such as RedLine and NodeStealer.InfoQ: “Traditional OAuth bearer tokens operate on a "finders-keepers" model, making them vulnerable to Infostealer malware (e.g. RedLine, NodeStealer)”
- Partly supportedGoogle said it chose to limit DPoP to refresh tokens because they are the primary vector for persistent impersonation.InfoQ: “This decision is motivated by the fact that long-lived refresh tokens are "the primary vector for persistent online impersonation"”
- SupportedApplying DPoP to access tokens would add asymmetric cryptographic verification overhead on every request.InfoQ: “whereas applying DPoP to access tokens would introduce "asymmetric cryptographic verification overhead" for each request.”
- SupportedDhruv Agnihotri argues that browser-based single-page applications are not entirely protected against misuse of the private key.InfoQ: “However, as Dhruv Agnihotri argues, single-page-apps (SPAs) running inside a browser are not entirely protected against misuse of the key .”
- SupportedGoogle and WICG are developing Device Bound Session Credentials to bind browser session cookies to device hardware such as a TPM.InfoQ: “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).”
- SupportedGoogle recommends considering Cloud STS for delegation: an intermediate agent can exchange an upstream token for a short-lived federated token bound to its own local key pair.InfoQ: “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”
