JWT Interview Questions: 15 Questions With Complete Answers

JWT questions appear in backend, full-stack, and security interviews. They test whether you understand authentication deeply or just copy-pasted code. These 15 questions cover everything from basic structure to attack vectors — the range you will actually encounter.

Structure and Claims Questions

Q: What are the three parts of a JWT and what does each contain?

A JWT is three base64url-encoded strings separated by dots: header.payload.signature. The header contains the token type (JWT) and the signing algorithm (e.g., HS256, RS256). The payload contains claims — statements about the subject and token metadata. The signature is a cryptographic hash of the header and payload, used to verify the token has not been tampered with.

Q: What is the difference between registered, public, and private claims?

Registered claims are the seven IANA-defined claims (sub, iss, aud, exp, iat, nbf, jti). Public claims are names registered in the IANA JWT Claims Registry to avoid collisions — like the OpenID Connect claims (email, name, picture). Private claims are custom application-specific claims not registered anywhere, meaningful only within your own system.

Q: What is the difference between exp, iat, and nbf?

All three are Unix timestamps. exp is when the token expires and must be rejected. iat is when the token was issued — used to calculate token age. nbf (not before) is when the token becomes valid — useful for tokens that should not be accepted before a future time. All three are optional per the spec but exp is strongly recommended.

Algorithm and Verification Questions

Q: What is the difference between HS256 and RS256?

HS256 (HMAC-SHA256) is symmetric — the same secret key signs and verifies the token. Only parties that share the secret can verify tokens. RS256 (RSA-SHA256) is asymmetric — a private key signs and a public key verifies. Services can verify tokens without having the signing key. RS256 is preferred when multiple services need to verify tokens or when the verifier should not be trusted with the signing key.

Q: What is the "none" algorithm vulnerability?

The JWT spec allowed "alg": "none" for unsigned tokens. Early libraries would accept these as valid, allowing an attacker to forge any payload by setting the algorithm to "none" and providing no signature. The fix is to never accept tokens with alg:none, and to always hard-code the expected algorithm server-side rather than reading it from the token header.

Q: Explain the RS256/HS256 algorithm confusion attack.

If a server uses RS256 and publishes its public key, an attacker can create a new token signed with HS256 using the public key as the secret. If the server auto-detects the algorithm from the token header, it verifies the HS256 token using the public key — and the verification succeeds. Mitigation: always specify the expected algorithm explicitly in your verification call, never allow the token to self-declare its algorithm.

Sell Custom Apparel — We Handle Printing & Free Shipping

Storage and Security Questions

Q: Where should you store a JWT in a browser application?

The safest approach for SPAs: store short-lived access tokens in memory (JavaScript state), and long-lived refresh tokens in httpOnly+secure+sameSite=strict cookies. localStorage is susceptible to XSS theft. httpOnly cookies are not readable by JavaScript, eliminating XSS token theft, but require CSRF mitigations (sameSite=strict covers most cases).

Q: How do you revoke a JWT?

JWTs are stateless — there is no native revocation mechanism. Options: use short expiry times to limit the revocation window; maintain a server-side token blocklist (using the jti claim as the key, usually in Redis); use opaque refresh tokens (which can be deleted server-side) paired with short-lived JWTs; or move to a stateful reference token pattern where the JWT is just a pointer to a server-side session.

Q: What should never be stored in a JWT payload?

Passwords, raw credit card numbers, SSNs, API keys, or any secret. JWT payloads are base64-encoded, not encrypted — anyone who has the token can decode and read all claims without any key. JWT protects integrity (via the signature), not confidentiality.

Implementation and Design Questions

Q: What is the difference between an ID token and an access token?

An ID token (OpenID Connect) contains user identity information for the client to display (name, email, profile picture). An access token is for authorizing API calls — your API validates it to decide what the caller is allowed to do. You should never use an ID token to authorize API calls, and you should never use an access token as proof of identity for display purposes.

Q: How would you implement JWT refresh tokens?

Issue a short-lived access token (15 min) and a long-lived refresh token (30 days). Store the refresh token in an httpOnly cookie and persist it server-side (hashed) in a database. When the access token expires, the client calls a /refresh endpoint — the server validates the refresh token against the database, issues a new access token, and optionally rotates the refresh token. On logout, delete the refresh token from the database, immediately invalidating the session.

Q: Can you modify a JWT payload and use it?

Not without invalidating the signature. If you change even one byte of the payload, the signature check will fail on a properly implemented server. This is the core security guarantee of JWTs — the signature proves the payload has not been modified since it was issued by the trusted party. A server that skips signature verification can be fooled by a modified payload.

Q: What is the maximum recommended size for a JWT?

There is no hard limit in the spec, but practical limits exist. HTTP headers have browser and server limits around 8KB total. Cookies max out at 4KB. A typical JWT with a few claims is 200-500 bytes. Tokens above 4KB can cause issues. If your token is getting large, consider moving verbose data (like long permission lists) to a server-side lookup rather than embedding them all in the token.

Frequently Asked Questions

Are these questions asked in Google, Amazon, or FAANG interviews?

JWT questions appear most often in interviews for backend roles, full-stack positions, and security engineer roles. FAANG interviews tend to focus more on systems design, but JWT security questions are common at startups and mid-size companies building auth systems.

What is the most important JWT concept to know for interviews?

The distinction between decoding and verifying. Many candidates confuse "decode" (reading the payload) with "validate" (confirming the signature). Being clear that decoding requires no key and that authorization decisions must only be made after server-side signature verification shows real depth.

Do I need to memorize the base64url encoding details?

Not the exact details, but you should know that JWT uses base64url (not standard base64), that it strips padding, and that this is why you sometimes need to add padding back when decoding manually. Understanding the why matters more than memorizing the + vs - substitution.