Hello readers đź‘‹, welcome to the 15th blog in our Node.js series!
In our previous posts, we built a REST API, learned how to protect routes with JWT, and explored middleware and file uploads. Authentication has come up several times, but today we’re going to take a step back and look at the bigger picture. We’ll compare three pillars of authentication in web applications: sessions, JSON Web Tokens (JWT), and cookies.
If you’ve ever been confused about when to use a session-based login, when to reach for a JWT, or where cookies fit into all this, this post will clear things up. We’ll keep it practical, avoid deep security rabbit holes, and end with a decision framework you can apply to your next project.
Let’s get started.
What are cookies?
Cookies are small pieces of data stored on the client (browser) by the server via the Set-Cookie header. They are automatically sent back to the server with every subsequent request to the same domain. That’s their superpower: they travel with every request without the client having to do anything extra.
A cookie looks something like this:
Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict
The browser then dutifully sends Cookie: sessionId=abc123 with each request.
Cookies alone are not an authentication method; they are a transport mechanism. They can carry a session ID, a JWT, or just a simple preference. But because sessions almost always rely on cookies, the two are often mentioned together.
Key properties you can set on cookies:
-
HttpOnly – the cookie cannot be accessed via JavaScript (
document.cookie), which helps prevent XSS attacks. - Secure – the cookie is only sent over HTTPS.
- SameSite – controls whether the cookie is sent on cross‑site requests, mitigating CSRF.
In a traditional session‑based authentication, the server sets a cookie containing a unique session ID, and all further requests carry that cookie to identify the user.
What are sessions?
Session‑based authentication is the classic approach. After the user logs in with valid credentials, the server creates a session – a record in a database, in‑memory store, or cache (like Redis) that contains the user’s identity and any other relevant data. The server then sends back a cookie holding only the session ID.
Every subsequent request comes with that cookie. The server reads the session ID, looks up the session data (often from a store), and knows who the user is without them sending the password again.
Let’s see a simplified Express example using express-session:
const session = require('express-session');
app.use(session({
secret: 'your-secret-key',
resave: false,
saveUninitialized: true,
cookie: { secure: true, httpOnly: true, maxAge: 3600000 } // 1 hour
}));
app.post('/login', (req, res) => {
// authenticate user
req.session.userId = user.id; // stored on server
res.send('Logged in');
});
app.get('/dashboard', (req, res) => {
if (!req.session.userId) return res.status(401).send('Unauthorized');
// fetch user data using session.userId
res.send(`Hello user ${req.session.userId}`);
});
Sessions are stateful: the server must maintain a session store (memory, database, Redis). When you scale to multiple server instances, the session store must be shared, which adds complexity.
What are JWT tokens?
JSON Web Tokens (JWT) are a stateless authentication method. After a successful login, the server generates a token containing a payload (like the user’s ID and role) and signs it with a secret key. The token is sent to the client, which stores it. For each subsequent request, the client sends the token, usually in the Authorization header as a Bearer token, or sometimes in an HttpOnly cookie. The server verifies the signature, extracts the payload, and trusts that the user is who the token claims.
We’ve already implemented JWT authentication in an earlier blog. Here’s a quick recap:
const jwt = require('jsonwebtoken');
app.post('/login', (req, res) => {
// authenticate user
const token = jwt.sign({ userId: user.id }, 'secret', { expiresIn: '1h' });
res.json({ token });
});
app.get('/profile', (req, res) => {
const token = req.headers.authorization?.split(' ')[1];
if (!token) return res.status(401).send('No token');
try {
const decoded = jwt.verify(token, 'secret');
req.user = decoded;
res.send(`Profile of user ${req.user.userId}`);
} catch (err) {
res.status(403).send('Invalid token');
}
});
Because JWT contains all the info needed (in the payload), the server doesn’t need to look up a session. That’s the stateless magic.
Stateful vs stateless authentication
This is the key distinction.
- Stateful (sessions): The server keeps track of authenticated users. Each request requires a session lookup. This works great for traditional multi‑page apps because scaling requires a shared session store. Logout is easy: just destroy the session on the server.
- Stateless (JWT): The server doesn’t store anything. It trusts the token after verifying the signature. This makes horizontal scaling a breeze. Logout is trickier: since the server doesn’t remember the token, you can’t invalidate it without a blacklist (bringing back some state). Usually, you set short expiration and rely on the client removing the token.
Think of sessions as a coat-check ticket: you give the clerk your coat, get a ticket, and later hand the ticket back to retrieve your coat. The clerk (server) remembers you. JWT is like a digital passport: the passport says who you are, and the border official (server) verifies its authenticity without calling home. Both have their place.
Sessions vs JWT: detailed comparison
| Feature | Session‑based | JWT |
|---|---|---|
| State | Stateful (server stores session data) | Stateless (server only verifies token) |
| Storage | Session ID stored in a cookie; session data stored server‑side (memory, DB, Redis) | Token stored client‑side: browser (localStorage, sessionStorage) or HttpOnly cookie; no server‑side storage |
| Scalability | Requires shared session store across instances (e.g., Redis) | Easy to scale horizontally; no server‑side data sharing needed |
| Logout | Server deletes session – immediate effect | No server‑side record; token can’t be invalidated instantly unless a blacklist is used. Short expiry & client removal are typical |
| Security typical risks | Session hijacking (if cookie stolen), CSRF (mitigated with SameSite, tokens) | Token theft (if stored in non‑HttpOnly cookie or localStorage), XSS (if accessible via JS), token size |
| Payload visibility | Server‑side, opaque to client | Payload is Base64‑encoded (not encrypted); everyone can read it, but signature ensures integrity. Never put secrets in payload |
| Typical use case | Traditional server‑rendered web apps, multi‑page apps, apps with centralized user management | APIs, single‑page applications (SPAs), mobile apps, microservices, third‑party integrations |
Note that you can store a JWT inside an HttpOnly cookie, blending some benefits: you get automatic cookie sending (no need to attach header manually) and protection from XSS, while still being stateless. The choice of where to store the token is separate from the choice of session vs JWT.
When to use each method
Use sessions when:
- You have a traditional server‑rendered application (EJS, Pug, etc.).
- You need fine‑grained control over active session invalidation (e.g., force logout, revoke access instantly).
- You’re comfortable managing a session store (or don’t mind the overhead for a simple app).
- You want to keep sensitive data on the server.
Use JWT when:
- You are building a REST API that serves multiple frontends (web, mobile, desktop).
- You want to scale horizontally without worrying about a shared data store.
- You need to pass authorization across multiple independent services (microservices).
- Your client is a SPA where the frontend handles presentation and stores the token (e.g., in memory or localStorage, though HttpOnly cookie is safer).
A hybrid approach: store a short‑lived JWT inside an HttpOnly, Secure, SameSite cookie. That way you get automatic cookie handling, XSS protection, and still remain stateless on the server. This is increasingly popular in modern frameworks.
Conclusion
Sessions, cookies, and JWT aren’t mutually exclusive; they’re pieces of the authentication puzzle. Cookies transport data (session IDs or JWTs) seamlessly. Sessions give you server‑side control at the cost of state. JWT gives you stateless scalability at the cost of instant invalidation. Choosing between them depends on your application architecture, scalability needs, and security priorities.
To recap:
- Cookies are a transport mechanism, automatically sent with every request, and can be secured with HttpOnly, Secure, and SameSite flags.
- Sessions store user state on the server and use a cookie holding a session ID. They are stateful and great for traditional web apps.
- JWT embeds user information in a signed token; the server doesn’t need a lookup. They are stateless and ideal for APIs, SPAs, and microservices.
- The decision often hinges on stateful vs stateless needs and where you want to store sensitive data.
In the next post, we’ll start connecting Express to databases; building a full‑stack authentication flow with registration and login that persists real data. See you then!
Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.
Top comments (0)