· javascript
Google Adopts DPoP to Strengthen OAuth 2.0 Against Token Theft and Replay Attacks
Traditional OAuth bearer tokens operate on a "finders-keepers" model, making them vulnerable to Infostealer malware (e.g.
RedLine, NodeStealer) and Adversary-in-the-Middle (AiTM) attacks. To prevent this types of attacks, DPoP uses cryptography to bind tokens to an asymmetric key pair generated by the client. Consequently, a stolen token cannot be replayed without the corresponding private key, which remains under the client's control.
Google OAuth platform supports DPoP only for refresh tokens, while access tokens, which are shorter-lived, remain standard Bearer tokens. This decision is motivated by the fact that long-lived refresh tokens are "the primary vector for persistent online impersonation", whereas applying DPoP to access tokens would introduce "asymmetric cryptographic verification overhead" for each request. It is worth noting that adopting DPoP adds several client-side requirements, including generating cryptographic keys, handling timestamps and nonces correctly, generating the appropriate HTTP headers and the required DPoP proof JWTs.
While DPoP provides protection for API tokens, it does not protect standard web application session cookies, which remain vulnerable to Infostealer malware. To address the threat of cookie theft, Google and the Web Incubator Community Group (WICG) are developing Device Bound Session Credentials (DBSC).
