What Is JWT and How Token Auth Works

1What Is a JWT?

A JSON Web Token (JWT) is a compact, self-contained token that securely carries claims about a user — such as their ID and role — in a digitally signed package. Because it is signed, a server can trust its contents without storing anything on its side or querying a database.

That self-contained quality is the whole point. Instead of the server keeping a record of who is logged in, it hands the client a signed token. The client sends it back on each request, and the server simply verifies the signature to know the token is genuine and unmodified.

2The Three Parts of a JWT

A JWT is three Base64Url-encoded sections joined by dots: header.payload.signature. Each part has a clear job.

• Header: names the token type and the signing algorithm, e.g. {"alg": "HS256", "typ": "JWT"}.
• Payload: the claims — data like {"sub": "user123", "role": "admin", "exp": 1735689600}.
• Signature: created by signing the header and payload with a secret or private key.
• The three parts are joined with dots: xxxxx.yyyyy.zzzzz.

3How the Signature Works

The signature is what turns readable JSON into a tamper-proof token. The server takes the encoded header and payload, runs them through a signing algorithm with a key, and appends the result. On every request it repeats the calculation and compares.

There are two families of algorithms. HMAC (like HS256) uses one shared secret for both signing and verifying — simple, but every verifier needs the secret. RSA and ECDSA (like RS256) use a private key to sign and a public key to verify, so services can validate tokens without holding the signing secret.

• signature = HMAC-SHA256(base64(header) + '.' + base64(payload), secret)
• Server recomputes the signature on each request and compares
• A mismatch means the token was altered — reject it
• RS256 signs with a private key, verifies with a public key

4How Token Authentication Works

Token authentication follows a simple loop: log in once, receive a token, then attach it to every subsequent request. The server never has to remember you between requests.

• 1. The user logs in with a username and password.
• 2. The server verifies the credentials and returns a signed JWT.
• 3. The client stores the token and sends it in the Authorization: Bearer <token> header.
• 4. The server verifies the signature and reads the claims to authorize the request.
• 5. No database session lookup is needed — the token carries everything.

5Sessions vs Tokens

Traditional session auth and JWT token auth solve the same problem differently, and each has trade-offs worth knowing before you choose.

• Sessions: the server stores state and hands the client an opaque ID. Easy to revoke instantly, but needs a shared session store.
• Tokens: the client holds signed state. Stateless and scalable, but hard to revoke before expiry.
• Sessions suit single-server or tightly-coupled apps; tokens suit APIs, mobile, and microservices.
• Many systems combine both: JWTs for access, a server-side list for refresh-token revocation.

6When to Use JWTs, and When Not To

JWTs shine in specific scenarios and are the wrong tool in others, so match them to the job. Their statelessness is a strength for distributed systems but a weakness when you need instant revocation.

Reach for JWTs when a request must be verified across many services without a shared session store, or for short-lived API access. Prefer traditional server sessions when you need to log users out instantly, manage long-lived logins from one server, or store large amounts of session state you would rather not ship to the client on every request.

• Good fit: stateless APIs, microservices, mobile app access tokens.
• Good fit: short-lived, single-purpose tokens like email verification links.
• Poor fit: cases needing instant logout or fine-grained session revocation.
• Poor fit: storing lots of mutable session data best kept server-side.

7Common Mistakes to Avoid

JWTs are safe only when used correctly. These slip-ups cause most real-world problems.

• Putting secrets in the payload: it is only encoded, not encrypted — anyone can read it.
• Long-lived access tokens: a leaked token is valid until expiry, so keep them short.
• Not verifying the algorithm: reject tokens whose 'alg' is 'none' or unexpectedly changed.
• Storing tokens in localStorage without XSS defences, exposing them to script injection.
• Skipping the exp claim, producing tokens that never expire.

8Key Takeaways

The essentials of JWTs and token authentication come down to a few points.

• A JWT is a signed, self-contained token of header.payload.signature that carries user claims.
• The signature proves integrity, but the payload is readable — never store secrets in it.
• Token auth is stateless: the server trusts the signature instead of a session store.
• Signed tokens are hard to revoke, so keep access tokens short and use refresh tokens.
• Verify the signature and algorithm, use HTTPS, and store tokens defensively against XSS and CSRF.

9Frequently Asked Questions

Q: Is a JWT encrypted? A: No, a standard JWT is only signed and Base64Url-encoded, not encrypted. Anyone who intercepts it can decode and read the payload. The signature prevents tampering, not reading. If you must hide the contents, use JWE (JSON Web Encryption).

Q: How do I log a user out with JWTs? A: Because JWTs are stateless, you cannot instantly invalidate one. Common approaches are keeping access tokens very short-lived, deleting the token client-side, and maintaining a server-side blocklist or revoking the refresh token.

Q: Where should I store a JWT in the browser? A: An HttpOnly, Secure cookie protects against JavaScript theft (XSS) but needs CSRF protection. localStorage is easy but exposed to XSS. Choose based on your threat model, and always serve over HTTPS.

Q: What is the difference between authentication and authorization in a JWT? A: Authentication is verifying the token is genuine (checking the signature). Authorization is reading its claims — like a role or permissions — to decide what the user may do. A single JWT supports both.