How JWT Authentication Works — tokens without sessions
How JWT authentication works, shown on an interactive canvas: credentials, the three-part signed token, and how every request is verified statelessly.
A JSON Web Token is a signed, self-contained statement of who you are: the server creates it once at sign-in, and every later request proves itself with the token instead of a session lookup.
How JWT Authentication Works — tokens without sessions
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- Read left to right: Sign-in, Token issue, Authenticated requests.
- The user's row and the server's row alternate, so every arrow is either the user supplying something or the server deciding something.
- The two Reject shapes at the top of the sign-in and request columns are the failure endpoints — each decision on the canvas feeds one of them.
Proving who you are
"User submits email and password" and "Server verifies the credentials against the database" are the only place a password exists in the flow. "Credentials valid?" splits into the happy path and "Sign-in rejected". This is conventional authentication — the JWT part starts after the credential check succeeds.
Minting the token
"Server builds the header, payload and signature" is the heart of the visual. The header names the signing algorithm; the payload carries the claims — the user id, expiry, and any scopes; the signature binds them so the token cannot be altered without detection. "Server signs the token with its secret key" is the act that makes it trustworthy: only a server holding the secret can produce a valid signature. "Client receives the JWT and stores it" hands the artifact to the client, where it lives until expiry.
Stateless verification
"Client sends the JWT in the Authorization header" begins the repeated part of the flow, and "Server verifies the signature with its secret key" is why this scales: re-checking a signature is a computation, not a database lookup, so there is no central session store to consult. "Signature valid and not expired?" adds the time check, routing invalid or expired tokens to "Request rejected with 401" and valid ones to "Server trusts the claims and processes the request".
Key relationships and takeaways
- A JWT is three parts — header, payload, signature — joined by dots; the payload is readable but tamper-evident.
- The signature turns identity into a capability: possession of a valid, unexpired token is what authenticates the request.
- Verification is stateless — re-computing the signature replaces the session lookup.
- The token must be stored safely by the client and sent with every request, so its expiry is the real security boundary.
- JWTs and OAuth fit together: OAuth decides what the client may do, and JWT is one common format for the token that carries it.
When to use this visual
- Teaching a new backend team why no session table is needed and what the signature actually proves.
- Choosing between JWT and server-side sessions for a service where horizontal scaling makes shared state painful.
- Reviewing a token's claims — expiry, issuer, audience — before trusting it in a microservice.
How it works
List the claims your tokens actually carry
On the "header, payload and signature" step, add the real claims you issue — sub, exp, iss, aud, any scopes — so the diagram documents your token contract.
Add the refresh flow
Insert the refresh-token path after expiry: the client presents a long-lived refresh token, the server mints a new access token, and the session continues without a new sign-in.
Name your signing key strategy
Annotate the signing step with your key management — a single shared secret (HS256) or a public/private key pair (RS256) — since that choice decides who can verify the token.
Add the failure branches
Include expired, malformed and tampered tokens as explicit endpoints so the diagram covers the rejections your API actually returns.
Frequently asked questions
What is a JWT and what does it contain?
A JSON Web Token is a string of three dot-separated parts: a header stating the signing algorithm, a payload of claims about the user and the token's lifetime, and a signature. The header and payload are base64-encoded JSON — readable by anyone — and the signature is what prevents them from being changed without the signing key.
Why is JWT authentication called stateless?
Because the server stores nothing about the session. Each request arrives with the token, and the server verifies the signature and expiry on the spot. There is no session table to query and no state to replicate across servers, which is what makes the approach scale horizontally. The cost is that a token cannot be revoked before it expires without extra machinery.
Is a JWT secure if anyone can read the payload?
Reading and trusting are different things. The payload is not encrypted — do not put secrets in it — but the signature means any modification invalidates the token, so a client cannot change its own claims. For transport security the token travels inside HTTPS, and the data it grants access to is protected by the resource server enforcing the claims.
How do JWT and OAuth relate?
They solve different halves of the problem. OAuth is the authorization protocol — how a client obtains permission and a token. JWT is a token format. In practice OAuth access tokens are often JWTs: the authorization server signs a JWT carrying the scopes, and resource servers verify it. This canvas covers the authentication half; the OAuth visual covers the delegation half.
Edit this visual in QueryChart (FlowJam)
Open this exact JWT canvas as your own chart, rename the client and server to your services, and annotate your own claims.