Google OAuth adds DPoP to bind refresh tokens and block replay

On 2026-11-12, InfoQ reported that the Google OAuth platform has added support for DPoP, or Demonstrating Proof-of-Possession, an OAuth 2.0 security mechanism designed to mitigate token theft and replay attacks. Under the model described in the report, a traditional OAuth Bearer Token follows a whoever holds it can use it approach that leaves it exposed to infostealer malware such as RedLine and NodeStealer, as well as AiTM man-in-the-middle attackers. DPoP addresses this by cryptographically binding tokens to a pair of asymmetric keys generated by the client. Even if a token is stolen, an attacker cannot replay it without the matching private key, which stays on the client side.

According to the same report, the Google OAuth platform enables DPoP only for refresh tokens, while short-lived access tokens continue to use standard bearer tokens. The reasoning given is that long-lived refresh tokens are the main entry point for persistent identity impersonation, and attaching DPoP to access tokens as well would add an asymmetric cryptography check to every request. Enabling DPoP also introduces new client-side requirements, including generating cryptographic keys, correctly handling timestamps and nonces, producing the right HTTP request headers, and building the required DPoP proof JWT.

DPoP does not protect standard web application session cookies, which remain vulnerable to Infostealer malware. To counter cookie theft as a separate threat, Google and the Web Incubator Community Group, or WICG, are developing Device-Bound Session Credentials, abbreviated DBSC, which the report describes as still in development.