InfoQ reported on November 12, 2026 that Google’s OAuth platform had added support for Demonstrating Proof-of-Possession (DPoP), an OAuth 2.0 mechanism designed to reduce token theft and replay attacks.
Unlike a bearer token, which anyone holding it can use, a DPoP-protected token is cryptographically bound to a client-generated key pair. A stolen token cannot be replayed without the corresponding private key, which remains with the client.
Google’s implementation applies DPoP to long-lived refresh tokens, while short-lived access tokens remain standard bearer tokens. The reported rationale is to protect credentials that could enable prolonged impersonation without adding asymmetric cryptographic checks to every access-token request. Clients using DPoP must generate keys, handle timestamps and nonces, and produce the required HTTP headers and DPoP proof JWTs.
DPoP does not protect web session cookies from theft. At the time of the report, Google and the Web Incubator Community Group were developing Device-Bound Session Credentials (DBSC) to bind browser sessions to device hardware, such as a TPM.
Google also said DPoP is a poor fit for delegation between multiple AI agents: sharing the first agent’s private key with another would undermine the mechanism. It suggested Google Cloud Security Token Service (STS) instead, allowing an intermediary agent to exchange an upstream token for a short-lived federated token bound to its own key pair.
Because the DPoP private key stays with the client, protection still depends on client security. Dhruv Agnihotri argued that browser-based single-page applications cannot fully prevent misuse of a key. The report notes that IETF guidance for browser-based applications recommends a Backend-for-Frontend pattern that keeps tokens and cryptographic keys outside the browser; Agnihotri also proposed a zero-persistence approach for cases where server-side infrastructure is unavailable.