Lesson 9 of 30

Authentication: JWTs vs Sessions

Q: Would you use session-based or JWT-based authentication for a new app? Walk through the actual tradeoff.

A strong answer covers: Sessions: server holds state, trivially revocable, requires a lookup per request and server-side storage; JWTs: stateless, no lookup/storage needed (scales easily), but can't be revoked before expiry — the server has nothing to delete; JWT payloads are encoded, not encrypted, and token storage location (localStorage vs httpOnly cookie) has real security implications (XSS vs CSRF exposure).

Two different answers to 'how does the server remember you're logged in on the next request' — one keeps state on the server, one packs it into the token itself. Neither is simply 'the modern one.'

14 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

Is the payload of a JWT encrypted, meaning it's hidden from anyone who intercepts it?

No — it's base64-encoded, not encrypted; anyone can decode and read itYes — the signature both encrypts and authenticates the payloadYes, but only the parts of the payload marked as private claims

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Authentication: JWTs vs Sessions

What interviewers actually ask about this, and what a strong answer has to cover.

Would you use session-based or JWT-based authentication for a new app? Walk through the actual tradeoff.

A strong answer covers

Sessions: server holds state, trivially revocable, requires a lookup per request and server-side storage
JWTs: stateless, no lookup/storage needed (scales easily), but can't be revoked before expiry — the server has nothing to delete
JWT payloads are encoded, not encrypted, and token storage location (localStorage vs httpOnly cookie) has real security implications (XSS vs CSRF exposure)

Likely follow-ups

How would you mitigate JWT's revocation problem in practice?
Why shouldn't you put sensitive data directly in a JWT payload?
What's the security tradeoff between storing a token in localStorage versus an httpOnly cookie?

Practice these with the AI interviewer →

The plain-language idea

HTTP itself is stateless — every request is independent, with no memory of the last one. Both approaches exist to answer the same question ("is this request from a logged-in user, and who?") with opposite tradeoffs.

Session-based auth: on login, the server creates a session record (in memory or a database) and gives the browser a session id in a cookie. Every later request sends that cookie; the server looks up the id to find who's logged in. The server holds the actual state.

JWT-based auth (token-based): on login, the server creates a signed token containing the user's info directly ({ userId, role, exp }), and hands it to the client. Every later request sends that token; the server just verifies the signature — no lookup, no stored session, because the token is the proof.

Sessions vs JWTs: who holds the actual stateStep 1 of 3

Session: the server stores { sessionId: userId }; the client just holds an opaque cookie pointing to it.

What people usually miss

Watch out

"JWT is stateless" is exactly why revocation is hard. If a user's account is compromised or a permission changes, an already-issued JWT is still valid (and still trusted) until it expires — a real, deliberate design tradeoff, not an implementation bug. Short expiry times plus a refresh-token flow is the standard mitigation.
A JWT's payload is base64-encoded, not encrypted. Anyone can decode and read it (paste one into jwt.io) — the signature only proves it wasn't tampered with, it doesn't hide the contents. Never put secrets in a JWT payload.
Where the token is stored matters a lot. localStorage is readable by any JavaScript on the page, making it vulnerable to XSS; an httpOnly cookie is invisible to JavaScript entirely, closing that specific attack surface (at the cost of needing CSRF protection instead).

Why this matters in interviews

"Would you use JWTs or sessions for this app, and why?" is a genuine engineering tradeoff question, not a trick with one right answer — a strong response names the real tradeoff (revocability and server state vs. statelessness and scale) instead of treating JWT as an automatic upgrade.