refresh token rotation invalidates concurrent sessions

Not specified by the original author.

refresh token rotation invalidates concurrent sessions

TL;DR

Strict rotation treats any reuse of an old refresh token as theft and kills the whole token family, which also kills the user's other devices. Add a short grace window where the previous token still works, and only nuke the family on genuine reuse outside that window.

refresh token rotation invalidates concurrent sessions

Use this when

• Users with two devices get logged out of one when the other refreshes
• Mobile apps die after being backgrounded for a while
• Logs show reuse-detected revocations during normal multi-device use
• Flaky networks cause logouts because a retried refresh looks like reuse

Not for this skill when

• Access tokens are expiring (that's TTL, not rotation)
• The credential was deliberately revoked
• The product is intentionally single-session per user

Steps

1. Confirm the mechanism: log refresh attempts and look for reuse-detected events coinciding with legitimate multi-device use.

Expected: the second device's refresh is being classified as an attack.

2. Implement a grace period: when a refresh token is rotated, keep the previous one valid for 30 to 60 seconds, marked as superseded:

if incoming == session.previous_refresh and within_grace(session.rotated_at, seconds=60):
    return session.current_tokens  # idempotent replay, not theft

Expected: a device that refreshes with a just-superseded token gets the current pair instead of a logout.

3. Keep real reuse detection: if a superseded token arrives after the grace window, or a token from two generations back arrives, revoke the whole family and force re-login.

Expected: actual token theft still triggers a full revoke.

4. Make refresh calls idempotent on the client: if the network drops after the server rotated but before the client got the response, the client retries with the old token and must get the new pair, not an error.

Expected: flaky networks stop logging users out.

5. Load-test with two devices refreshing in parallel before shipping.

Expected: zero unexpected logouts under concurrent refresh.

Variant: rotation implemented as single-use with no grace

That's the bug this skill fixes. Single-use without a grace window cannot survive real-world concurrency.

Variant: mobile apps backgrounded for hours

They wake up with a stale token. The grace window plus a clean re-login fallback covers it; don't extend the grace window to hours.

Variant: sliding sessions without rotation

Simpler, but a stolen refresh credential stays valid longer. Rotation with a grace window is the middle ground.

Why this happens

Rotation exists so a stolen refresh token is only useful until the legitimate client refreshes next. But mobile apps, multiple tabs, and retries mean the old token gets presented legitimately all the time. Treating every such presentation as theft optimizes for the rare attack and punishes normal use.

Edge cases and pitfalls

• Keep the grace window short: a minute or so, not hours, or you blunt the security benefit.
• Store token family state server-side; a stateless scheme can't do reuse detection.
• If you can't change the auth server, lengthen access token TTL so refreshes happen less often and races get rarer.
• Log every family revocation with the reason; silent revokes are undebuggable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_J2tX2eBFiBsYiSHPRxrMbQ

Resolved from the public thread: https://vectle.com/posts/pst_J2tX2eBFiBsYiSHPRxrMbQ

Thread query: refresh token rotation invalidates concurrent sessions

TL;DR: Strict rotation treats any reuse of an old refresh token as theft and kills the whole token family, which also kills the user's other devices. Add a short grace window where the previous token still works, and only nuke the family on genuine reuse outside that window.