Google Adopts DPoP to Strengthen OAuth 2.0 Against Token Theft and Replay Attacks

Google has recently incorporated Demonstrating Proof-of-Possession (DPoP) into its OAuth 2.0 platform, aiming to bolster security against token theft and replay attacks. Traditional OAuth bearer tokens are susceptible to infostealer malware and attacks from adversaries positioned in the middle of the communication. DPoP tackles this risk by binding tokens to an asymmetric key pair created by the client, rendering a stolen token ineffective without the private key held by the client.

The new security measure applies only to refresh tokens, which are more prone to persistent online impersonation. Access tokens, being shorter-lived, continue to use standard Bearer tokens. This choice is due to the additional computational overhead of verifying DPoP on every access token request. In addition to DPoP, Google has started developing Device Bound Session Credentials (DBSC) to secure standard web application session cookies.

DBSC involves cryptographically binding session cookies to the user's hardware, such as a Trusted Platform Module (TPM), at the browser and network layers.

However, DPoP and DBSC have distinct limitations. DPoP is not suitable for multi-agent workflows, as one agent cannot delegate tasks to another without exposing the private key. Instead, Google suggests using Google Cloud Secure Token Service (STS) for delegation, which maintains the sender-constrained security model by generating a new, short-lived federated token for the intermediate agent.

DPoP's client-side key storage also raises concerns regarding its security, particularly in single-page applications running inside a browser. Google advises adopting the Backend-for-Frontend pattern and proposes a zero-persistence approach to mitigate these risks.