● Covered by 1 source · 1 reportMedium impact1 neutral
Google OAuth Platform Adopts DPoP to Secure Refresh Tokens Against Theft and Replay Attacks
Key points
- Google OAuth supports DPoP for refresh tokens.
- DPoP binds tokens to client-generated asymmetric key pairs.
- Prevents replay of stolen tokens without the private key.
- Does not apply to access tokens due to verification overhead.
DPoP Integration for Refresh Tokens
Google's OAuth Platform has introduced support for Demonstrating Proof-of-Possession (DPoP), an OAuth 2.0 security mechanism. DPoP is implemented specifically for refresh tokens, which are long-lived and represent a significant vector for online impersonation if compromised. Access tokens, being shorter-lived, continue to use the standard Bearer token model to avoid cryptographic verification overhead on every request.
Mitigating Token Theft and Replay Attacks
Traditional OAuth bearer tokens are susceptible to 'finders-keepers' scenarios, making them vulnerable to infostealer malware and Adversary-in-the-Middle (AiTM) attacks. DPoP counters this by using cryptography to bind tokens to an asymmetric key pair generated by the client. This ensures that a stolen token cannot be replayed without the client's private key, which remains under its control.
Client-Side Requirements and Limitations
Implementing DPoP introduces several client-side requirements, including the generation of cryptographic keys, correct handling of timestamps and nonces, and the creation of specific HTTP headers and DPoP proof JWTs. Google notes that DPoP is not suitable for multi-agent workflows where one agent needs to delegate tasks to another, as this would require sharing the private key. For such scenarios, Google recommends using Google Cloud Secure Token Service (STS).
Complementary Security Measures
While DPoP protects API tokens, it does not secure standard web application session cookies, which remain vulnerable to infostealer malware. To address cookie theft, Google and the Web Incubator Community Group (WICG) are developing Device Bound Session Credentials (DBSC). DBSC aims to cryptographically bind browser session cookies to the device's hardware, such as a Trusted Platform Module (TPM), creating a comprehensive defense-in-depth strategy against credential theft across both API and web-based user sessions.
✨ This summary was generated by AI from the outlets' reporting listed below. It is not independently verified and may contain errors — check the original sources. How BrevFeed works →
The daily brief
One email each morning: the day's tech stories, clustered across outlets and summarized. No account needed.
One email a day. Unsubscribe in one click, any time.
Today's brief
Spend a few minutes, get the whole day. Every topic's top stories in one hands-free rundown — listen, watch, or read the transcript.
▶ Play today's brief
New every morning, and the back catalogue is archived by date.
Reporting from
Google's OAuth Platform now supports Demonstrating Proof-of-Possession (DPoP) for refresh tokens, a security mechanism that cryptographically binds tokens to a client's asymmetric key pair. This change mitigates token theft and replay attacks by preventing stolen tokens from being replayed without the corresponding private key. The adoption of DPoP addresses the vulnerability of long-lived refresh tokens, which are a primary target for persistent online impersonation.