Ultimate Guide · 2026

JWT Security Guide: What a Token Inspector Reveals About Your Auth System

JSON Web Tokens power authentication for millions of APIs — yet most security incidents involving them are not exotic zero-days. They are the same handful of configuration mistakes: no expiration check, weak algorithms, secrets in the payload. This guide shows you exactly how to read a token, and exactly what to harden.

Written by Benjamin Rotshtein

Updated August 6, 2026

Download as PDF

The three parts of a JWT

A JWT is three dot-separated segments. Each segment is Base64Url-encoded, and only the third one is cryptographically meaningful:

header.payload.signature

Header — declares the signing algorithm (e.g. HS256) and token type. Payload — the claims: who the user is, when it was issued, when it expires. Signature — proves the first two segments were not modified by anyone without the key.

Here is a real example token, with the three segments colored to match the anatomy:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTUxNjIzOTAyMiwiZXhwIjoxNzk5OTk5OTk5fQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Paste this sample into the JWT decoder and watch each segment be decoded in real time.

Standard claims: what a decoded payload tells you

When you decode the payload, the security-relevant fields are the registered claims:

Any other field is a private claim — application-specific data. The rule is simple: treat everything in the payload as readable by the bearer, and verify the signature before trusting any of it.

How the signature works: HS256 vs RS256

The signature is what makes a JWT trustworthy. It is computed over the encoded header and payload using a signing algorithm:

• HS256 (symmetric) — the same secret signs and verifies. Simple and fast, but every service that verifies tokens must hold the secret, and anyone with it can forge tokens.
• RS256 (asymmetric) — a private key signs; a public key verifies. Your auth server keeps the private key, and downstream services verify with the public key only. This is the recommended choice for microservices and multi-service systems.

What a token inspector reveals about your auth system

Pasted into a decoder, a single production token exposes more than you might expect about your architecture:

• The alg field leaks your signing setup. If you see "alg":"none", verification can be bypassed. HS256 tells attackers a shared secret exists; RS256 means a public key is available.
• The exp claim reveals your session policy. No exp, or exp years in the future, means long-lived tokens with a huge theft window. Compare exp with iat: if a token was issued in 2016 and never expires, your validation code is missing a check.
• The payload reveals data hygiene. Tokens containing passwords, email addresses, roles or billing data are readable by anyone holding the token — a privacy leak waiting for a log dump or an XSS to expose it.
• The signature length hints at key strength. A short signature over an HS256 token often points to a weak, guessable secret (like "secret" or "password").

The JWT hardening checklist

• Always verify the signature. Reject any token whose signature does not validate with your key. Never trust the header's alg field blindly — whitelist exactly HS256 or RS256.
• Check exp on every request. Reject expired tokens. Require a short exp (minutes to hours), and use refresh-token rotation for long-lived sessions.
• Use RS256 when multiple services verify. Distribute only the public key; keep the private key on the issuing server.
• Keep secrets out of the payload. Store only non-sensitive identifiers. Sensitive data lives in your user-store, referenced by the sub claim.
• Serve over HTTPS only. A JWT is just a string — anyone who intercepts it can replay it. Transport security is not optional.
• Use strong secrets. For HS256, use a randomly generated secret of at least 256 bits. Weak secrets are crackable offline within minutes.
• Never paste production tokens into server-side tools. Decode locally, in your browser, so the token never leaves your machine.

Frequently asked questions