Refresh Token Rotation and App Session Boundary

Working case

Reviewer 47 opens three tabs. Their access token expires while all three tabs request case lists. If each tab independently uses the same rotating refresh token, one succeeds and the others may trigger reuse detection. A server-owned session coordinates one refresh per token family and makes the other requests wait for the result or fail with a recoverable sign-in state. When the reviewer signs out, the portal invalidates its own session immediately. A provider token may remain valid briefly unless the provider supports revocation, so the app does not present local logout as proof that every external session ended.

Implementation boundary

function sessionMayReadCase(session, account) {
  return Boolean(session) && !session.revoked &&
    session.accountId === account.id &&
    session.permissionVersion === account.permissionVersion;
}
console.log(sessionMayReadCase({ accountId: 47, permissionVersion: 3, revoked: false }, { id: 47, permissionVersion: 4 }));
// Output: false

Choose a token custody model before coding. For a server-backed app, store provider tokens encrypted or otherwise protected server-side with access control and limited retention; send the browser a session cookie with Secure, HttpOnly, and an appropriate SameSite policy. Rotate the app session identifier at sign-in and account changes. Serialize refresh for each token family using a lock or compare-and-swap; persist a replacement token atomically before releasing waiting requests. Reject a spent token replay according to the provider contract and decide when to invalidate the family. For a public client, follow the provider’s required rotation or sender-bound design and understand that browser script compromise remains a different risk. Keep local permission checks fresh on private API reads and writes.

Cost and boundaries

One refresh usually costs a provider round trip; repeated concurrent refresh can multiply traffic and cause failed sessions. Per-family coordination adds contention but keeps normal case requests from racing on a one-use token. Session lookup costs O(1) with indexed identifiers, while server-side storage and cleanup grow with active sessions. Shorter access-token lifetimes increase renewal frequency; longer lifetimes increase the delay before external scope changes take effect unless resource servers recheck. Track refresh attempts per session, rotation conflicts, replay detections, sign-out-to-denial time, and provider outages. Never use raw tokens as telemetry labels.

Failure trace

Expire the access token and send 47 concurrent requests from several tabs. Only one refresh should consume the current rotating token; the others should receive a consistent new session outcome. Crash after provider success but before storing the replacement and verify the app fails closed with a sign-in recovery path. Replay a spent refresh token and confirm the chosen family response. Sign out in one tab, wake another, and deny its private API request. Remove a reviewer from a tenant while the provider token remains valid; local authorization must still reject the case.

Verification

• Provider tokens are held under a deliberate custody model.
• Concurrent refresh cannot consume one rotating token multiple times.
• Local sign-out and permission revocation deny private requests.

Practice drill

Build a session store for reviewer 47 with a provider token family and a local permission version. Inject 47 simultaneous requests at expiry, one provider timeout, one replay, and a sign-out race. Record provider calls, issued app sessions, and rejected stale requests. Inspect cookies for Secure, HttpOnly, and SameSite attributes in a real browser environment. Switch the browser to reviewer 62 and check that neither old account caches nor an old session can reveal case 47.

Decision note

The application owns its session and authorization lifetime; provider renewal is a separate protected operation.

Common Mistakes

• Keeping long-lived provider refresh tokens in routine browser-readable storage.
• Allowing each tab to rotate the same token independently.
• Treating provider token expiry as the app’s only revocation mechanism.

Related lessons

Federated Identity and Session Lifecycle; Authorization Code, PKCE, and Callback Binding; ID Token Verification and Stable Account Identity; Federated Account Linking, Logout, and Revocation; Permission Revocation and Active Sessions; Browser Storage Cleanup on Account Change.

Apply and check

Build Project: federated permit reviewer sign-in and review Web Development: federated identity and session contracts quiz.