The first time I studied Sessions and JWTs, I just saw them as two different ways to authenticate users. You either use one or the other. Simple.
But recently, while learning Spring Boot, I realized I had misunderstood the whole thing. They’re not just two different tools for authentication — they’re two entirely different ideologies. And that’s what I want to talk about in this blog.
But before we get there, let’s address the fundamental concept: stateful vs stateless communication.
Stateful vs Stateless Communication
Stateful communication is when the server remembers you. It knows who you are. Of course not by your face, but by some kind of identifier. Once you log in, it can remember your role, permissions, and all that. So the next time you talk to the server, it already knows you.
Stateless communication is the opposite. Every time you send a request, you need to introduce yourself all over again. The server has no memory of your previous requests.
Given that introduction, we can now talk about those two methods.
How Sessions Work
Let’s say you walk into a restaurant and the waiter takes you to a table let’s say table number 21. You have your tasty meal and are now preparing to leave, when you come back at the counter and say that you want the bill for table number 21, they give it to you. You don’t tell them what all you ordered, they know that already. That’s basically a session.
When you log in using sessions, the server creates something called a session ID, which is just a randomly generated key. It then stores that key in a database or memory, along with your details like who you are, what access you have, etc.
Your browser gets a cookie with this session ID, and every time you send a request, the browser automatically includes that cookie. The server checks the session ID, fetches your information from memory or the database, and continues.
That’s what makes it stateful — the server keeps track of your session. It remembers you.
This works well when you’re dealing with one server. But things start getting tricky when you try to scale.
Why sessions don’t scale
Imagine there’s a gym in your locality. You buy a one-month membership.
Now, each day you walk in, the gym owner might recognize your face (if he has a good memory) or more realistically, check a register where your name is written. Once he finds your entry, you’re in.
That is how we were working with the sessions, the server remembered your identity
But now imagine you’re traveling and want to use a gym in another city, part of the same brand.
You walk in because you have your membership, you tell him your name and say “Naam to suna hoga” but the owner stares blankly. He doesn’t recognize you because he’s a different person. So what, he can just find your name in that register right? Not really, This owner won’t have the register that your locality gym was maintaining. This gym has no idea who you are.
This is where JWTs come in.
JWTs: Your ID Card
Let’s improve the gym system.
Instead of relying on a local register, what if the gym gives you a special ID card? Whenever you enter any branch, you show the card and they let you in.
But there’s a problem with this approach, what if someone makes a fake card at home?
So let’s say this ID card is signed using a special pen that only gym owners have. If someone tries to forge the card, the gym staff can tell immediately because the signature won’t match.
That’s what JWTs do.
A JWT (JSON Web Token) is a self-contained piece of information. It includes your identity and some other data, and it’s signed using a secret only the server knows. When the server receives the token, it doesn’t look you up in a database — it just checks if the token was signed with its secret and if it hasn’t expired or been tampered with.
This means the server doesn’t need to remember anything. You carry your identity with you in the form of a token.
And that’s why JWTs are stateless.
So What Are You Really Choosing?
When you pick between Sessions and JWTs, you’re not just picking between two tools. You’re picking between two mindsets:
- Do you want the server to remember each user and manage their sessions? (Stateful / Sessions)
- Or do you want each user to carry their own identity so the server doesn’t need to store anything? (Stateless / JWTs)
Each approach has its strengths and trade-offs. Sessions are simple and secure in smaller, single-server apps. JWTs shine when you need to scale horizontally, or when clients need to communicate with multiple services.
But now, at least, you know the real difference isn’t just in how you authenticate. It’s in how your system thinks.
Before this session expires…
Thank you for reading! I really hope you found something useful or interesting in here. If you’ve got a question, a thought to share, or just feel like saying hi, you can find me on Twitter or LinkedIn.
Top comments (1)
Great share
Really cleared the concept
Also since i am particularly new to web dev
How and from where would you do it if you did it once again.
Would be great if you could share