JWT interview questions and answers

"A user clicks log out," the interviewer said. "What happens to their JWT?" The candidate said it gets deleted. "From the browser, yes. What about the copy someone captured off the network an hour ago?" And that is the whole problem with JWTs in one question: you cannot un-issue something you never stored.

JWT interview questions are really questions about a tradeoff — you gain stateless verification and give up revocation. Candidates who describe JWTs as simply "better than sessions" get taken apart in follow-ups. This guide covers the structure, signing, the revocation problem, storage, refresh rotation, and the attacks interviewers name.

What JWT interviews actually test

JWT interview questions appear in backend, full-stack and security loops. Five bands:

• Structure and mechanics — the three parts, what signing does and does not do.
• The revocation problem — the question above, and its realistic answers.
• Storage — localStorage vs cookies, and the XSS/CSRF tradeoff.
• Refresh tokens — rotation, reuse detection, expiry strategy.
• Attacks — alg:none, algorithm confusion, weak secrets, missing claim validation.

Structure, and what signing actually guarantees

A JWT is three base64url-encoded parts separated by dots: a header (algorithm and type), a payload (claims), and a signature. The single most important thing to say: a signed JWT is not encrypted. The payload is encoded, not hidden — anyone holding the token can decode and read it.

So the signature guarantees integrity and authenticity (this token was issued by someone with the key and has not been altered), not confidentiality. Never put anything sensitive in a payload — no passwords, no PII you would not hand to the user, no internal identifiers you rely on being secret. Interviewers ask this constantly and it is a genuine production bug.

Know the standard claims and why they exist: sub (subject), iss (issuer), aud (audience), exp (expiry), iat (issued at), nbf (not before), jti (a unique token ID, which matters for the denylist approach below). Know that HS256 is symmetric — one shared secret signs and verifies — while RS256 is asymmetric, so a private key signs and services verify with a public key. RS256 is the right answer when multiple services verify tokens, because you do not distribute a signing secret to every consumer.

If you genuinely need confidentiality, the answer is JWE (encrypted JWT) rather than putting secrets in a JWS payload — naming that distinction is a strong signal.

The revocation problem

Back to the intro. Because verification is stateless — the server checks a signature rather than looking anything up — there is no place to mark a token as dead. A stolen token stays valid until exp. This shows up as several interview scenarios: logout, a user whose permissions were downgraded, a compromised account, a fired employee.

The realistic answers, and interviewers want the tradeoffs:

• Short-lived access tokens (5–15 minutes) plus a long-lived refresh token. The standard design. It does not eliminate the window, it bounds it — a stolen access token is useless within minutes, and revocation happens at the refresh step.
• A denylist of jti values until they expire, checked on each request. This works and it reintroduces the state you adopted JWTs to avoid — but the denylist is small (only unexpired revoked tokens) and lives in Redis, so it is far cheaper than a full session store.
• A token version per user — store an integer in the user record, include it in the token, bump it to invalidate everything for that user. Cheap and effective for "log out everywhere" and password changes, though it means a per-request user lookup.
• Accept the window explicitly — for low-risk applications, a 15-minute exposure may be a reasonable, documented decision.

The mature framing to state: if you need immediate revocation on every request, server-side sessions are the simpler correct answer. Candidates who can say "JWTs may be the wrong choice here" score higher than those who defend them universally. Our REST API interview questions guide covers the surrounding API design.

Where to store the token

A guaranteed question, and the honest answer is that both options trade one attack for another:

• localStorage — simple, works across domains, immune to CSRF because nothing is sent automatically. Vulnerable to XSS: any injected script can read it and exfiltrate the token.
• httpOnly cookie — JavaScript cannot read it, so XSS cannot steal it directly. But cookies are sent automatically, which reintroduces CSRF, mitigated with SameSite=Lax or Strict plus CSRF tokens for state-changing requests. Also needs Secure.

The current mainstream recommendation is the httpOnly + Secure + SameSite cookie, because XSS is more common and more damaging than CSRF, and SameSite handles most CSRF for free. Say the reasoning rather than the conclusion — and add the honest caveat that with XSS an attacker can still make authenticated requests from the victim's browser even without reading the token, so no storage choice saves you from XSS.

Never store tokens in sessionStorage and call it more secure — it has the same XSS exposure with worse ergonomics. And never put a token in a URL query string, where it lands in logs, referrer headers and browser history.

Refresh tokens and rotation

The design most loops expect you to describe:

// Refresh with rotation + reuse detection
async function refresh(presentedToken) {
  const stored = await db.findRefreshToken(hash(presentedToken));

  if (!stored) throw new AuthError("unknown token");

  if (stored.usedAt) {
    // Already redeemed once. Either a replay or a stolen token —
    // we cannot tell which, so kill the whole family.
    await db.revokeFamily(stored.familyId);
    throw new AuthError("reuse detected");
  }

  await db.markUsed(stored.id);
  const next = await db.issueRefreshToken(stored.userId, stored.familyId);

  return {
    accessToken: signAccess(stored.userId, { expiresIn: "10m" }),
    refreshToken: next,   // single use — the old one is now dead
  };
}

Explain the two ideas. Rotation means each refresh token is single-use and returns a new one. Reuse detection means if a token is presented twice, either the legitimate client replayed it or an attacker stole it — and since you cannot distinguish, you revoke the entire token family and force re-authentication. That combination is what makes long-lived refresh tokens acceptable.

Other details worth knowing: store refresh tokens hashed (they are credentials), keep them in an httpOnly cookie scoped to the refresh endpoint path, and handle the race where several concurrent requests all trigger a refresh at once — usually with a short grace window or a client-side mutex.

The attacks interviewers name

• alg:none — the classic. An attacker changes the header algorithm to none and strips the signature; a naive library trusts it. Fix: never let the token declare its own algorithm — pin the expected algorithm server-side.
• Algorithm confusion (RS256 → HS256) — the attacker switches the header to HS256 and signs with the public key, which a careless verifier treats as the HMAC secret. Same fix: pin the algorithm.
• Weak HS256 secrets — short secrets are brute-forcible offline, since the attacker has the token. Use a long random secret, or RS256.
• Missing claim validation — verifying the signature but not checking exp, aud or iss. A valid token issued for a different service is still cryptographically valid; aud is what stops it being accepted.
• Sensitive data in the payload — the decoding point from earlier.
• No expiry — a token without exp is a permanent credential.

The general principle to state: use a maintained library, verify with pinned parameters, and never trust anything the token says about how it should be validated. Our API security interview questions guide covers the wider surface and the cybersecurity analyst guide covers the defensive side.

The RFCs, jwt.io, OWASP, ChatGPT — where each fits

• jwt.io — the debugger everyone uses; paste a token and see the claims. Also the fastest way to demonstrate to yourself that the payload is readable.
• OWASP cheat sheets — the JWT and session management sheets are the source of most storage and attack questions, and are free.
• RFC 7519 and RFC 8725 — the spec and the Best Current Practices document. 8725 in particular is short and directly interview-relevant.
• Implementing auth once yourself — highest yield. Issue tokens, implement refresh rotation, then try the alg:none attack against your own endpoint.
• Auth0 and Okta engineering blogs — well-written explanations of rotation and reuse detection.
• ChatGPT — good for generating auth code and explaining claims. It will not ask what happens to the copy of the token captured an hour ago.
• Greenroom — the spoken layer. Ari, the AI interviewer, runs the round out loud and pushes the tradeoff follow-up when your answer treats JWTs as strictly better than sessions. Fair tradeoff: Ari will not audit your implementation.

How to prepare for a JWT interview

• Week 1: mechanics. Decode real tokens on jwt.io, explain the three parts and HS256 vs RS256 aloud, and say "signed is not encrypted" until it is reflexive.
• Week 2: revocation. Implement short access tokens plus a denylist and a token-version approach, and be able to argue when sessions beat JWTs.
• Week 3: storage and refresh. Build rotation with reuse detection, and rehearse the localStorage-versus-cookie tradeoff as a reasoned answer rather than a verdict.
• Final week: attack your own implementation with alg:none and algorithm confusion, then run two full spoken mocks with security follow-ups.

Building the rest of the stack? The OAuth 2.0 interview questions guide covers the protocol JWTs usually travel in, the API security guide covers the wider surface, and the REST API guide covers the design layer.

Frequently asked questions

What are the most common JWT interview questions?

The most common questions cover the three parts of a JWT and why signing does not mean encryption, what happens to a token when a user logs out and how you revoke one, whether to store tokens in localStorage or an httpOnly cookie and the XSS versus CSRF tradeoff, how refresh token rotation and reuse detection work, the difference between HS256 and RS256, and attacks such as alg:none and algorithm confusion.

Is a JWT encrypted?

No. A standard signed JWT is base64url-encoded, not encrypted, so anyone holding the token can decode and read the payload. The signature guarantees integrity and authenticity — that the token was issued by a holder of the key and has not been modified — but provides no confidentiality. Never place passwords, sensitive personal data or secret internal identifiers in a payload. If you genuinely need confidentiality, use an encrypted JWT, known as JWE.

How do you revoke a JWT?

You cannot revoke a stateless token directly, because verification checks a signature rather than consulting storage. The practical approaches are short-lived access tokens of five to fifteen minutes paired with refresh tokens so the exposure window is bounded, a denylist of jti values held in Redis until they expire, or a token version integer stored per user that you increment to invalidate every existing token. If you need instant revocation on every request, server-side sessions are simpler and more appropriate.

Should you store a JWT in localStorage or a cookie?

The mainstream recommendation is an httpOnly, Secure cookie with SameSite set to Lax or Strict, because JavaScript cannot read it and so cross-site scripting cannot steal the token directly, while SameSite handles most cross-site request forgery. localStorage avoids CSRF entirely but is readable by any injected script. The honest caveat is that with XSS an attacker can still issue authenticated requests from the victim's browser, so no storage choice fully mitigates it.

What is refresh token rotation and reuse detection?

Rotation means each refresh token is single-use: presenting it returns a new access token and a brand new refresh token, invalidating the old one. Reuse detection means that if an already-redeemed token is presented again, the system cannot tell whether the legitimate client replayed it or an attacker stole it, so it revokes the entire token family and forces re-authentication. Together they make long-lived refresh tokens acceptably safe.

What is the alg:none attack on JWTs?

An attacker modifies the token header to specify an algorithm of none and removes the signature, hoping the server trusts the token's own declaration about how it should be verified. A related attack is algorithm confusion, where an RS256 token is switched to HS256 and signed with the public key, which a careless verifier treats as the HMAC secret. The fix for both is to pin the expected algorithm server-side rather than reading it from the header.