
Shivam Yadavyooo its me shivam hii i am a developer and todays topic of blog is what are these things...
hii i am a developer
and todays topic of blog is what are these things (session, cookie and jwt)
and without wasting time let move to actual topic
everything is happening because of this big word
so whenever the user login the user is given the access to the protected routes like:
/dashboard/settings/profileand as u know HTTP is stateless
then how will u maintain this state of user being login
like with each request if we ask user to login he might get irritated and will not use the website
and to avoid this thing
these things were born π
there are different use cases of session and cookie but i will be more focusing on authentication
first user login by putting credential
the server will create a session_id
now the session_id will be stored on the DB related to user
and after that the session_id is sent to user browser
now where the browser will store this session_id?
the designed answer would be:
and whenever the req/res happens between the server and user browser will send the cookie along with the HTTP request
and when that request is received the server will first take the session_id and check in the DB that whose session is this and that session is valid or not
and if everything is checked the access is provided
and done
this is the Auth happening in back 90's π
User Login
β
Server Creates Session ID
β
Session Stored In DB/Memory
β
Session ID Sent In Cookie
β
Browser Stores Cookie
β
Every Request Sends Cookie
β
Server Verifies Session
β
Access Granted
A cookie is a small piece of data that a server sends to the userβs web browser.
The browser may store it and send it back with subsequent requests to the same server.
now this definition would make sense after that long prolog π
Cookies are small pieces of data stored inside the browser.
Thatβs it.
Cookies are not authentication by themselves.
They are just storage.
Think of cookies like a small pocket inside the browser.
Server can put data into that pocket.
Browser automatically sends it back in future requests.
When server sends response:
Set-Cookie: userId=123
Browser stores it.
Now every future request automatically includes:
Cookie: userId=123
That is the basic idea.
Cookies can store:
Cookie is just a storage mechanism.
Not an authentication strategy.
this is very important π
many people think:
cookie == auth
NO
cookie is just storage
Session is a server-side authentication mechanism.
This means:
Data is stored on the server.
Not inside the browser.
When user logs in:
Example:
{
sessionId: "abc123",
userId: 45,
role: "admin"
}
Browser stores this session ID inside a cookie.
Now every request carries:
Cookie: sessionId=abc123
Server receives it and checks:
Which user belongs to this session?
Then server identifies the user.
Client -> Email + Password -> Server
Server checks database.
If correct:
Create Session
Example:
{
sessionId: "abc123",
userId: 45,
role: "admin"
}
Set-Cookie: sessionId=abc123
Cookie: sessionId=abc123
Server checks:
abc123 belongs to Shivam
User authenticated.
Login
|
v
Server Creates Session
|
v
Session Stored In Server Memory/DB
|
v
Session ID Sent In Cookie
|
v
Browser Stores Cookie
|
v
Every Request Sends Cookie Automatically
|
v
Server Verifies Session ID
now to understand this let see the flow
user put credential and then user click on login
server receive the login detail
server verify the user (exist in his own DB)
after that server create a JWT token
token is a piece of data which look like a random string but it is divided in three part
HEADER.PAYLOAD.SIGNATURE
first random string
second user related data like
{
userId: 45,
role: "admin"
}
then comes the secret key
after creating this the server send this token to the user
now the user takes this token and save this in his:
now with each request the browser will send this token to the server in his http header
Authorization: Bearer TOKEN
now with each req server get this token
server will put an middleware which will check the token is valid or not using the secret key we use to create this token
after this the user is given the access to the user
Login
|
v
Server Creates JWT
|
v
Token Sent To Browser
|
v
Browser Stores Token
|
v
Client Sends Token In Headers
|
v
Server Verifies JWT Signature
Stateful means:
Server stores user state.
Example:
Server remembers:
Session ID -> User Data
Every request requires checking stored session.
Stateless means:
Server does not remember user sessions.
Example:
All information is inside token itself.
Server just verifies token.
No session lookup needed.
| Session | JWT |
|---|---|
| Server stores user data | Client stores complete token |
| Client stores only session ID | Server usually stores nothing |
| Stateful | Stateless |
Because modern applications changed.
Earlier:
Frontend + Backend = Same Server
Traditional apps.
Like:
Sessions worked perfectly.
But modern systems became:
Frontend = React
Backend = Node.js API
Mobile App = Separate
Now multiple clients needed authentication.
JWT became easier because:
That is why JWT exploded in popularity.
Sessions are still extremely useful.
when making:
Why?
Because sessions are easier to revoke.
Example:
Delete session from server
User instantly logged out
Very controlled.
JWT works great when building:
Because:
No session storage required
Server scaling becomes easier.
Many beginners think:
JWT is always better
Not true.
JWT introduces complexity.
Especially:
Once token is issued:
Server may not fully control it until expiration.
That is why many large systems still use sessions.
centralized control matters.
scalability matters.
this line alone explain half of authentication architecture π
app.post("/login", (req, res) => {
const sessionId = "abc123";
sessions[sessionId] = {
userId: 1,
username: "shivam"
};
res.cookie("sessionId", sessionId);
res.send("Logged in");
});
app.get("/profile", (req, res) => {
const sessionId = req.cookies.sessionId;
const user = sessions[sessionId];
if (!user) {
return res.send("Unauthorized");
}
res.send(user);
});
const jwt = require("jsonwebtoken");
app.post("/login", (req, res) => {
const token = jwt.sign(
{
userId: 1,
username: "shivam"
},
"secretKey"
);
res.json({ token });
});
app.get("/profile", (req, res) => {
const token = req.headers.authorization.split(" ")[1];
try {
const decoded = jwt.verify(token, "secretKey");
res.send(decoded);
} catch {
res.send("Invalid token");
}
});
Not same.
Stored in browser
Stored on server
Cookie usually carries session ID.
Not same.
JWT is token.
Cookie is storage.
JWT can be stored inside cookies.
again π
cookie is just storage
| Thing | What It Actually Is |
|---|---|
| Cookie | Browser storage mechanism |
| Session | Server-side authentication state |
| JWT | Self-contained authentication token |
Learn sessions first.
Why?
Because sessions teach the actual foundation of authentication.
Once you understand:
Server remembers user identity
then JWT becomes much easier.
Most beginners directly jump into JWT tutorials.
Then they memorize code without understanding authentication flow.
Bad idea.
Understand the problem first.
Then understand sessions.
Then JWT.
That order builds real understanding.
Authentication is basically solving one problem:
How does server remember who the user is?
Sessions solve it by:
JWT solve it by:
Cookies help both by:
once u understand this
the entire authentication system starts making sense π
if u liked blog then follow me i always there with new blog like this
and also like the blog
meet u in the next blog
bye bye