JWT

Overview

A JSON Web Token (JWT) is a compact, signed token with three base64url parts: header (algorithm), payload (claims such as user ID, expiry, scopes), and signature. Any service with the signing key or public key can verify the token and trust its claims without calling a database or the issuer.

That statelessness is the main benefit and the main risk. JWTs scale well across microservices, but once issued they remain valid until they expire, so revocation requires short lifetimes, refresh tokens, or deny lists. JWTs are signed, not encrypted: anyone can read the payload, so never put secrets in it.

When to use it

• Access tokens verified by many services without a shared session store.
• OIDC ID tokens that convey user identity.
• Short-lived, signed claims between systems (signed URLs, email links).
• Stateless APIs where database lookups per request are too costly.

Where it shows up in interviews

Where it is used in real software

Key terms

Header

{ alg: RS256, typ: JWT, kid: key-id }.

Claims

sub (subject), iss (issuer), aud (audience), exp (expiry), iat (issued at), plus custom claims.

HS256 vs RS256

Shared-secret HMAC vs asymmetric RSA (or ES256) signatures.

JWKS

JSON Web Key Set: public keys published by the issuer.

Refresh token

Long-lived credential used to obtain new short-lived access tokens.

How it works, step by step

1. 1
   Issuer creates claims

   sub, iss, aud, exp (for example 15 minutes), scopes.

2. 2
   Issuer signs

   signature = sign(base64url(header) + '.' + base64url(payload), privateKey).

3. 3
   Client sends the token

   Authorization: Bearer <jwt>.

4. 4
   Service verifies

   Check the signature with the public key (by kid), then iss, aud, exp, and the allowed algorithm.

5. 5
   Refresh

   When the access token expires, exchange the refresh token for a new one; rotate the refresh token.

Sessions vs JWT access tokens

Both authenticate requests after login

A common hybrid: browser talks to a backend with a session cookie; the backend exchanges it for short-lived JWTs to call internal services.

Implementation

1import { SignJWT, jwtVerify, createRemoteJWKSet } from "jose";2 3// Issuer: sign a short-lived access token4async function issueAccessToken(userId: string, privateKey: CryptoKey) {5  return new SignJWT({ scope: "orders.read orders.write" })6    .setProtectedHeader({ alg: "ES256", kid: "2026-09" })7    .setSubject(userId)8    .setIssuer("https://auth.example.com")9    .setAudience("orders-api")10    .setIssuedAt()11    .setExpirationTime("15m")12    .sign(privateKey);13}14 15// Resource server: verify with the issuer's public keys (cached, rotated by kid)16const jwks = createRemoteJWKSet(new URL("https://auth.example.com/.well-known/jwks.json"));17 18async function authenticate(authorization?: string) {19  const token = authorization?.replace(/^Bearer /, "");20  if (!token) throw new HttpError(401, "Missing token");21  const { payload } = await jwtVerify(token, jwks, {22    issuer: "https://auth.example.com",23    audience: "orders-api",24    algorithms: ["ES256"], // never accept "none" or unexpected algorithms25  });26  return { userId: payload.sub!, scopes: String(payload.scope).split(" ") };27}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Storing JWTs in localStorage.

  Fix: Any XSS can steal them. Prefer HttpOnly Secure cookies for browsers, or keep tokens in memory.

• Long-lived access tokens.

  Fix: Keep them short and use refresh tokens.

• Not checking aud and iss.

  Fix: Otherwise a token issued for another service is accepted.

• Putting sensitive data in claims.

  Fix: Payloads are only base64 encoded; anyone can read them.

Interview questions

Practice problems