How JWT tokens work: the three-part string behind most logins
JWTs power stateless auth across web apps, APIs and single sign-on. They are compact, self-contained and cryptographically signed, so the server stores nothing. But that same design is exactly what attackers target when tokens are misused or leaked.
A JSON Web Token — usually just called a JWT and pronounced “jot” — is an open standard (RFC 7519) for passing a compact, self-contained bit of information between two parties in a way that a receiver can trust. It shows up everywhere: when you log in to a web app, when one microservice calls another, and often as the access token inside single sign-on. The short version is that a JWT is encoded, not encrypted, and it is header.payload.signature.
The three parts, in order
- Header — declares the token type (
typ: JWT) and the signing algorithm (for exampleHS256orRS256). Base64URL-encoded. - Payload — carries the
claims: who the token is about (often asubidentifier), who issued it (iss), when it expires (exp) and anything else the issuer wants to attach. - Signature — a cryptographic proof over the header and payload. If any character above it changes, verification fails, so the receiver knows the content was not tampered with.
Every part is encoded with Base64URL for safe transport, not for secrecy — decode the middle section and it is plain JSON. That is the part people misread most often: a JWT is a signed ticket, not a locked box. Nothing stops a client from reading what it carries; what it cannot do is alter it without breaking the signature.
Because the token itself carries the user's identity and permissions, the server can stay stateless. There is no database row to look up on every request — just a fast signature check. That is a win for scale and for mobile, where a phone can be offline or flaky and a session store would be painful. The flip side: the token is the bearer's identity, whichever device holds it can act as that user, and if it leaks, the blast radius is real.
The signature is what makes it trustworthy, and the algorithm choice decides how. With HS256 (HMAC) the issuer and verifier share one secret key — simple, but the secret must stay secret. With RS256 (RSA) or ECDSA the issuer signs with a private key and everyone else verifies with a public key, which is how one identity provider can issue tokens that many independent services accept. Get the algorithm wrong — for example trusting a key that matches an HS256 token as if it were an RSA public key — and the verification becomes trivially bypassable.
What breaks when done wrong
Storing a long-lived JWT in an accessible localStorage or a log; trusting a payload field as a role or admin flag without re-checking it server-side; missing or mis-parsing exp so tokens never actually expire; and accepting any kid or alg a client offers. None of these require a new vulnerability to exploit — they are misconfigurations of a token that is, by design, fully readable.
If you use JWTs: keep them short-lived, sign with a proper algorithm, treat every claim as untrusted input, and give your token a way out (revocation or a short exp) because once it is signed it is valid until it is not. If you're on the receiving end of a login that hands you a token, understand that the token is your session — protect it the way you protect a password: over encrypted connections, out of logs, and out of anyone else's reach.
Read the raw token in a client and you can see the iss, sub and exp claims on your own. That visibility is what makes JWTs so easy to reason about — and it is also why the security contract is carried almost entirely by the signature and the claims you choose to check.
Sources: jwt.io — Introduction to JSON Web Tokens; RFC 7519: JSON Web Token (IETF); Auth0 — What is a JWT?.
Corrections: Report an error at corrections@wireshaman.com.