Home / Knowledge hub / Stateless session
Knowledge hub
Stateless session
A session kept entirely in a signed token, with nothing stored on the server.
What it means
A stateless session keeps everything about a signed-in visit inside a token that the client holds, usually a signed JWT. The server stores no session record. On each request it checks the signature and expiry, and trusts the claims inside.
The alternative is a server-side session, where the browser holds a random reference and the server looks up the details. In the stateless design nothing needs to be looked up, so any server can handle any request without sharing a store.
Why it matters
The appeal is simple scaling: no shared session database, no lookup, easy use across services. The price is control. With nothing on the server to delete, a token stays valid until it expires, whether the user logged out, was fired, or had their role removed.
That makes stolen tokens harder to stop, and role changes slow to bite. The signing key becomes critical too: anyone who obtains it can mint a valid session for any account. These trade-offs are acceptable when understood, and expensive when discovered after an incident.
How it shows up
Keep tokens short-lived, minutes rather than days, and use a refresh token that can be revoked on the server. Keep a small deny list for emergencies, rotate signing keys, and check the algorithm, issuer, audience and expiry on every request. The JWT best-practice document, RFC 8725, covers these checks.
The mistakes: a stateless token that lasts for weeks, logout that only deletes the browser copy, sensitive data in the payload which is readable by anyone, trusting claims after a role change, and verification code that accepts unsigned tokens. Test logout and role removal by replaying the old token.
Questions people ask
Stateless session, answered
Are stateless sessions less secure?
Not inherently, but they are harder to revoke. A server-side session can be deleted instantly; a signed token cannot, so you rely on short expiry and a deny list.
Which is better depends on how fast you must cut access.
How do you log out of a stateless session?
The client discards the token, which only ends it for that client. A copy elsewhere still works until it expires. For real logout, keep a server-side deny list or use short tokens with revocable refresh tokens.
Test it by replaying the old token.
Is a JWT always a stateless session?
No. A JWT is a format. It can be used as a stateless session token, or merely as an identifier that the server also looks up. Stateless means the server does not store or consult anything about it.
The behaviour defines the design, not the format.
Can the contents of a stateless token be read?
Yes, usually. A signed JWT is encoded, not encrypted, so anyone holding it can read its claims. The signature stops edits, not reading.
Do not put secrets or personal data in it unless it is encrypted too.
When is stateless a good choice?
When many services need to trust the same identity, tokens are short-lived, and you can accept limited ability to revoke within that window. For high-risk sessions that need instant revocation, server-side sessions are simpler.
See opaque tokens.
Related
Terms that sit next to this one
JWT
A signed token a client carries to prove who is signed in.
Opaque token
A token with no readable content, looked up on the server to find who it is for.
Token revocation
Cancelling a token before it expires, for example after a password change.
JWT expiry
The time claim that stops a signed token from being accepted forever.
Logout invalidation
Making sure signing out really kills the session on the server, not just in the browser.
Does logout really log anyone out?
We replay tokens after logout, after a role change and past their expiry, and report which ones the server still accepted, with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.