JWT simulator

There are three parties: a client (a browser or app), an authorization server that checks passwords and issues tokens, and an API that accepts requests carrying an access token. Press Log in and the server signs an access token with HMAC-SHA256 using the Web Crypto API in your browser; the left panel shows it, split into its three parts and decoded. Every API call verifies the signature and the claims for real. Time is simulated, so you can jump ahead instead of waiting fifteen minutes.

• Log in, call the API, then add 15 minutes and call again: 401, expired. Press Refresh to get a new pair of tokens, and the call works.
• Press Change role to admin: the payload is edited and the old signature copied across. The API rejects it, because the signature no longer matches.
• Press alg: none: the forged token claims to need no signature. The API refuses any algorithm but the one it expects.
• Refresh once, then press Replay an old refresh token, as an attacker who copied it would. The server sees a used token come back, revokes the whole session, and the real client's next refresh fails too.
• Log out, then call the API: it still works until the access token expires. That is the revocation problem.

The tokens are genuine: one copied from the left panel decodes and verifies with any JWT library given the server's demo secret, semicolony-demo-secret-change-me. Nothing is sent over the network.

A JSON Web Token (JWT) is a compact string that carries a set of claims, such as a user's ID, their role and an expiry time, together with a signature that proves who issued them and that they have not been altered. It is designed to be passed around in HTTP headers and URLs, most often as Authorization: Bearer <token>.

The point of a JWT is that it is self-contained. A server that receives one checks the signature with a key it already has and reads the claims directly. It does not need to look up a session in a database, which is why JWTs are popular for APIs, for systems with many services, and in OAuth 2.0 and OpenID Connect, where an ID token is always a JWT.

Here is the example token from jwt.io, signed with HS256 and the secret your-256-bit-secret. It was signed again when this page was built, and the result matched jwt.io's published token.

The payload is a JSON object of claims. RFC 7519 registers seven short names; all are optional, but most access tokens use several. Applications add their own, such as role or scope.

The alg header names the signature algorithm, from the list in RFC 7518. The choice decides who can create tokens and who can only check them.

Decoding a JWT is not validating it. An API that accepts a token should, in this order:

1. Check that it has three parts and that the header and payload are valid JSON.
2. Check the algorithm against a fixed allowlist chosen by the API. Never let the token's header decide.
3. Verify the signature with the expected key.
4. Check exp (and nbf if present) against the current time, allowing at most a minute or so of clock skew.
5. Check iss and aud, so a token from another issuer, or one meant for another service, is refused.
6. Then apply the application's own rules, such as the user's role or scopes.

RFC 8725, "JSON Web Token Best Current Practices", lists these checks and the attacks they prevent. Use a maintained library and configure it with the expected algorithm, issuer and audience, rather than writing verification by hand.

Because an API accepts a valid JWT without asking anyone, a stolen access token works until it expires. So access tokens are kept short-lived, typically 5 to 60 minutes. To avoid making users log in again that often, the authorization server also issues a refresh token: a long-lived credential that the client sends only to the authorization server, to get a new access token.

Refresh tokens are usually opaque random strings that the server stores, as in the simulator, so that it can check and revoke them; the API never sees them. With rotation, each refresh returns a new refresh token and marks the old one as used. If a used one comes back, either the client is confused or someone copied it, and the safe response is to revoke every token from that login. RFC 9700 (2025), the OAuth 2.0 security best current practice, recommends rotation, or tokens bound to the client's key, for public clients such as browser and mobile apps.

Logging out with JWTs is harder than it looks. The server can revoke the refresh token at once, but the access token is a signed string in the client's hands, and every API will keep accepting it until exp. The options:

• Short access tokens. The simplest approach: accept that access lasts a few more minutes after logout.
• A denylist. Record the jti of revoked tokens until they expire, and have APIs check it. This brings back a lookup on every request, though a small, fast one.
• Token introspection. APIs ask the authorization server about each token (RFC 7662), which works best with opaque tokens.
• Key rotation. Changing the signing key invalidates every token signed with the old one, for all users at once.

A token in localStorage or a JavaScript variable can be read by any script on the page, so one cross-site scripting (XSS) bug lets an attacker take it. A token in a cookie marked HttpOnly cannot be read by scripts, Secure keeps it off unencrypted connections, and SameSite=Lax or Strict limits when it is sent from other sites, though state-changing requests still need protection against cross-site request forgery (CSRF). A common pattern for single-page apps is a backend-for-frontend: a small server that holds the tokens and gives the browser only a session cookie.

• alg: none. The specifications allow an "unsecured JWT" with no signature. In 2015, Tim McLean showed that several libraries would accept one when the token said so, letting anyone forge any claims. The simulator's API refuses it, as every verifier should.
• Algorithm confusion. If a server expects RS256 but lets the header choose, an attacker can sign a token with HS256 using the server's public key as the HMAC secret, and a naive library will verify it with that same public key. Pinning the algorithm per key prevents it.
• Weak HMAC secrets. An HS256 token can be attacked offline: guess the secret, recompute the signature, compare. Short or dictionary-word secrets fall quickly.
• Trusting the payload without verifying. Decoding is not verifying. Code that reads claims from an unverified token trusts anyone.
• Header-controlled key lookup. The kid, jku and x5u headers point to keys; a server that fetches keys from URLs in the token, or uses kid unsafely in a file path or query, can be tricked into using an attacker's key.
• Secrets in the payload. The payload is readable by anyone who sees the token, including browser extensions and logs.

Typical questions: what the three parts are and whether the payload is secret (it is not); how an API verifies a token without a database; HS256 versus RS256 and when each fits; why access tokens are short and how refresh tokens work; how you would log a user out everywhere; JWT versus sessions; and where to store tokens in a browser. In system design questions, mention that the API gateway or each service validates tokens locally using the issuer's public keys, cached from its JWKS endpoint.