💡
A cookie is just a string the browser carries. Whether that string is a session ID, a JWT, or a user preference — the cookie doesn't care.
## **JWT: Identity in the Token**
03 / What Are JWT Tokens
A JSON Web Token is a self-contained credential. Instead of issuing a random ID and keeping a record server-side, the server encodes the user's identity directly into the token itself — and signs it cryptographically so it can't be tampered with.
A JWT has three parts separated by dots: a **header** (algorithm info), a **payload** (claims: user ID, role, expiry), and a **signature** (cryptographic proof of authenticity). When the server receives a JWT, it only needs to verify the signature — no database lookup required.
```javascript
const jwt = require('jsonwebtoken');
// 1. Login: sign a token and return it
app.post('/login', (req, res) => {
const user = validateCredentials(req.body);
const token = jwt.sign(
{ userId: user.id, role: user.role },
process.env.JWT_SECRET,
{ expiresIn: '24h' }
);
res.json({ token }); // client stores this
});
// 2. Protected route: verify without any DB call
app.get('/dashboard', (req, res) => {
const token = req.headers.authorization?.split(' ')[1];
const decoded = jwt.verify(token, process.env.JWT_SECRET);
res.json({ userId: decoded.userId });
});
```
![](https://cdn.hashnode.com/uploads/covers/696f9f5589255b82f81f6b17/75d41992-42af-41f0-a831-8fbd11a81d9e.png align="center")
##
**Stateful vs Stateless Auth**
04 / Core Concept
This is the architectural divide. **Stateful authentication** (sessions) requires the server to maintain a record of who is logged in. Every request triggers a database or cache lookup. The server is the source of truth — which means it can also instantly revoke access.
**Stateless authentication** (JWT) embeds identity in the token itself. The server trusts the token's signature and needs no external lookup. This scales beautifully — any server in a cluster can validate any token independently. The tradeoff: you cannot "un-sign" a token once issued. Revocation requires workarounds like a token blocklist (which reintroduces state).
###
**Session-Based vs JWT: Comparison**
05 / Differences
| **Property** | **Sessions** | **JWT Tokens** | **Cookies (as transport)** |
| --- | --- | --- | --- |
| **State** | Stateful — server stores session data | Stateless — token carries all data | Neutral — just a transport mechanism |
| **Storage** | Session store (Redis, DB, memory) | Client-side (localStorage, cookie) | Browser, auto-sent with requests |
| **Revocation** | Instant — delete session record | Hard — must wait for expiry or blocklist | Depends on what it carries |
| **Scalability** | Requires shared session store across servers | Scales naturally — any server can verify | No scaling impact on its own |
| **Payload size** | Small (just an ID in the cookie) | Larger — grows with claims in token | Limited to ~4KB total |
| **Server DB call** | Every request hits the session store | No lookup needed — verify in memory | Depends on what the cookie holds |
| **Cross-domain** | Difficult — cookies are domain-scoped | Easy — bearer token works anywhere | Restricted by SameSite / CORS rules |
| **Typical use** | Traditional web apps, server-rendered | APIs, mobile apps, microservices | Paired with sessions or JWT for transport |
* * *
## **When to Use Each**
06 / Decision Guide
There is no universally superior approach. The right choice depends on your architecture, your team's needs, and the nature of your application.
**Use Sessions When**
* You need instant account revocation (e.g., "log out all devices", ban a user)
* Building a traditional server-rendered web app (Rails, Django, Express with Pug)
* Your data is sensitive and you want zero user data in the browser
* You already run Redis or a caching layer
* You're building an admin panel or internal tool with strict access control
**Use JWT When**
* Building a stateless REST API consumed by mobile apps or SPAs
* Operating across multiple domains or microservices
* Horizontal scaling matters and a shared session store is a bottleneck
* Implementing OAuth 2.0 or third-party integrations
* Short-lived tokens where expiry-based invalidation is acceptable
**Use Cookies (as transport) When**
* You want the browser to handle token delivery automatically
* Security is a priority — `HttpOnly` cookies block XSS token theft
* You want `SameSite=Strict` CSRF protection built in
* The app and API share the same domain
**Combine Both**
* Store a JWT inside an `HttpOnly` cookie to get stateless verification with the security of cookie transport
* Use a short-lived JWT + a long-lived refresh token in a session record for revocable stateless auth
* Many production apps pair these approaches depending on route sensitivity
💡
The practical default for most web apps in 2025: JWT stored in an HttpOnly, Secure, SameSite=Strict cookie gives you stateless verification, automatic browser delivery, and meaningful XSS protection — without the scaling overhead of a session store.