OAuth 2.0 Refresh Token Rotation: Diagnosing False Logout Due to Reuse Detection

Symptom

Clients occasionally experience abrupt logouts after a refresh token has been used once and then re‑used by a retry or race condition. The server treats the second use as a potential theft and revokes the entire token family, leaving users unexpectedly signed out.

Unresolved Decision

The core question is whether reuse detection should trigger an automatic family revocation (fail‑closed) or serve merely as a signal for additional verification steps (fail‑open). Each path trades off user experience against security assurance.

Constraints & Uncertainty

Implementation‑specific behavior varies across authorization servers; some impose a grace window, others revoke immediately. Network latency, concurrent refresh calls, and device‑wide token sharing can all trigger false positives.

Questions to Resolve Before Enabling Strict Revoke

• What is the measured rate of legitimate refresh retries or race conditions in our production environment?
• Would a short grace period (e.g., 30–60 seconds) reduce false logouts without significantly weakening theft detection?
• Does our authorization server support a configurable fail‑open strategy that allows the client to request additional authentication instead of revoking the entire token family?