# Google Adopts DPoP to Strengthen OAuth 2.0 Security Google integrates DPoP to mitigate token theft risks by binding credentials to client-side keys. - **Source:** [InfoQ](https://brifing.si/source/68ac18af-a4f3-4f7c-9c2c-44d4af8f89dd) - **Published:** 2026-10-29 - **Topic:** [Software & Engineering](https://brifing.si/c/engineering) - **Original article:** - **On Brifing:** https://brifing.si/s/4210d207-3d50-4723-8203-a4d518b959eb ## DPoP Integration Overview Google has officially introduced support for Demonstrating Proof-of-Possession (DPoP) within its OAuth platform. This security mechanism aims to mitigate risks associated with token theft and replay attacks. By binding tokens to specific asymmetric key pairs, Google enhances the security posture of its authentication flows, moving beyond traditional bearer token models. ## Mitigating Token Theft Vectors Traditional bearer tokens operate on a finders-keepers model, leaving them exposed to Infostealer malware like RedLine and NodeStealer. Adversary-in-the-Middle attacks also pose significant threats to these standard tokens. DPoP addresses these vulnerabilities by requiring the client to hold a private key, ensuring stolen tokens cannot be replayed without it. ## Strategic Scope of Implementation Google currently limits DPoP support to refresh tokens, while access tokens remain standard bearer tokens. This design choice balances security with performance, as applying asymmetric cryptographic verification to every access request would introduce significant overhead. Long-lived refresh tokens are identified as the primary vector for persistent online impersonation attacks. ## Client-Side Implementation Requirements Adopting DPoP necessitates specific client-side changes for developers. Teams must implement logic for generating cryptographic keys, managing timestamps, and handling nonces. Furthermore, developers are required to generate appropriate HTTP headers and DPoP proof JWTs. These technical prerequisites ensure that the client maintains control over the private key during authentication. ## Complementary Defense with DBSC While DPoP secures API tokens, it does not address vulnerabilities in web application session cookies. To bridge this gap, Google and the Web Incubator Community Group are developing Device Bound Session Credentials (DBSC). DBSC binds browser session cookies to hardware, such as a TPM, providing a comprehensive defense-in-depth strategy for users. ## Limitations in Agent Workflows DPoP is not suitable for multi-agent workflows because one agent cannot easily delegate tasks without sharing its private key. Sharing keys violates the core security model of DPoP. Google recommends using the Google Cloud Secure Token Service for such scenarios, allowing intermediate agents to exchange tokens for new, locally-bound federated credentials. ## Browser Security Considerations The security of DPoP relies heavily on the client environment. Single-page applications running in browsers remain susceptible to key misuse. Consequently, IETF guidance suggests adopting the Backend-for-Frontend pattern to keep tokens and keys out of the browser. Dhruv Agnihotri also suggests a zero-persistence approach for environments lacking robust server-side infrastructure. ## Future of Authentication Security The shift toward proof-of-possession models marks a critical evolution in securing OAuth 2.0 against modern cyber threats. By combining DPoP for API security and DBSC for browser sessions, Google establishes a more resilient framework. Developers must now prioritize these cryptographic bindings to protect against sophisticated credential theft and persistent impersonation attempts. ## Sources covering this story - https://www.infoq.com/news/2026/10/google-dpop-oauth2/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._