Google’s OAuth DPoP Support: What InfoQ Reported in November 2026

InfoQ China 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. That date is the article’s publication date, not a stated launch date for the feature.

A conventional bearer token can be used by anyone who obtains it. DPoP instead binds a token cryptographically to a client-generated key pair. A stolen token cannot be replayed without the corresponding private key, which remains with the client.

According to the report, Google applies DPoP to refresh tokens, while shorter-lived access tokens remain standard bearer tokens. The article identifies long-lived refresh tokens as a key route to sustained account impersonation and notes that applying DPoP to access tokens would add asymmetric cryptographic checks to every request. Clients using DPoP must also generate keys, handle timestamps and nonces, and produce the required HTTP headers and DPoP proof JWTs.

DPoP does not protect ordinary web-session cookies. The report says Google and the Web Incubator Community Group are developing Device-Bound Session Credentials (DBSC) to address cookie theft by binding browser sessions cryptographically to device hardware, such as a TPM.

The article also describes a limitation for multi-agent workflows: passing a DPoP-bound token to another agent would require sharing the first agent’s private key. It says Google recommends using Google Cloud Security Token Service (STS) instead, so an intermediary agent can exchange an upstream token for a short-lived federated token bound to its own key pair.

Finally, DPoP’s protection depends on the security of the client holding the private key. As the report notes, Dhruv Agnihotri argues that browser-based single-page applications cannot fully prevent key misuse. The article cites IETF guidance recommending a Backend-for-Frontend approach that keeps tokens and cryptographic keys outside the browser; it also notes Agnihotri’s proposed zero-persistence approach for cases where server-side infrastructure is unavailable.