Securing Refresh Tokens: Moving Beyond Bearer-Only OAuth

The Core Update

Google now supports DPoP (Demonstrating Proof-of-Possession) for OAuth 2.0 refresh tokens. Traditional bearer tokens are easily stolen by infostealers, allowing bad actors to replay credentials indefinitely. DPoP cryptographically binds your refresh tokens to a client-side asymmetric keypair. Official Source: Google Announcement

Technical Impact & Mechanism

Google chose to implement DPoP at the refresh token level specifically. Access tokens remain standard bearer tokens. This is a deliberate performance choice. It avoids the latency hit of asymmetric signature verification on every high-frequency API call, while locking down the most dangerous vector: persistent offline token theft.

You must generate a JWT DPoP proof for every request that involves a refresh token. The proof includes:

• htm: The HTTP method (e.g., POST).
• htu: The target URL.
• iat: Issued at timestamp.
• jti: A unique identifier to prevent replay.

Example proof construction logic:

// Pseudo-logic for client-side DPoP proof
const header = { alg: 'ES256', typ: 'dpop+jwt', jwk: publicKey };
const payload = { htm: 'POST', htu: 'https://oauth2.googleapis.com/token', iat: Date.now(), jti: crypto.randomUUID() };
const dpopProof = sign(header, payload, privateKey);

Action Plan for Developers & Businesses

1. Evaluate Architecture: If you use browser-based clients, migrate to a Backend-for-Frontend (BFF) pattern. This simplifies your key management and keeps secrets out of the browser environment.
2. Audit Storage: Ensure your private keys are stored in secure, hardware-backed storage (like TPM or Secure Enclave) rather than local storage or cookies.
3. Integrate DPoP Flows: Update your token refresh logic to include the DPoP header and handle the cryptographic handshake required by the identity provider.