In this article
How this list is ordered
The questions run from what a token is to what goes wrong in production. Read them in order if you are new, or jump to a group. The wider topic sits in the cyber security interview questions guide, and the web-attack side is covered in application security interview questions. Every entry gives a short answer, one line on why it is asked, and where to read more.
The basics
What is a JSON Web Token (JWT)?
A JSON Web Token is a compact, uniform resource locator (URL)-safe way to represent claims between two parties, defined in the Request for Comments (RFC) series (RFC 7519, May 2015). A claim is a statement about a subject, such as a user id. The claims form a JavaScript Object Notation (JSON) object used as the payload of a signed structure or the plaintext of an encrypted one. An application programming interface (API) usually receives one with each request.
Why it is asked: it checks that you can define the term before using it. Read the full explanation: RFC 7519.
What are the three parts of a JWT?
A signed JWT has three parts joined by periods: header, payload and signature. Each part holds a base64url-encoded value (RFC 7519, May 2015); base64url is an encoding that writes bytes as letters, digits, hyphen and underscore so they survive in a URL. The header names the algorithm, the payload holds the claims, and the signature covers the header and payload. The example token is 227 characters: 36 for the header, 146 for the payload and 43 for the signature.1
Text description of the diagram
- A signed JWT has three parts joined by periods: header, payload and signature.
- The signature covers the header and payload.
Why it is asked: it shows whether you have seen a real token. Read the full explanation: jwt.io introduction.
Is a JWT encrypted?
A standard signed JWT is encoded and signed, not encrypted, so anyone holding it can read the payload. Decoding the example payload needed no secret and showed the subject user-123.1 The signature protects integrity, meaning changes are detected, not secrecy. The standard allows claims to be signed, integrity protected or encrypted (RFC 7519, May 2015); confidentiality needs the encrypted form.
Why it is asked: "JWT is encrypted" is the most common wrong belief. Read the full explanation: RFC 7519.
What is the difference between JWS and JWE?
A JSON Web Signature (JWS) carries claims that are digitally signed or protected with a message authentication code. A JSON Web Encryption (JWE) carries claims as encrypted plaintext. A JWT is a JWS or a JWE, and a token may be nested inside another so that it is both signed and encrypted (RFC 7519, May 2015). Most tokens met in interviews are the signed kind.
Why it is asked: it tests whether you separate signing from encryption. Read the full explanation: RFC 7519.
Is JWT the same as OAuth?
No. OAuth 2.0 is an authorization framework in which a client obtains an access token from an authorization server to call an API (RFC 6749, October 2012). A JWT is only a token format. OAuth does not require access tokens to be JWTs, and JWTs are used without OAuth, so the comparison is a format against a framework.
Why it is asked: it tests whether you separate a token format from a protocol. Read the full explanation: RFC 6749.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Signing and algorithms
What is the difference between HS256 and RS256?
The hash-based message authentication code (HMAC) algorithm with a Secure Hash Algorithm (SHA) of 256 bits (HS256) lets one shared secret both sign and verify. The Rivest–Shamir–Adleman (RSA) signature algorithm with the same hash (RS256) lets a private key sign and a public key verify. Both are defined in RFC 7518, section 3.1, May 2015. Choose the RSA kind when the services that verify tokens should not be able to mint them. An HMAC secret should be a random key, not a memorable password (RFC 8725, February 2020).
Why it is asked: it tests key management thinking, not only names. Read the full explanation: RFC 7518.
What is the "alg none" attack?
An attacker edits the header so the algorithm reads "none", and some libraries then trust that value and accept the token without checking any signature (RFC 8725, February 2020). The forged shape keeps three parts with an empty third one: in the example its signature part had 0 characters.1 The defence is for the verifier, not the token, to decide which algorithms are acceptable.
Why it is asked: it is the classic JWT flaw and tests whether you distrust the header. Read the full explanation: RFC 8725.
What is an algorithm confusion attack?
In algorithm confusion an attacker changes the header from an RSA algorithm such as RS256 to an HMAC one such as HS256 (RFC 8725, February 2020). If the verifier lets the header choose, it may treat the public RSA key as an HMAC secret, and anyone knows a public key. Binding each key to exactly one algorithm closes the gap.
Why it is asked: it separates people who memorised "alg none" from those who understand key and algorithm binding. Read the full explanation: RFC 8725.
How should a server verify a JWT signature safely?
Fix the accepted algorithms in server configuration and never read them from the token. RFC 8725 says libraries must let the caller specify a supported set of algorithms and must not use any other, and that each key must be used with exactly one algorithm, checked at verification time (RFC 8725, February 2020). Verify the signature first, then check the claims.
Why it is asked: it turns the attacks into a concrete rule. Read the full explanation: RFC 8725.
How does a verifier use the kid header and a JWKS?
The kid header parameter names which key signed the token, so the verifier can pick the matching public key from the issuer's JSON Web Key Set (JWKS), a published set of public keys. Treat kid as untrusted input: look it up only among keys you already trust, keep each bound to one algorithm, and never build a file path or database query from it (RFC 8725, February 2020).
Why it is asked: it tests key rotation and input distrust together. Read the full explanation: RFC 8725.
Claims and validation
What are the registered claims in a JWT?
RFC 7519 registers seven short names: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at) and jti (JWT identifier). The example token carries iss, sub, aud, iat and exp.1 You may add private claims of your own, but keep them small because the token travels with every request.
Why it is asked: it checks that you can read a payload and know what each field is for. Read the full explanation: RFC 7519.
What does the exp claim do, and is it mandatory?
The exp claim gives the time on or after which the token must not be accepted. The standard allows a small leeway, usually no more than a few minutes, for clock differences between machines, and it makes the claim optional (RFC 7519, section 4.1.4, May 2015). So your verifier should require it. The example lifespan of 900 seconds, 15 minutes, is our choice, not a standard.1
Why it is asked: optional expiry is a trap for people who assume it is always there. Read the full explanation: RFC 7519.
Which claims must a server check besides the signature?
A valid signature only shows who made the token. Also check the issuer, the audience and the expiry. RFC 8725 has sections on validating the issuer and subject and on using and validating the audience, so a token minted for one service is not accepted by another (RFC 8725, February 2020). Reject tokens that fail any check.
Why it is asked: "signature valid means trusted" is a frequent mistake. Read the full explanation: RFC 8725.
What should and should not go in a JWT payload?
Put the minimum: a subject identifier, the issuer, the audience, times and perhaps a role. Leave out passwords, secrets and personal data, because a signed token is readable by whoever holds it. Changing one claim breaks the signature: in the example, editing the subject produced a different signature, so a tampered token fails verification.1
Why it is asked: it tests whether you apply the encoded-not-encrypted fact to a design. Read the full explanation: RFC 7519.
Sessions, revocation and storage
What is the difference between a JWT and a session cookie?
A session cookie usually holds an opaque identifier and the server looks up the state. A JWT is self-contained: the server checks the signature and reads the claims without a lookup. A JWT is a token format, while a session is a state choice, so the real trade-off is lookup cost against easy revocation.
Why it is asked: it checks that you compare designs, not buzzwords. Read the full explanation: cyber security interview questions guide.
How do you revoke a JWT?
A stateless JWT has no built-in revocation before exp: a stolen example token stays usable for up to 900 seconds, 15 minutes.1 Options are short lifespans or a denylist. A denylist is a server-side list of revoked token ids (the jti claim). A denylist entry only needs to live until the token's exp. Each option adds state.
Why it is asked: it exposes the cost of statelessness. Read the full explanation: RFC 7519, section 4.1.4.
Where should a browser store a JWT?
There is a trade-off, and practice differs. A token in storage that page script can read can be stolen by cross-site scripting (XSS), described in OWASP on cross-site scripting. A cookie marked HttpOnly and Secure keeps it out of reach of script, but then you must consider cross-site request forgery (CSRF), described in OWASP on cross-site request forgery, for example with the SameSite attribute. State the risk of each, then pick.
Why it is asked: no answer is perfect, so it tests reasoning. Read the full explanation: OWASP on XSS.
What are access tokens and refresh tokens?
A common design issues a short-lived access token that the API accepts, plus a longer-lived refresh token that the client sends only to the authorization server to get new access tokens (RFC 6749, section 1.5, October 2012). The server records each refresh token so it can revoke it, and can rotate it on every use (RFC 9700, section 4.14, January 2025). A stolen access token then works only until its short exp.
Why it is asked: it ties lifespan, revocation and storage into one design. Read the full explanation: RFC 6749, section 1.5.
Follow-up questions
What JWT questions are asked for experienced developers?
Experienced-level questions usually go past definitions into failure modes: algorithm confusion, audience checks, revocation cost and storage trade-offs. Prepare to explain a design choice, such as short lifespans with refresh tokens against a denylist. Who may do what once identity is proven is the daily work of an identity and access management analyst. The wider security round is covered in the security interview guide and in its learning path.
How do you decode a JWT?
Split the token on the periods, then base64url-decode the first two parts to read the header and payload as JSON. No secret is needed, which is why decoding proves nothing; only signature verification does. Tools such as the jwt.io debugger decode example tokens.
Is a JWT the same as an access token?
No. A JWT is a format; an access token is a role. Some systems issue access tokens as JWTs, others as opaque strings the API must look up.
What do you do when a JWT is stolen?
Revoke it through your denylist, rotate the signing key if the key may be exposed, shorten lifespans, and look for use from unexpected places. Detection and response of this kind is the work described in Security Operations Center (SOC) analyst interview questions, and attacker tactics are covered in threat intelligence interview questions.
- A signed JWT is header, payload and signature, base64url-encoded and joined by periods; it is readable, not secret.
- The verifier fixes the allowed algorithms and binds each key to one; it never trusts the header.
- A valid signature is not enough: check issuer, audience and expiry, and require
exp. - Revoking a stateless token needs state: a denylist, or short lifespans to limit the gap.
- Storage in a browser is a trade-off between script theft and cookie request forgery.
Sources
- RFC 7519: JSON Web Token (JWT) — IETF / RFC Editor, 1 May 2015
- RFC 8725: JSON Web Token Best Current Practices (BCP 225) — IETF / RFC Editor (Sheffer, Hardt, Jones), 1 Feb 2020
- JSON Web Tokens introduction and debugger (jwt.io) — Auth0 (Okta), 26 Oct 2026
- RFC 7518: JSON Web Algorithms (JWA) — IETF / RFC Editor, 1 May 2015
- RFC 6749: The OAuth 2.0 Authorization Framework — IETF / RFC Editor, 1 Oct 2012
- RFC 9700: Best Current Practice for OAuth 2.0 Security — IETF / RFC Editor, 1 Jan 2025
- Cross Site Scripting (XSS) — OWASP Foundation, 26 Oct 2026
- Cross Site Request Forgery (CSRF) — OWASP Foundation, 26 Oct 2026
