How does a JSON Web Token (JWT) work?

Question

IT Interview Practice · Accepted Answer

A **JSON Web Token (JWT)** is a compact, URL-safe, self-contained token that carries claims about a user. The server signs it once; afterwards it can **verify** the token on every request without a database lookup — that is what makes JWT-based auth *stateless*.

## Structure: three base64url parts

A JWT is `header.payload.signature`, three base64url-encoded segments joined by dots:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header
.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDB9      ← payload (claims)
.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1    ← signature
```

- **Header** — the signing algorithm, e.g. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — the **claims**: standard ones like `sub` (subject/user id), `exp` (expiry), `iat` (issued-at), `iss` (issuer), plus any custom fields (`role`, `email`).
- **Signature** — computed over the header and payload with a secret or private key.

> The payload is **encoded, not encrypted**. Anyone can base64-decode and read it, so never put passwords or secrets in a JWT.

## How signing and verification work

```
signature = HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)
```

- **HS256** (symmetric): the same secret signs and verifies. Simple, but every verifier must hold the secret.
- **RS256** (asymmetric): a **private key** signs, a **public key** verifies. The auth server keeps the private key; other services verify with the public key and can never mint tokens.

On each request the server recomputes the signature over the received header+payload and compares it. If they match and `exp` is in the future, the token is trusted — no session store needed.

```js
const jwt = require("jsonwebtoken");

const token = jwt.sign({ sub: "123", role: "admin" }, SECRET, {
  expiresIn: "15m",
});

try {
  const claims = jwt.verify(token, SECRET); // throws if tampered or expired
  // claims.sub === "123"
} catch (e) {
  // reject: invalid or expired
}
```

## The hard part: revocation

Because verification is stateless, you **cannot** invalidate a token before it expires just by "deleting" it server-side. Common mitigations:

- Keep access tokens **short-lived** (5–15 min) and pair them with a longer-lived **refresh token**.
- Maintain a small **denylist** of revoked token ids (`jti`) for logout/compromise — this reintroduces a little state.
- Rotate signing keys.

## Storage trade-offs

| Storage | Pro | Con |
|---|---|---|
| `httpOnly` cookie | Not readable by JS (XSS-safer) | Needs CSRF protection |
| `localStorage` | Simple, no CSRF | Exposed to XSS |

## Why it matters

JWTs power stateless authentication across APIs, microservices, and SPAs — a service can trust a request by verifying a signature alone, with no shared session store. But that same statelessness is the classic interview trap: tokens can't be easily revoked, the payload is readable, and `alg` confusion or a missing expiry check are real vulnerabilities. Knowing exactly what the signature protects, and what it doesn't, is essential to using JWTs safely.

Storage	Pro	Con
`httpOnly` cookie	Not readable by JS (XSS-safer)	Needs CSRF protection
`localStorage`	Simple, no CSRF	Exposed to XSS

Structure: three base64url parts

How signing and verification work

The hard part: revocation

Storage trade-offs

Why it matters

Related questions