JWT (JSON Web Token)

A signed, self-contained token: three base64 chunks separated by dots, carrying claims about a user that anyone can verify without a lookup.

that long random string in the headerthe token my API checksjotthe token that carries the user info inside itthe eyJ tokenthree-part token with dotsJWT authsigned login token

See it

Live demo coming soon

What it is

A JWT is three base64url chunks joined by dots: header.payload.signature. The header names the algorithm, the payload holds claims (sub for the user, exp, iat, iss, aud, plus whatever you add), and the signature proves nobody edited the first two. Signed does not mean secret: paste any JWT into jwt.io and read it. The payoff is verification with no round trip, since anyone holding the public key or shared secret can check a token without asking your database anything.

Reach for JWTs when several services need to trust the same identity without sharing a session store, when an identity provider issues short access tokens on your behalf, or for machine-to-machine calls. OIDC ID tokens are JWTs, so if you use social login you already have one. If you are shipping one web app with one database, plain server-side sessions are simpler, smaller, and revocable, and 'JWT for auth' is often just cargo cult.

The big gotcha: you cannot un-issue a JWT. Until exp passes, a stolen one keeps working, so keep access tokens to minutes, pair them with refresh tokens, and keep a deny list for emergencies. Verify with the expected algorithm pinned (reject alg 'none' and the classic RS256-to-HS256 confusion attack where a public key is used as an HMAC secret), always check exp, iss, and aud, never put anything sensitive in the payload, and do not park tokens in localStorage where any injected script can read them.

Ask AI for it

Add JWT access tokens to this API. Sign with RS256 (or EdDSA) using a private key held only by the auth service, and publish the public key at a JWKS endpoint so other services verify without sharing secrets. Include sub, iss, aud, iat, exp, and a jti, and keep the access token lifetime to 15 minutes with a separate long-lived refresh token that rotates on use. On the verifying side, use a maintained library, pin the accepted algorithm explicitly, reject alg 'none', and validate exp, iss, and aud rather than only checking the signature. Cache JWKS keys with a TTL so key rotation works without a deploy. Store no personal data in the payload beyond a user ID and roles, deliver the token to browsers in an HttpOnly Secure cookie rather than localStorage, and add a revocation deny list keyed by jti that verification checks for tokens not yet expired.

You might have meant

bearer tokenaccess token vs refresh tokenrefresh tokensessionid token

Go deeper