Auth, Session & Storage

1The security triangle: you can't win all three

Every token storage decision is a trade-off among three properties. You can satisfy two of them, never all three simultaneously:

Given that constraint, there are exactly three real options — pick the pair that fits your threat model:

No single mechanism wins everything. The question is: which threat is more dangerous in your context? For most web apps, XSS is the greater risk — an attacker who can run JS can exfiltrate a localStorage token and replay it from anywhere. That's why the modern recommendation is HttpOnly cookies for refresh tokens, in-memory for access tokens.

2Client storage options compared

* Memory is not XSS-safe — injected JS runs in your page's context and can read variables. The advantage over localStorage is blast radius: the token is not persisted, dies with the tab, and cannot be read cross-origin or after the XSS is patched. A stolen memory token buys an attacker at most 15 minutes in one live session.

3JWT vs opaque tokens

* JWT revocation workarounds: short expiry (15 min window), a blocklist in Redis (defeats statelessness for those tokens), or refresh-on-every-request. None is perfect. The practical answer: keep JWTs short-lived and accept the window.

JWT anatomy: the three parts

A JWT is three Base64URL-encoded strings joined by dots: header.payload.signature

{
  "alg": "RS256",
  "typ": "JWT"
}

{
  "sub": "user123",
  "roles": ["admin"],
  "exp": 1716242622,
  "iat": 1716239022
}

RS256(
  base64url(header)
  + "."
  + base64url(payload),
  privateKey
)

How a JWT is created (RS256)

How a JWT is verified (RS256)

4Refresh token rotation

Refresh tokens are long-lived and therefore the highest-value theft target. Rotation limits the damage window if one is stolen.

-- Singleton refresh gate --
let refreshPromise = null;

async function getAccessToken() {
  if (!isExpired(accessToken)) return accessToken;
  if (!refreshPromise) {
    refreshPromise = callRefreshEndpoint()
      .then(t => { accessToken = t; refreshPromise = null; return t; });
  }
  return refreshPromise;
}

Three tiers of the refresh race — right fix for each

5Cookies deep: SameSite, Secure, HttpOnly

Three cookie attributes together form the modern auth cookie pattern:

SameSite: which to pick?

Cross-subdomain cookies

To share a cookie across www.example.com and api.example.com: set Domain=.example.com (leading dot = include all subdomains). Be aware: any compromised subdomain can now read and set that cookie.

Set-Cookie: session=<token>; HttpOnly; Secure; SameSite=Lax; Domain=.example.com; Path=/; Max-Age=2592000

6The recommended pattern: access + refresh split

Putting it all together, the modern standard for SPAs with a backend:

-- Access token: short-lived JWT in memory --
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...
Expiry: 15 minutes. Stored in a JS module variable. Never in localStorage.

-- Refresh token: opaque, long-lived, in HttpOnly cookie --
Set-Cookie: refresh=<opaque-token>; HttpOnly; Secure; SameSite=Lax; Path=/auth/refresh
Path=/auth/refresh means the cookie is ONLY sent to that one endpoint. Nothing else sees it.

-- On 401: refresh → new access token, transparent to the UI --

7CSRF is not solved by CORS (L17 tie-in)

A reminder from L17: CORS is browser-enforced on reading responses, but it does not prevent simple cross-origin requests from being sent. A malicious page can still trigger a cookie-carrying <form action="https://example.com/checkout" method="POST"> — no CORS preflight for a form POST with application/x-www-form-urlencoded.

SameSite=Lax/Strict is now the primary CSRF defense for modern browsers. For cases requiring SameSite=None (third-party embeds, cross-site widgets):

• Synchronizer Token Pattern — server generates a per-session CSRF token, embedded in HTML; JS reads it from a non-HttpOnly cookie or a meta tag and sends it as a header (X-CSRF-Token). Server validates header matches session. XSS risk: JS can read the non-HttpOnly cookie — acceptable trade-off for CSRF protection.
• Double-submit cookie — server sets a random cookie (non-HttpOnly), JS reads it and echoes it as a request header. Server checks header matches cookie. Simpler but weaker (subdomain attack possible).
• Custom request header — any custom header (e.g. X-Requested-With: XMLHttpRequest) triggers a CORS preflight for cross-origin requests, which a simple form can't forge. Weak defense; use as belt-and-suspenders only.

8platform-specific angle

• SEA mobile users: Low-end devices lose connections; SameSite=Lax on session cookies ensures users coming back from a background-killed tab still get their session cookie on the returning navigation.
• Cross-subdomain SSO: Domain=.example.com allows the same session cookie to work across partner portals and subdomains. Trade-off: subdomain compromise = cookie compromise. Pair with strict CSP (L19).
• Scale: JWT for the API layer — stateless, horizontally scalable, no Redis lookup per request. Opaque refresh token stored in a session DB (with Redis expiry TTL). Refresh token family revocation on compromise.
• Multi-tab refresh race: At platform traffic levels, users often have multiple tabs open. The singleton refresh gate pattern above is load-bearing — without it, race conditions log users out on rotation reuse detection.

9Check yourself — scenario quiz