Sessions vs Tokens: Two Ways to Stay Logged In

HTTP is stateless — each request arrives with no memory of the last. So how does a site remember you are logged in across many requests? There are two established answers, sessions and tokens, and they make a fundamental trade-off between server simplicity and scalability.

Session-based authentication

With sessions, the server does the remembering. When you log in, the server creates a session record — who you are, when you logged in — and gives your browser a session ID, usually in a cookie. On each request the browser sends the ID, and the server looks up the matching record. The client holds only an opaque key; all the real data lives server-side.

Token-based authentication

With tokens, typically JWTs, the client does the carrying. On login the server issues a signed token containing the user’s identity and claims, and the client sends it with each request. The server verifies the signature and trusts the contents without any lookup, because the signature proves the token has not been tampered with. The server stores nothing — it is stateless.

The core trade-off

• Scalability — tokens need no shared session store, so they scale across many servers trivially; sessions require a shared store or sticky routing.
• Revocation — sessions can be invalidated instantly by deleting the record; tokens are valid until they expire, making instant logout harder.
• Size — a session ID is tiny; a token carrying claims is larger and rides along with every request.
• Simplicity — sessions are conceptually simpler and the long-proven default for traditional web apps.

Which to choose

Sessions remain an excellent, secure default for traditional server-rendered web applications, especially with a single backend. Tokens shine for APIs consumed by many clients, mobile apps, and distributed systems where statelessness across services is valuable. Plenty of real systems blend the two, using short-lived tokens backed by server-side refresh state.