PATTERN Cited by 1 source
Refresh token coalescing¶
Problem¶
High-request-volume OAuth clients (CLIs, MCP clients) can issue concurrent or near-concurrent refresh token requests. If the OAuth server has strict refresh-token-reuse detection (as Ory Hydra 1.x does), a retried refresh request is treated as token reuse, causing the entire access/refresh token chain to be invalidated — effectively logging the user out.
Solution¶
Place a coalescing layer in the proxy/router in front of the OAuth server. When a refresh token request arrives, the proxy briefly caches the response. If a duplicate request for the same refresh token arrives within the cache window, the proxy returns the cached response without forwarding to the OAuth server. This prevents the server from seeing the "reuse" and invalidating the chain.
How Cloudflare Applied It¶
After upgrading to the latest Hydra 1.x (which introduced stricter refresh invalidation), Cloudflare observed a spike in refresh token errors — Wrangler and MCP clients' retried refresh requests were invalidating entire sessions. The fix was adding coalescing behavior in the Worker that routes OAuth traffic to Hydra: duplicate refresh token requests within a short window were short-circuited with the cached response (Source: sources/2026-06-24-cloudflare-oauth-for-all).
Hydra 2.x resolves this natively with a configurable "refresh token grace period" that allows retries within a window without invalidation.
Trade-offs¶
- Pro: Prevents spurious session invalidation for high-throughput clients.
- Pro: Implemented at proxy layer — no changes to Hydra itself.
- Con: Cache window must be short to avoid security implications (stale refresh response).
- Con: Adds state to an otherwise stateless proxy hop.