How JWT Authentication Works

JSON Web Tokens are the most common way to do stateless authentication: the server hands out a signed token at login and verifies it on later requests without storing session state. Here's how that works, and where it goes wrong.

This is a supporting guide in Web Security Essentials.

The three parts of a JWT

A JWT is three Base64url-encoded parts joined by dots — header.payload.signature:

Header — the token type and signing algorithm (e.g. HS256)
Payload — the claims: who the user is (sub), when it was issued (iat), when it expires (exp), plus any custom data
Signature — the header and payload signed with a secret or private key

The header and payload are only encoded, not encrypted — anyone with the token can read them. See How to Decode a JWT to inspect one.

The authentication flow

The user logs in with credentials.
The server verifies them and returns a signed JWT.
The client stores it and sends it on later requests (typically Authorization: Bearer <token>).
The server verifies the signature and expiry on each request and trusts the claims inside — no database lookup for the session needed.

That "no lookup" property is the appeal: any server holding the signing key can verify the token, which scales well across services.

Why the signature matters

The signature is the whole security model. Because it's computed from the header, payload, and a secret the server holds, a client can't change a claim (say, flipping admin to true) without invalidating the signature. The server recomputes the signature and rejects any token that doesn't match. A token whose signature you don't verify is worthless — always verify.

Common pitfalls

Secrets in the payload. It's readable — never put anything sensitive there.
Not verifying, or accepting alg: none. Reject unsigned tokens and pin the expected algorithm.
No expiry, or very long ones. Use short exp values; you can't easily revoke a stateless token before it expires.
Storing tokens carelessly. Protect against XSS/CSRF depending on where you keep them, and only ever send them over HTTPS.

Part of Web Security Essentials. See also How to Decode a JWT and How to Store Passwords Securely.

Try it

Paste a token into the JWT Decoder to inspect its header, claims, and expiry — it's read entirely in your browser, never uploaded.