Top 25 JWT Interview Questions and Answers [2026]

TL;DR: JWT interviews in 2026 test signature checks, claim validation, key rotation through JWKS, and how tokens are stored and revoked. Candidates should know that RFC 9700 now sets the OAuth security baseline, and that RFC 10017 tells browser apps to keep tokens on a backend instead of in JavaScript.

In August 2026 the IETF published RFC 10017, its best practice for OAuth in browser apps. It strongly recommends a backend for frontend, so tokens never reach the browser at all.

That settles an old interview argument about localStorage versus cookies. A senior engineer still has to get the rest right: the token format, validation, keys, storage and revocation.

JWT Structure and Claims

1. What are the three parts of a JWT?

A signed JWT is a header, a payload and a signature, each base64url-encoded and joined with dots.

• Header: JSON naming the algorithm (alg), often a key ID (kid) and a type (typ).
• Payload: JSON holding the claims, such as sub, exp and any custom data.
• Signature: computed over the encoded header, a dot, and the encoded payload.

eyJhbGciOiJFUzI1NiIsImtpZCI6ImsxIn0   // header
.eyJzdWIiOiI0MiIsImV4cCI6MTc5MDAwMDAwMH0   // payload
.MEUCIQD...   // signature

This is the Compact Serialization. RFC 7519 requires JWTs to use it, even though JWS also defines a JSON form.

2. Is the payload of a JWT encrypted?

No. A normal JWT is a JWS: it is signed, not encrypted. Anyone who holds the token can base64url-decode the payload and read it.

The signature proves who issued the token and that nobody changed it. It hides nothing. So a JWT should never carry passwords, card numbers or personal data the client should not see.

3. What is the difference between JWS and JWE?

JWS gives integrity and authenticity; JWE gives confidentiality. A JWS has three parts and a readable payload. A JWE has five parts: header, encrypted key, IV, ciphertext and authentication tag.

Use a JWE only when the claims must stay secret from the party carrying the token. Many teams sign first and then encrypt, which is called a nested JWT.

The receiver must then check both layers with keys it chose, never keys the token names.

4. What do the registered claims iss, sub, aud, exp, nbf, iat and jti mean?

They are the standard claims from RFC 7519, and a validator should know each one:

• iss: who issued the token. Check it against the issuers you trust.
• sub: who the token is about, usually a user ID.
• aud: who the token is for. An API must reject a token meant for another API.
• exp: when it expires. nbf: not valid before this time. Both are seconds since the epoch.
• iat: when it was issued.
• jti: a unique ID, useful for replay checks and deny lists.

RFC 7519 lets a validator allow "some small leeway, usually no more than a few minutes" for clock skew on exp and nbf.

5. When would you choose HS256, RS256 or ES256?

Choose HS256 only when the issuer and every verifier are the same trusted service. Choose an asymmetric algorithm such as RS256, ES256 or Ed25519 when other services verify the token.

HS256 uses one shared secret to sign and to verify. Every service that can check a token can also forge one. With RS256 or ES256, the issuer keeps the private key and verifiers only get the public key.

ES256 and Ed25519 give much smaller keys and signatures than RSA.

An HMAC secret must be random and at least as long as the hash output: 256 bits for HS256. A short human-chosen secret can be brute-forced offline from a single token.

6. What is the difference between a JWT and an opaque token?

A JWT carries its own claims, so an API can validate it locally with a public key. An opaque token is a random string, so the API must ask the authorization server about it.

The API does that through token introspection (RFC 7662). The trade-off is simple. A JWT saves a network call per request, but it stays valid until it expires. An opaque token costs a lookup, but the server can revoke it at once.

Some systems use opaque tokens at the edge and swap them for JWTs inside the network.

Validating a JWT

7. Walk through how an API should validate an incoming JWT.

Check the format, pin the algorithm, verify the signature with a key you trust, then check the claims. Reject the token at the first failure.

1. Confirm it is a compact JWT: three base64url parts and nothing else.
2. Read alg and reject it unless it is in your allowlist for this issuer.
3. Find the key by kid in the issuer's key set, and confirm that key is meant for that algorithm.
4. Verify the signature.
5. Check iss, aud, exp and nbf, and typ if the token type is defined.
6. Only then read scopes, roles and other claims.

Use a maintained library for steps 1 to 4, and configure it. Most JWT bugs come from a library called with its defaults, not from broken crypto.

8. What is the alg: none attack, and how do you stop it?

The attacker sets "alg": "none", removes the signature, and edits the payload. A library that trusts the header then accepts the forged token with no signature at all.

The fix is an allowlist of algorithms set by the server, never taken from the token. The draft update to the JWT best practices records a variant: some libraries blocked none but compared names without case, so noNE slipped through.

That is why the draft says to use allowlists rather than blocklists.

9. What is algorithm confusion between RS256 and HS256?

The attacker changes alg from RS256 to HS256 and signs the token with HMAC, using the server's RSA public key as the secret.

A library that picks the algorithm from the header then verifies it with that same public key, and the forged token passes.

The public key is public, so anyone can do this. The fix is to bind each key to exactly one algorithm. The draft JWT best practices state it directly: "each key MUST be used with exactly one algorithm."

// Node.js, jose library: the allowlist comes from config, not the token
const { payload } = await jwtVerify(token, JWKS, {
  issuer: "https://auth.example.com",
  audience: "orders-api",
  algorithms: ["ES256"],
});

10. Why must you validate the aud claim?

Without an audience check, a token issued for one API works on every API that trusts the same issuer. A low-value service could then leak tokens that open a high-value one.

Each API should accept only tokens whose aud names it. Pair this with narrow scopes, so a stolen token opens as little as possible.

11. How can the kid, jku and x5u headers be abused?

All three come from the token, so all three are attacker input. A kid placed into a file path or SQL query invites path traversal or injection.

A jku or x5u URL that the server fetches without checks lets an attacker point it at their own key, or at an internal host (SSRF).

Treat kid as a lookup key into a key set you already trust. Ignore jku and x5u, or accept them only for URLs on a fixed allowlist.

Keys and Token Lifecycle

12. What is a JWKS endpoint, and how does key rotation work?

A JWKS endpoint publishes the issuer's public keys as a JSON Web Key Set, defined in RFC 7517. Verifiers fetch it, cache it, and pick the key whose kid matches the token.

Safe rotation takes three steps. Publish the new key first. Start signing with it once verifiers have had time to refresh their cache. Remove the old key only after every token it signed has expired.

A verifier that sees an unknown kid should refetch the set once, with a rate limit, so an attacker cannot use random kid values to flood the issuer.

13. JWTs are stateless. How do you revoke one?

You cannot un-issue a self-contained token, so you limit its life and add state only where you need it.

• Short access tokens: 5 to 15 minutes caps the damage window.
• Revoke the refresh token: the user cannot get new access tokens, so logout takes effect within one access token lifetime.
• Deny list: store revoked jti values, or a per-user "tokens issued before" time, until the tokens expire. This adds a lookup to every request.
• Introspection: for high-risk APIs, ask the authorization server on each call.

14. How does refresh token rotation detect theft?

Each refresh returns a new refresh token and invalidates the old one. If an old token is used again, the server knows two parties hold the same grant, so it revokes the whole family.

RFC 9700 notes the server "cannot determine which party submitted the invalid refresh token". So it revokes the active token too. The real user has to log in again, and the thief is locked out.

Rotation needs a grace period in practice, because a mobile app may retry a refresh after a network drop.

15. What is the difference between an ID token and an access token?

An ID token tells the client who logged in; an access token tells an API what the client may do. The ID token is an OpenID Connect JWT whose audience is the client app. The client validates it and reads the user's identity.

The access token's audience is the API. Sending an ID token to an API as a bearer token is a common bug. With explicit typing and audience checks in place, the API will reject it.

16. How does DPoP make a stolen token useless?

DPoP binds a token to a key pair held by the client, so the token only works with a fresh proof signed by that key. It is defined in RFC 9449.

On every request the client sends a DPoP header. It holds a short JWT typed dpop+jwt with the HTTP method (htm), the URL (htu), a unique jti, and a hash of the access token (ath).

A JWT access token carries cnf.jkt, the thumbprint of the client's public key. The API checks that the proof was signed by that key. A thief who copies the token but not the private key cannot make a valid proof.

GET /orders HTTP/1.1
Authorization: DPoP eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCJ9...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2In0...

Storing Tokens

17. What is wrong with keeping a JWT in localStorage?

Any script running on the page can read localStorage, so one XSS bug hands the token to an attacker. That includes a compromised third-party script.

RFC 10017 goes further. Once an attacker runs code in the page, they can often start a new silent login in a hidden iframe and get fresh tokens, wherever the old ones were kept. Moving tokens out of localStorage alone does not fix that.

Keeping them out of the browser does.

18. HttpOnly cookie or Authorization header: which should a web app use?

For a first-party web app, an HttpOnly, Secure, SameSite cookie holding a session is the safer default. A bearer token in an Authorization header suits API clients that are not browsers.

A cookie does not stop XSS from sending requests while the user is on the page. It stops the attacker from taking the token away and using it later.

19. What is the backend-for-frontend pattern?

A backend for frontend (BFF) is a small server that runs the OAuth flow as a confidential client and keeps every token on the server side. The browser only gets an HttpOnly session cookie.

The BFF attaches the access token when it forwards API calls.

RFC 10017 says this pattern is "strongly recommended for business applications, sensitive applications, and applications that handle personal data."

It rates a browser-only app that keeps tokens in JavaScript as "not recommended" for those same apps.

20. How should a client handle an expired access token?

Refresh once, retry once, and send the user to log in if the refresh fails. On a 401, the client pauses new calls and makes a single refresh request, even if many calls failed at once. It then replays the queued calls with the new token.

A good client also refreshes a little before exp, which avoids most 401 responses in the first place. Without a single shared refresh, parallel requests each rotate the refresh token. That can trip reuse detection and log the user out.

What Changed Recently

21. What does the update to the JWT best practices add?

It adds attacks found since RFC 8725 came out in 2020. The draft-ietf-oauth-rfc8725bis was approved by the IESG on August 24, 2026 and waits in the RFC Editor queue. The new threats include:

• Case tricks: noNE getting past a blocklist that checks for none.
• Format confusion: a library verifies the JSON form of a JWS but reads claims by splitting the compact form. The fix is to reject any token with characters outside base64url and dots.
• JWE decompression bombs: a tiny compressed payload that expands to gigabytes. Cap the decompressed size.
• PBES2 cost attacks: a huge p2c iteration count. The draft recommends rejecting values above twice OWASP's 600,000.
• Injection and SSRF: through claims that the server uses in lookups or fetches.

22. Why did RFC 9864 deprecate the EdDSA algorithm name?

Because EdDSA does not say which curve to use; the key decides. RFC 9864 calls such names "polymorphic". It registers the fully specified names Ed25519 and Ed448, and marks EdDSA as deprecated.

A fully specified name lets a verifier pin the exact operation in its allowlist. That fits the rule of one algorithm per key. Older verifiers may only know EdDSA, so check library support before switching issuers.

23. What does RFC 9700 require of OAuth deployments that issue JWTs?

RFC 9700, the OAuth 2.0 Security Best Current Practice from January 2025, turns years of advice into rules. The main ones for JWT systems:

• Public clients must use PKCE, and authorization servers must support it.
• Clients should not use the implicit grant. The password grant must not be used.
• Refresh tokens for public clients must be sender-constrained or rotated.
• Access tokens should carry only the privileges the client needs, limited to certain APIs.

OAuth 2.1, which folds these rules into the core spec, is still an Internet-Draft. Candidates should cite RFC 9700 for the rules, not "the OAuth 2.1 spec".

24. What does RFC 10017 change for single-page apps?

It sets out three designs "in decreasing order of security" and prefers the one that keeps tokens off the browser. RFC 10017, published in August 2026, puts the backend for frontend first.

A token-mediating backend, which hands the access token to the browser, comes next. A browser-only client that runs OAuth in JavaScript comes last.

It also lists patterns it discourages, including the implicit grant and running OAuth inside a Service Worker. For an interview, the useful point is the threat model.

The RFC assumes the attacker can run code in the page, then asks what that attacker can steal. Only a design with no tokens in the browser leaves nothing to steal.

25. What is SD-JWT, and how does it hide claims?

SD-JWT lets the holder of a signed token show some claims and hide others, without breaking the issuer's signature. It is defined in RFC 9901 (November 2025).

The issuer signs only salted hashes of each hidden claim, listed in an _sd array. Each claim's salt, name and value travel beside the JWT as a "disclosure". The holder sends only the disclosures they want to reveal, joined by tildes:

<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~<KB-JWT>

The optional key binding JWT, typed kb+jwt, proves the presenter holds the key the token was issued to. SD-JWT is the base format for digital identity credentials, such as the SD-JWT VC draft.

Signs of a Strong Answer

• They pass the allowed algorithms, issuer and audience to the library explicitly, and can say what each default would let through.
• They explain RS256 to HS256 confusion in one breath and fix it by binding keys to algorithms, not by patching one check.
• They plan key rotation with overlap and cached JWKS, and know what happens on an unknown kid.
• They talk about revocation in terms of access token lifetime and refresh token rotation, with numbers they have used.
• They reach for a BFF for browser apps and can quote the XSS threat model behind it.
• They know OAuth 2.1 is still a draft and point to RFC 9700 for the current rules.

Hiring Engineers Who Know JWT

Token bugs are easy to write and hard to spot in review, so auth work needs engineers who have shipped it before.

Second Talent matches companies with pre-vetted API developers and back-end engineers from Asia, screened with questions like these.

Tell us the stack and we send a shortlist within 24 hours. Start hiring, or see our OAuth and API security interview guides.