Where should you store an access token?

Preferred: an httpOnly, Secure, SameSite cookie so JavaScript cannot read it, paired with CSRF defenses. Second best: in memory only, accepting a refresh on every reload. localStorage is the weakest because any XSS can exfiltrate the token, though it is sometimes chosen for short-lived tokens against third-party APIs. State the threat model, then pick.

What is the difference between an access token and a refresh token?

An access token is short-lived (minutes) and sent with every API call. A refresh token is long-lived, sent only to the auth server, and exchanged for a new access token. Short access tokens limit the blast radius of theft; refresh tokens keep users signed in without re-entering credentials.

Why does OAuth require PKCE for browser apps?

Public clients cannot keep a client secret. PKCE binds the authorization request to the token exchange with a code verifier and challenge, so an intercepted authorization code is useless without the original verifier. The implicit flow is deprecated for this reason.

How do you handle many requests failing with 401 at once?

Single-flight refresh: the first 401 starts one refresh call, every other failed request is queued on the same promise, and when refresh resolves all queued requests replay with the new token. If refresh fails, clear the session and redirect to login once, not once per request.

Authentication vs authorization?

Authentication answers who you are; authorization answers what you may do. The frontend can hide UI a user is not allowed to use, but that is UX only. Every authorization decision must be enforced again on the server, because the client is fully controllable by the user.

Authentication & Authorization

Where do you store an access token? The trade-off answer interviewers want.

Module 13 · Authentication & Authorization

Sessions vs JWT, OAuth 2.0 and OIDC flows, access and refresh tokens, silent refresh, rotation, logout and revocation, RBAC vs ABAC, and route protection.

Cookie sessions vs stateless JWT, OAuth 2.0 Authorization Code with PKCE, OIDC, access and refresh token lifetimes, silent and rotating refresh, single-flight 401 handling, logout and revocation, RBAC vs ABAC, and route protection.

About this module

"Where would you store an access token?" is one of the most common frontend interview questions, and the expected answer is a trade-off discussion, not a one-liner.

This module covers the full identity picture: cookie sessions vs stateless JWT, the OAuth 2.0 Authorization Code flow with PKCE, OIDC identity tokens, and how SSO works from the browser's point of view.

You will learn token lifetimes, silent and rotating refresh, handling 401s with a single-flight refresh queue, revocation and logout across tabs, and why httpOnly + SameSite cookies beat localStorage under XSS.

It closes with authorization: authentication versus authorization, RBAC versus ABAC, protecting routes in the App Router with middleware, and why client-side guards are UX rather than security.

Phase 7 (Week 7) of the interview roadmap. Senior Track spans modules 1–19; the Staff Track starts at module 20.

Why this matters

"Where would you store an access token?" is asked in almost every frontend loop, and a one-line answer fails it. Strong candidates compare httpOnly cookies against memory and localStorage under XSS and CSRF, then explain refresh, revocation, and what the server must still enforce.

Key topics covered

AuthN vs AuthZ
Sessions vs JWT
OAuth 2.0 & PKCE
OpenID Connect
Token Lifetimes
Token Storage Trade-offs
Refresh & Rotation
Single-Flight 401 Handling
Logout & Revocation
RBAC vs ABAC
Route Protection

Where you'll use it

Choosing token storage for a SPA that talks to a third-party API
Implementing a single-flight refresh queue for concurrent 401s
Adding SSO to an app with an existing session cookie
Protecting App Router routes with middleware instead of client guards
Logging a user out across every open tab at once

AuthN vs AuthZ

Who you are, versus what you are allowed to do.

Authentication establishes identity. Authorization decides permissions. They are separate systems that fail in separate ways, and conflating them is the fastest way to lose a security question.

Authentication versus authorization
	Authentication	Authorization
Question	Who are you?	What may you do?
Artifact	Session or token	Roles, scopes, policies
Failure code	401 Unauthorized	403 Forbidden
Frontend role	Obtain and attach credentials	Hide disallowed UI
Source of truth	Auth server	Resource server

The line that must be said

Client-side authorization is user experience, never security. Hiding an admin button stops confusion, not an attacker with DevTools. The server re-checks every decision on every request.

Sessions vs JWT

Stateful and revocable, or stateless and fast.

Cookie sessions versus stateless JWT
Aspect	Cookie session	Stateless JWT
Server state	Session store lookup	None: signature verify
Revocation	Immediate: delete the record	Hard until expiry
Scaling	Needs shared store (Redis)	Scales trivially
Payload size	Tiny id	Larger, sent on every call
Cross-domain APIs	Awkward	Natural
Best for	First-party web apps	APIs, mobile, service-to-service

Common hybrid

Short-lived JWT access tokens for API calls, plus a stateful, revocable refresh token held server-side. You get stateless verification on the hot path and real revocation where it matters.

OAuth 2.0 & PKCE

Delegated authorization: let a user grant access without sharing a password.

Authorization Code + PKCE

1. App generates code_verifier (random) and
   code_challenge = SHA256(code_verifier)
2. Redirect → /authorize?client_id&redirect_uri&state&code_challenge
3. User authenticates and consents at the auth server
4. Redirect back → /callback?code=...&state=...
5. App verifies state, then POSTs code + code_verifier to /token
6. Auth server returns access_token (+ refresh_token)

Browser apps are public clients: they cannot keep a client secret
PKCE binds the redirect to the token exchange, so a stolen code is useless
state defends against CSRF on the callback; verify it before using the code
The implicit flow is deprecated: it put tokens in the URL fragment
Never accept a redirect_uri that is not on a server-side allowlist

OpenID Connect & SSO

OAuth answers 'may this app act for you'. OIDC answers 'who are you'.

OIDC is an identity layer on top of OAuth 2.0
It adds an id_token: a signed JWT describing the user (sub, email, name)
id_token is for your app to read; access_token is for calling APIs
Validate issuer, audience, expiry, and signature against the provider JWKS
SSO works because the provider already holds a session: no second login prompt

Frequent mix-up

Do not send the id_token to your APIs as a bearer credential. It proves identity to your client, not authorization to a resource server. Send the access token.

Token Lifetimes

Short access tokens shrink the blast radius; refresh tokens keep users signed in.

Token types and lifetimes
Token	Typical lifetime	Sent to	If stolen
Access	5–15 minutes	Resource APIs	Expires quickly
Refresh	Days to weeks	Auth server only	Serious: rotate and revoke
ID	Minutes	Nobody: read locally	Identity disclosure

Shorter access tokens mean more refreshes: balance security against chattiness
Absolute session lifetime caps how long a stolen refresh chain can live
Idle timeout logs out an unattended browser independently of token expiry
Refresh proactively at ~80% of lifetime so users never see a 401

Token Storage Trade-offs

The most-asked question in this chapter. Answer with a threat model.

Token storage options compared
Location	XSS exposure	CSRF exposure	Survives reload
httpOnly cookie	Not readable by JS	Needs SameSite + CSRF token	Yes
In-memory variable	Only while running	None	No
localStorage	Fully readable	None	Yes
sessionStorage	Fully readable	None	Per tab

The default recommendation is an httpOnly, Secure, SameSite cookie: script cannot read it, so XSS cannot exfiltrate it. The cost is that the browser attaches it automatically, so you must defend against CSRF.

When cookies are impossible (a third-party API on another origin), hold the access token in memory only and rely on a refresh call after reload. localStorage is the weakest option: any injected script reads it instantly.

Set-Cookie: session=<opaque>;
  HttpOnly;          // invisible to document.cookie
  Secure;            // HTTPS only
  SameSite=Lax;      // blocks most cross-site sends
  Path=/;
  Max-Age=1209600

How to phrase it

“It depends on the threat you are optimizing against. XSS beats every storage choice, so cookies plus a strong CSP are my default; memory-only is the fallback for cross-origin APIs; localStorage only for low-value, short-lived tokens.”

Refresh & Rotation

Renew silently, rotate every time, and detect reuse.

Silent refresh: exchange the refresh token before the access token expires
Rotation: every refresh issues a new refresh token and invalidates the old one
Reuse detection: an old refresh token being presented means theft — revoke the family
Refresh endpoints must be rate limited: they are a credential-stuffing target
Never put refresh tokens in localStorage; they are the long-lived secret

Why rotation matters

With rotation plus reuse detection, a stolen refresh token becomes self-revealing: as soon as either the attacker or the real user refreshes, the other one presents a used token and the whole chain is revoked.

Single-Flight 401 Handling

Six parallel requests expire together. You should refresh once, not six times.

let refreshing: Promise<void> | null = null;

async function apiFetch(input: RequestInfo, init?: RequestInit) {
  let res = await fetch(input, { ...init, credentials: "include" });
  if (res.status !== 401) return res;

  // Every concurrent 401 awaits the same in-flight refresh.
  refreshing ??= refreshSession().finally(() => {
    refreshing = null;
  });

  try {
    await refreshing;
  } catch {
    redirectToLogin();
    throw new Error("Session expired");
  }

  return fetch(input, { ...init, credentials: "include" });
}

Queue failed requests on one shared promise, then replay them
Retry each original request exactly once after a successful refresh
If refresh fails, clear session state and redirect once, not per request
Exclude the refresh call itself from the interceptor or you get infinite recursion

Logout & Revocation

Clearing local state is not logging out.

Call a server logout endpoint so the session or refresh family is revoked
Clear the cookie server-side; a client cannot delete an httpOnly cookie
Purge cached user data: query cache, stores, IndexedDB, and Service Worker caches
Broadcast logout to other tabs via BroadcastChannel or a storage event
For SSO, consider provider-initiated single logout so the IdP session ends too

const channel = new BroadcastChannel("auth");

export function logoutEverywhere() {
  channel.postMessage({ type: "logout" });
}

channel.onmessage = (e) => {
  if (e.data.type === "logout") {
    queryClient.clear();
    location.replace("/login");
  }
};

RBAC vs ABAC

Roles are simple. Attributes are expressive. Most products end up mixing them.

Role-based versus attribute-based access control
	RBAC	ABAC
Decides on	Role assignment	Attributes and context
Example	Admin may delete users	Owner may edit before publish
Strength	Easy to reason about and audit	Fine-grained, data-aware
Weakness	Role explosion at scale	Harder to test and explain
Frontend use	Toggle nav and actions	Usually resolved server-side

Ship permissions to the client as capability flags, not raw role strings
Capability flags keep UI logic stable when the role model changes
Render a clear 'no access' state instead of a blank screen or a 404
Never gate on a role read from a token the client could forge locally

Route Protection

Middleware at the edge, checks at the data layer, guards for UX.

// middleware.ts — runs before the route renders.
export function middleware(request: NextRequest) {
  const session = request.cookies.get("session");

  if (!session) {
    const url = new URL("/login", request.url);
    url.searchParams.set("next", request.nextUrl.pathname);
    return NextResponse.redirect(url);
  }

  return NextResponse.next();
}

export const config = { matcher: ["/app/:path*"] };

Middleware gives a redirect before any protected HTML is generated
Preserve the intended destination in a next param so login returns the user there
Validate the next param against your own origin to avoid open redirects
Server Components should still verify the session: middleware is not authorization
Client-side guards only prevent a flash of protected UI

Interview Takeaways

How to answer the token storage question and everything after it.

Answer storage with a threat model, then a recommendation: httpOnly cookie by default
Short access tokens, long refresh tokens, rotation with reuse detection
Single-flight refresh so concurrent 401s trigger one renewal
Logout must revoke server-side, purge caches, and broadcast across tabs
OAuth code flow with PKCE for browser clients; implicit flow is dead
Client authorization is UX; the server enforces every decision

Frequently Asked Questions

Authentication and authorization interview questions.

Authentication

Authorization

Question

Who are you?

What may you do?

Artifact

Session or token

Roles, scopes, policies

Failure code

401 Unauthorized

403 Forbidden

Frontend role

Obtain and attach credentials

Hide disallowed UI

Source of truth

Auth server

Resource server

Aspect

Cookie session

Stateless JWT

Server state

Session store lookup

None: signature verify

Revocation

Immediate: delete the record

Hard until expiry

Scaling

Needs shared store (Redis)

Scales trivially

Payload size

Tiny id

Larger, sent on every call

Cross-domain APIs

Awkward

Natural

Best for

First-party web apps

APIs, mobile, service-to-service

Authorization Code + PKCE 1. App generates code_verifier (random) and code_challenge = SHA256(code_verifier) 2. Redirect → /authorize?client_id&redirect_uri&state&code_challenge 3. User authenticates and consents at the auth server 4. Redirect back → /callback?code=...&state=... 5. App verifies state, then POSTs code + code_verifier to /token 6. Auth server returns access_token (+ refresh_token)

Token

Typical lifetime

Sent to

If stolen

Access

5–15 minutes

Resource APIs

Expires quickly

Refresh

Days to weeks

Auth server only

Serious: rotate and revoke

Minutes

Nobody: read locally

Identity disclosure

Location

XSS exposure

CSRF exposure

Survives reload

httpOnly cookie

Not readable by JS

Needs SameSite + CSRF token

Yes

In-memory variable

Only while running

None

localStorage

Fully readable

None

Yes

sessionStorage

Fully readable

None

Per tab

let refreshing: Promise<void> | null = null; async function apiFetch(input: RequestInfo, init?: RequestInit) { let res = await fetch(input, { ...init, credentials: "include" }); if (res.status !== 401) return res; // Every concurrent 401 awaits the same in-flight refresh. refreshing ??= refreshSession().finally(() => { refreshing = null; }); try { await refreshing; } catch { redirectToLogin(); throw new Error("Session expired"); } return fetch(input, { ...init, credentials: "include" }); }

RBAC

ABAC

Decides on

Role assignment

Attributes and context

Example

Admin may delete users

Owner may edit before publish

Strength

Easy to reason about and audit

Fine-grained, data-aware

Weakness

Role explosion at scale

Harder to test and explain

Frontend use

Toggle nav and actions

Usually resolved server-side

// middleware.ts — runs before the route renders. export function middleware(request: NextRequest) { const session = request.cookies.get("session"); if (!session) { const url = new URL("/login", request.url); url.searchParams.set("next", request.nextUrl.pathname); return NextResponse.redirect(url); } return NextResponse.next(); } export const config = { matcher: ["/app/:path*"] };

About this chapter

About this module

Why this matters

Key topics covered

Where you'll use it

AuthN vs AuthZ

The line that must be said

Sessions vs JWT

Common hybrid

OAuth 2.0 & PKCE

OpenID Connect & SSO

Frequent mix-up

Token Lifetimes

Token Storage Trade-offs

How to phrase it

Refresh & Rotation

Why rotation matters

Single-Flight 401 Handling

Logout & Revocation

RBAC vs ABAC

Route Protection

Interview Takeaways

Frequently Asked Questions

About this chapter

About this module

Why this matters

Key topics covered

Where you'll use it

AuthN vs AuthZ

The line that must be said

Sessions vs JWT

Common hybrid

OAuth 2.0 & PKCE

OpenID Connect & SSO

Frequent mix-up

Token Lifetimes

Token Storage Trade-offs

How to phrase it

Refresh & Rotation

Why rotation matters

Single-Flight 401 Handling

Logout & Revocation

RBAC vs ABAC

Route Protection

Interview Takeaways

Frequently Asked Questions