JWTs (JSON Web Tokens).
A festival wristband: checked at a glance, with no call back to the box office.
When you pay at a festival gate you do not get a receipt to show a cashier each time. You get a wristband. Every ride and bar just glances at it and waves you through — no phone call back to the ticket office.
A JWT is that wristband for the web. You log in once, the server hands you a signed token, and you show it with each request. The server can trust it on sight, so it does not need to look you up in a session store every time.
- One check-in, please.1
You sign in once. In return you get a signed token — your wristband for the visit.
- 2
The token has three parts: who you are, some claims, and a signature.
- Wristband? In you go.3
Each later request just shows the token. The server trusts it on sight — no lookup.
- 4
The signature makes it tamper-evident: change one letter and it stops matching.
- 5
Anyone can read what is on it — so never put secrets in a token.
- Expires at midnight.6
It cannot easily be cancelled mid-visit, so tokens are kept short-lived.
Why “stateless” is the whole point
A classic session keeps your details on the server and hands you a meaningless ID; every request makes the server look that ID up. A JWT carries the details with it, signed, so any server with the key can verify it without shared storage. That makes it easy to scale across many servers — but it also means the server is not tracking each token.
The revocation catch
Because no one is looking the token up, you cannot simply delete it to log someone out. Until it expires, it stays valid. Real systems work around this with short lifetimes plus a separate refresh token, or a small block-list for the rare “revoke now” case — which quietly brings back a bit of the state JWTs were meant to avoid.