Q263: Token Refresh Session Renewal and Auth Race Conditions

What Interviewers Want To Evaluate

Interviewers want to know whether you can handle authentication over time, not only the first login.

They want to hear about access token expiry, refresh flows, concurrent requests, silent renewal, tab coordination, logout, retry loops, and user-friendly recovery.

Short Interview Answer

Token refresh and session renewal keep authenticated users active without exposing long-lived credentials or creating retry storms. I design access tokens to be short-lived, refresh or renew through a controlled server endpoint, coordinate concurrent refresh attempts, avoid infinite retry loops, handle revoked sessions clearly, and synchronize logout across tabs. The UI should distinguish loading auth, expired auth, forbidden access, and recoverable network failures.

Detailed Interview Answer

Authentication is not a one-time event.

After login, many things can happen:

access token expires
refresh token expires
session is revoked
password changes
organization access changes
network drops
multiple tabs make requests
clock skew affects expiry

A good frontend auth model handles these without confusing users or hammering APIs.

Short-Lived Access

Short-lived access tokens reduce risk.

If stolen, they expire quickly.

But short lifetimes mean the app needs renewal.

That renewal should be:

centralized
observable
race-safe
bounded
recoverable

Do not scatter refresh logic across every API call.

Refresh Token Risk

Refresh tokens are powerful.

They can often mint new access tokens.

Storing them in JavaScript-readable storage increases XSS impact.

Safer patterns often keep refresh capability in:

HttpOnly secure cookie
server session
backend-for-frontend
identity provider session

The right choice depends on app architecture.

Refresh Race Conditions

Imagine ten API calls fail with 401 at the same time.

Bad behavior:

all ten calls refresh simultaneously
some refresh requests invalidate others
requests retry with mixed tokens
the app logs out randomly

Better behavior:

one refresh in flight
other requests wait
successful refresh releases queued retries
failed refresh clears session once

This is often called refresh deduplication or single-flight refresh.

Retry Limits

Auth retry loops are dangerous.

Rules:

retry a request once after successful refresh
do not refresh repeatedly for the same failed request
do not refresh on 403
do not refresh on validation errors
stop when refresh endpoint fails

Otherwise the app can create traffic spikes and confusing UI.

Session Renewal

Some apps renew sessions based on activity.

Others use fixed expiration.

Questions to ask:

does activity extend the session?
does sensitive action require re-auth?
what is the idle timeout?
what is the absolute timeout?
how are users warned before expiry?

Security and UX must be balanced.

Multi-Tab Behavior

Users open multiple tabs.

Auth state should not fall apart.

Coordinate with:

BroadcastChannel
storage events
server session checks
short polling where necessary

When one tab logs out, other tabs should not keep showing private data as if the session is alive.

Revocation

Sessions can be revoked.

Examples:

admin disables account
user changes password
device is removed
refresh token is rotated
organization access is removed
security incident forces logout

The frontend should handle revocation as a normal state, not an impossible error.

Error State Taxonomy

Separate:

unknown auth state
anonymous
authenticated
expired
forbidden
network unavailable
server unavailable

This helps the UI choose between spinner, sign-in prompt, access denied, retry, or incident messaging.

Interview Example

If asked, "Several requests get 401 after token expiry. What should happen?"

Answer:

"The first request should trigger a single refresh flow. Other requests should wait for that result. If refresh succeeds, retry each original request once with the new credential. If refresh fails, clear auth state and redirect or prompt for sign-in without creating an infinite loop."

Common Mistakes

Common mistakes include:

refreshing on every request
refreshing many times concurrently
retrying forever after 401
refreshing after 403
not syncing logout across tabs
keeping private data visible after session loss
storing refresh tokens casually
not distinguishing expired from forbidden

Senior-Level Framing

The senior framing:

"I treat auth renewal as a state machine. The app should know whether it is authenticated, refreshing, expired, forbidden, or offline, and every transition should be bounded, observable, and recoverable."

Practice Prompt

Design an auth client for:

short-lived access
server-side refresh
multiple concurrent API calls
multi-tab logout
offline mode
forbidden organization access

Write the states and transitions before writing code.

Final Mental Model

Authentication must survive time.

Login starts the session, but renewal, revocation, tab coordination, and failure handling determine whether the product feels trustworthy.