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.

Not specified by the original author.

TL;DR

Application > Settings > Refresh Token Rotation: ON. - Rotation: every refresh invalidates the old token and issues a new pair. - Reuse Interval: small leeway (seconds) for concurrent requests.

Steps

1. Application > Settings > Refresh Token Rotation: ON.
2. - Rotation: every refresh invalidates the old token and issues a new pair.

• Reuse Interval: small leeway (seconds) for concurrent requests. Keep it tight; it is not a grace period for replays.
• Absolute Lifetime: hard cap from first issuance (e.g. 30 days). The backstop.
• Inactivity Lifetime: expiry after idle (e.g. 7 days).

3. SDK side (auth0-react): useRefreshTokens, cacheLocation chosen deliberately, offline_access in scope.
4. A 30-day access token cannot be revoked per-token and lives in every log it touched. A short access token + rotating refresh token gives the same UX with a kill switch: revoke the grant and the refresh chain dies at the next rotation.
5. Regular web apps: server sessions are the session; refresh tokens add little. M2M: no refresh tokens at all. Native apps: rotation on, same as SPA.
6. - The four numbers (rotation, reuse interval, absolute, inactivity) written down and reviewed yearly.

• invalid_grant path tested, not just the happy path.

When to use

You are seeing this: The backstop. - Inactivity Lifetime: expiry after idle (e.g. Use this skill when you run into "Refresh token policy for SPAs: rotation on, reuse detection, absolute lifetime".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

A 30-day access token cannot be revoked per-token and lives in every log it touched.

Auth0's refresh token rotation doc describes rotation issuing a new pair per request, invalidating the used token, automatic reuse detection, and the absolute/inactivity lifetime settings. Verified against live docs 2026-09-26.

Not specified by the original author.

TL;DR: Rotating refresh tokens give SPAs long sessions without third-party cookies, but the client must replace the stored token on every rotation and treat reuse detection as a full logout. Set Reuse Interval if you need a small leeway for concurrent requests (a few seconds), but keep it tight.

Refresh token rotation

How it works

With rotation on, each refresh request returns a new access token AND a new refresh token; the old refresh token is invalidated immediately. If a rotated-out token is ever used again, Auth0 treats it as token theft: the whole grant (all tokens) is revoked. That is automatic reuse detection.

Setup

1. Application settings > Refresh Token Rotation: on. Set Reuse Interval if you need a small leeway for concurrent requests (a few seconds), but keep it tight.
2. Absolute Lifetime: the hard cap on the session (e.g. 30 days). Inactivity Lifetime: expiry after idle time (e.g. 7 days). Both count from issuance of the first token in the chain.
3. Request the offline_access scope at login or no refresh token is issued at all. For SPAs this means adding it to authorizationParams scope.

SDK behavior

auth0-react with useRefreshTokens handles the swap: it stores the new refresh token and uses it next time. Rules for your own code:

• Always persist the newest refresh token before using it; a crash between use and persist strands the user.
• Serialize refresh calls: two tabs refreshing at once can trigger false reuse detection. A single-flight lock (leader tab or mutex) avoids it. The reuse leeway setting covers small races.
• On invalid_grant from the token endpoint, assume the grant is revoked: clear stored tokens and send the user to login. Do not retry the same refresh token.

When rotation is wrong

Regular web apps with server sessions usually do not need rotating refresh tokens; the server session is the session. M2M apps do not get refresh tokens at all (client_credentials only).

Checklist

• offline_access requested, rotation on, absolute + inactivity lifetimes set deliberately.
• Reuse detection error path logs the user out cleanly instead of looping.

When to use this

• This covers exactly what the title says: Refresh token rotation for SPAs.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Refresh; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Refresh behavior.

Auth0's refresh token rotation doc describes issuing a new refresh token with each request, invalidating the used one, and automatic reuse detection against replay attacks. The absolute/inactivity lifetime settings are part of the refresh token configuration. Verified against live docs 2026-09-26.