Google announced support for DPoP in its OAuth system. This update secures refresh tokens against theft. Access tokens remain standard Bearer tokens for speed.
Traditional OAuth bearer tokens operate on a "finders-keepers" model. This makes them vulnerable to Infostealer malware. Malware like RedLine can steal these tokens. Adversary-in-the-Middle (AiTM) attacks also target them. An attacker sitting in the network can intercept data.
DPoP (Demonstrating Proof-of-Possession) is an application-layer OAuth 2.0 security profile. It follows RFC 9449 standards. This profile neutralizes token theft and replay attacks. It does this by cryptographically binding tokens to a client-generated asymmetric keypair. The binding happens at the application layer. Even if a token is stolen, it cannot be replayed. Replay means using a stolen token again to gain access. The attacker needs the corresponding private key to use it.
Google Identity and its OAuth Platform function as a developer-facing service. Engineers implement OAuth 2.0 and cryptographic security controls here. They use these controls to protect API integrations. Separately, Google Workspace Context-Aware Access (CAA) leverages DPoP to secure enterprise AI workloads. CAA uses the Gemini Enterprise Agent Platform. It cryptographically validates agent identities at the Agent Gateway.
Google's OAuth Platform supports DPoP binding specifically for refresh tokens. This design choice reflects a pragmatic engineering tradeoff. By sender-constraining the long-lived refresh token, Google neutralizes the primary vector for persistent offline impersonation. Sender-constrained means the token is only valid for a specific client. Short-lived access tokens remain standard Bearer tokens. This ensures high-QPS resource APIs do not incur per-request asymmetric cryptographic verification overhead. High-QPS means high query per second, or very fast request rates. This approach delivers robust protection for sensitive credentials. It also maintains the high performance and low latency of Google API integrations.
Unlike standard Bearer token flows, DPoP requires client-side cryptographic key generation. Users must generate strict timestamp and nonce handling. They must compute specific claims like htm, htu, iat, and jti. Exact header construction and DPoP proof JWT construction are also needed. These changes may introduce additional system constraints. They affect secure computation, handling, and storage.