JWT access tokens and refresh rotation in SPAs

Single-page apps struggle to store long-lived secrets safely. Short-lived access JWTs plus rotating refresh tokens in HttpOnly cookies is a common pattern—implemented carefully.

Access vs refresh#

• Access token: 5–15 minutes, sent as Authorization: Bearer or cookie; validates API calls.
• Refresh token: days/weeks, HttpOnly Secure SameSite cookie; only exchanged at /session/refresh.

Rotation#

Issue a new refresh token on each refresh; invalidate the previous server-side. If an old token is presented twice, treat as reuse attack—revoke the whole session family.

XSS vs CSRF#

Memory-only access tokens reduce theft via XSS but complicate page reloads. HttpOnly cookies resist XSS but need CSRF protection for mutating routes—use SameSite=strict or double-submit cookies.

Backend-for-frontend#

A BFF on your domain holds cookies and proxies to APIs, avoiding cross-site cookie complexity.

Summary#

JWTs are not a session store—they are signed claims. Pair short TTLs with refresh rotation, monitor reuse, and prefer SameSite cookies plus CSRF defenses for browser clients.