FrontendHaltAuthentication: sessions vs. tokens
Compare cookie-based sessions and token-based auth by storage, revocation, and cross-origin behavior.
WHAT YOU WILL BE ABLE TO DO
Learning outcomes
- Explain authentication: sessions vs. tokens in plain language.
- Connect the behavior to the underlying browser or framework model.
- Implement the core pattern and reason through edge cases.
- Answer common follow-ups without relying on memorized phrases.
01Explain it simply
Session-based auth stores a session id in a cookie that the server looks up against server-side state on every request. Token-based auth, commonly JWTs, issues a signed, self-contained token the client presents on each request; the server can verify it without a database lookup.
One-line definition: Compare cookie-based sessions and token-based auth by storage, revocation, and cross-origin behavior.
02Mental model
The real trade-off is where truth lives and how revocation works. Sessions keep truth server-side, so revoking access is an immediate delete. Self-contained tokens keep truth in the token itself, so revoking before natural expiry requires extra machinery such as short expiry plus refresh or a denylist, but they scale better across stateless services and origins.
03Step by step
- Decide whether auth state needs to be revocable instantly, which favors sessions.
- Decide whether the client needs to call multiple independent services or origins, which favors tokens.
- If using tokens, keep access-token lifetime short and use a refresh flow.
- Store session cookies as Secure, HttpOnly, and SameSite; treat token storage exposure explicitly.
- Never make the client responsible for deciding what it's authorized to do — only the server decision counts.
04Working example
// Session cookie set by the server after loginSet-Cookie: sid=abc123; Secure; HttpOnly; SameSite=Lax
// Token sent explicitly on each requestfetch('/api/orders', { headers: { Authorization: `Bearer ${accessToken}` },});The session cookie is opaque to the client and attached automatically by the browser; the server looks up abc123 against its own store. The bearer token is meaningful on its own — a resource server can verify its signature and claims without asking anywhere else, which is what makes it useful across services.
05Where it is used
- Sessions for traditional server-rendered apps with a single backend needing instant revocation
- Tokens for microservices, mobile plus web sharing one API, or third-party API access
- Refresh tokens for keeping short-lived access tokens usable without re-login
- OAuth/OIDC for delegated login through a third-party identity provider
06Common mistakes
- Storing a long-lived JWT in localStorage where XSS can read and replay it
- Treating a JWT's claims as still valid without checking expiry and signature on every request
- Believing a JWT can be 'logged out' instantly without a revocation mechanism
- Skipping SameSite/CSRF protection because 'we use tokens, not cookies' when refresh tokens are still cookie-stored
07Interview answer
Frame the comparison around revocation and trust location — a token isn't 'more secure' than a session, it just moves where truth is checked, with a different failure mode for logout.
Why can't a stolen JWT be invalidated the same way a stolen session id can?
A session id is just a lookup key the server controls and can delete immediately; a self-contained JWT remains cryptographically valid until it expires, so revoking it early requires extra state like a denylist or short expiry with refresh-token rotation.
DDConcept deep dives
Deep dive 1
Revocation cost is the real dividing line
A session id is a pointer into server-controlled state, so deleting that state revokes access immediately and completely. A self-contained token like a JWT remains valid to anyone who can verify its signature until it naturally expires, so instant revocation needs additional infrastructure such as a denylist, or a short expiry paired with refresh-token rotation.
- Sessions default to easy revocation; tokens default to easy statelessness.
- Neither approach is universally 'more secure' — they shift where trust and truth live.
- A hybrid — short-lived tokens plus a revocable refresh token — is a common compromise.
Deep dive 2
Token exposure depends on where it's stored, not just its format
A JWT stored in memory disappears on reload and is unreachable by inspecting browser storage; one stored in localStorage is readable by any script in the origin, including an XSS payload; one stored in an HttpOnly cookie is unreadable by script but sent automatically, reopening CSRF as a concern. The token format doesn't determine the risk — the storage and transmission choice does.
- In-memory storage minimizes XSS exposure at the cost of requiring a refresh flow on reload.
- HttpOnly cookies close off direct JavaScript theft but require CSRF protection.
- Every storage choice is a trade-off, not a universally 'correct' answer.
Deep dive 3
Delegated authorization solves a different problem than login
OAuth's core purpose is letting a user grant a third-party application scoped access to their data on another service, without ever sharing their actual password with that application. OpenID Connect builds an identity layer on top of that same delegation flow so 'login with X' can also assert who the user is, not just what they're allowed to access.
- OAuth is about authorization (what an app can do); OIDC adds authentication (who the user is).
- The state parameter in an OAuth redirect defends against a specific request-forgery attack on the flow itself.
- A bespoke login system and OAuth solve overlapping but distinct problems.
QAInterview questions and model answers
Attempt each answer aloud before opening it. The model answer shows the depth and precision expected in an interview; it is not a script to memorize.
Intermediate · Conceptual · 1 min · Question 1What is the core trade-off between session and token-based authentication?Open model answer
Model answer
Sessions keep authorization truth in server-side state, making revocation immediate but requiring shared or replicated storage across servers. Tokens are self-contained and verifiable without a lookup, scaling better across services, but revoking one before expiry needs extra mechanisms.
Open question page →Intermediate · Conceptual · 1 min · Question 2Why do token-based systems use short-lived access tokens with a refresh token?Open model answer
Model answer
A short expiry limits the damage window if an access token leaks, while a longer-lived refresh token, often stored more securely, lets the client obtain new access tokens without forcing the user to log in repeatedly.
Open question page →Intermediate · Conceptual · 1 min · Question 3What does OAuth actually solve, compared to a bespoke login form?Open model answer
Model answer
OAuth lets a user grant a third-party application limited access to their data on another service without sharing their password with that application, using delegated authorization tokens instead.
Open question page →Intermediate · Conceptual · 1 min · Question 4Why does SameSite matter even in a token-based system?Open model answer
Model answer
If refresh tokens or any session-establishing value is stored in a cookie, SameSite still controls whether that cookie is sent on cross-site requests, so CSRF exposure isn't eliminated just because access tokens are sent via headers.
Open question page →Intermediate · Conceptual · 1 min · Question 5What is the risk of validating a JWT without checking its signature and expiry?Open model answer
Model answer
A forged or expired token would be treated as valid, letting an attacker impersonate any user by crafting an arbitrary payload; every verification must check signature validity and expiry, not just decode the payload.
Open question page →Intermediate · Conceptual · 1 min · Question 6How should a frontend decide where to store an access token in memory versus persistent storage?Open model answer
Model answer
In-memory storage limits exposure since it disappears on page reload and isn't reachable by looking at disk or browser storage inspection, at the cost of requiring re-authentication or a silent refresh flow after a reload.
Open question page →Advanced · Conceptual · 1 min · Question 7What is the purpose of the state parameter in an OAuth redirect flow?Open model answer
Model answer
It is an unpredictable value the client generates before redirecting and verifies on return, preventing an attacker from tricking a user into completing an authorization flow initiated by the attacker.
Open question page →Advanced · Conceptual · 1 min · Question 8Why is refresh-token rotation used?Open model answer
Model answer
Each use of a refresh token issues a new one and invalidates the old, so a leaked refresh token that gets used by an attacker is detected the next time the legitimate client tries to use its now-invalidated copy.
Open question page →Advanced · Conceptual · 1 min · Question 9What does a token's audience (aud) claim protect against?Open model answer
Model answer
It ensures a token issued for one API or service can't be replayed against a different service that also trusts the same issuer, since that service can check the token was actually intended for it.
Open question page →Beginner · Conceptual · 1 min · Question 10Is HTTPS required for cookie-based sessions to be meaningful?Open model answer
Model answer
Effectively yes — without it, a session cookie can be observed in plaintext over the network, and the Secure attribute itself requires HTTPS to have any enforcement effect.
Open question page →SCScenario questions
Scenario 1
A single-page app currently stores its JWT access token in localStorage and has just failed a security review for XSS exposure.
- Confirm what an XSS payload could currently exfiltrate.
- Move toward keeping the access token in memory only.
- Use an HttpOnly cookie for the refresh token so JavaScript can't read it.
- Keep access-token lifetime short to shrink the exposure window regardless of storage.
Reveal worked answer
I would keep the access token in memory so a page reload requires a silent refresh, and move the refresh token into an HttpOnly, Secure, SameSite cookie so client-side script can't read it even under XSS. I would also shorten access-token lifetime and add CSRF protection around the refresh endpoint since it's now cookie-based.