How does token-based (JWT) authentication differ from server-side sessions?

Question

Accepted Answer

A session keeps the state on the server and gives the client only an opaque ID; a JWT puts the (signed) state inside the token itself, so the server trusts it by re-checking the signature and stores nothing — stateless vs stateful.

* Where the state lives is the whole difference: server store (session) versus inside the signed token (JWT). *

Dimension
Server-side session
Token (JWT)

Where state lives
On the server; client holds only a random ID
Inside the token the client holds

Server memory
Must store every active session
Stateless — nothing stored

Trust mechanism
Look up the ID in the session store
Re-verify the token's signature

Revoke / logout
Delete the session server-side — instant
Hard — a valid token works until it expires (needs short lifetimes or a blocklist)

Scale across servers
Needs shared or sticky session storage
Any server holding the key can validate it

The core trade-off: sessions are easy to revoke but need server-side storage; JWTs are stateless and scale easily but are hard to revoke. That one difference — statelessness — is why JWTs are popular for APIs and multi-service backends, and also why logout and token theft are harder to handle than with sessions.
Go deeper:

JSON Web Token (Wikipedia) — token structure and how stateless token auth compares with server-side sessions.

Dimension	Server-side session	Token (JWT)
Where state lives	On the server; client holds only a random ID	Inside the token the client holds
Server memory	Must store every active session	Stateless — nothing stored
Trust mechanism	Look up the ID in the session store	Re-verify the token's signature
Revoke / logout	Delete the session server-side — instant	Hard — a valid token works until it expires (needs short lifetimes or a blocklist)
Scale across servers	Needs shared or sticky session storage	Any server holding the key can validate it