Google OAuth adds DPoP support, binding refresh tokens to a client key pair so stolen tokens can't be replayed
Long-lived tokens held by agents are prime targets for infostealers. Why Google binds only refresh tokens, and what to do when agents delegate to each other.
// Key points
- DPoP (RFC 9449) binds tokens to a client-generated asymmetric key pair, so a stolen token can't be replayed without the private key.
- Google binds only refresh tokens; access tokens, typically valid for an hour or less, stay ordinary bearer tokens to avoid asymmetric signature checks on every API call.
- DPoP doesn't protect browser session cookies; that falls to DBSC, which Google and the WICG are developing.
- In multi-agent chains an intermediate agent can't sign a DPoP proof for its upstream; Google suggests exchanging through STS for a short-lived federated token bound to the agent's own key. Google Workspace already uses DPoP to validate agent identities at the Agent Gateway of the Gemini Enterprise Agent Platform.
Builder's takeProducts whose agents call Google Drive or Gmail for users should change how they store refresh tokens first. If AI Cloud Drive imports from Google Drive, I'd move its refresh tokens to DPoP binding with the private key kept server-side; the trade-off of binding only refresh tokens and keeping access tokens short-lived is worth copying in your own gateway too.
// Background · from #AI agents
Full timeline →- Oct 18 DeepSeek opens its Search and Fetch APIs to everyone at $0.75 per 1,000 calls per endpoint, free through Claude Code and Codex until October 31
- Oct 18 Tencent Hunyuan open-sources Hy-Memory-30B-A3B under Apache 2.0: a roughly 3B-active memory writer averaging 55.49 across four memory frameworks, ahead of Claude Opus 5 at 54.62
- Oct 17 Cloudflare adds continuous checks for Verified bots: a trust band based on whether they honor robots.txt and slow down after a 429