Search for a command to run...
Why HTTP is amnesiac, the difference between transport and state, and how to choose the right auth strategy for your Node.js app.
No comments yet. Be the first to comment.
These are the assignments or knowledge dumps I decide to write for the "Chai aur Code's web Dev Cohort 2026"
RAG helps LLMs answer questions using your own data, but it doesn't guarantee correct answers. Here's how the pipeline works and where it commonly breaks down.
Imagine asking an AI, "Write a blog," versus "Act as an SEO expert and write a 1,000-word blog on AI safety formatted in markdown." The difference in the resulting output is night and day. A prompt is
Spotify and Apple Music make it incredibly easy to showcase your live listening habits on your website. YouTube Music? Not so much. After doing some setup you can do an API call and fetch your account
Arthur C. Clarke's famous third law: "Any sufficiently advanced technology is indistinguishable from magic" perfectly captures how the pace of human innovation works. From carrying supercomputers in o
When I first tried to build a login system, I asked a senior developer what I should use. He said, "Just use cookies." Another developer overheard and said, "No, cookies are dead, use JWTs." A third chimed in, "JWTs are insecure, use sessions."
I spent the next week completely paralyzed.
The problem with learning authentication is that the industry uses the terms Cookies, Sessions, and JWTs as if they are three competing options on a menu. They aren't. Comparing cookies to JWTs is like comparing a delivery truck to a pizza. One is a vehicle; the other is the cargo.
To build secure Node.js applications, we have to decouple how we transport data from how we manage state.
Let’s break down exactly what these three terms mean, the fundamental difference between stateful and stateless architecture, and how to actually make the right choice for your application.
Every authentication strategy exists to solve one single problem: HTTP is stateless.
When you send a POST /login request with your username and password, the server validates it and says, "Great, you are Alice." But the very next time you make a request—say, GET /dashboard—the server has completely forgotten who you are.
To fix this, the server needs to give the client a token of proof. The client must then present that token on every subsequent request.
Let's start by defining the vehicle.
A Cookie is just a tiny text file that a server asks a browser to hold onto. It is not inherently an authentication tool. It is just a storage mechanism with one magical property: browsers automatically attach cookies to every single request they send to the domain that created them.
If your Express server sends a cookie to the client, you never have to write frontend code to attach it to future requests. The browser does the heavy lifting.
app.post('/login', (req, res) => {
// We are just telling the browser: "Hold onto this string for me."
res.cookie('my_auth_data', 'secret_value_here', {
httpOnly: true, // Prevents client-side JS from reading it (Security!)
secure: true, // Only sends over HTTPS
maxAge: 3600000 // Expires in 1 hour
});
res.send("Logged in!");
});
A cookie is just a backpack the browser wears. What matters is what we put inside the backpack. We have two main choices: a Session ID, or a JWT.
Session-based authentication is the traditional way the web has handled logins for decades.
In this model, the server is responsible for remembering everything. When a user logs in, the server creates a "Session" object in its own memory or database (like Redis). This object contains the user's ID, role, and data.
The server then generates a random, meaningless string called a Session ID (e.g., xyz123), and sends only that ID to the browser inside a cookie.
When the user makes their next request, the browser sends the cookie. The server reads xyz123, looks it up in its database, and says, "Ah, session xyz123 belongs to Alice!"
Because the server has to maintain a database of active sessions, this is called Stateful Authentication.
// Using 'express-session' to handle the heavy lifting
app.post('/login', (req, res) => {
const user = db.findUser(req.body.username);
if (user) {
// We attach the user ID to the session.
// Express automatically generates a Session ID, saves it to memory/Redis,
// and sends the ID to the browser in a cookie.
req.session.userId = user.id;
res.send("Logged in");
}
});
app.get('/dashboard', (req, res) => {
// The server looks up the cookie's Session ID in the database automatically
if (req.session.userId) {
res.send(`Welcome back, user ${req.session.userId}`);
}
});
The Tradeoff: Sessions are incredibly secure. If Alice's laptop is stolen, the admin can simply delete her Session ID from the database, and she is instantly logged out. However, sessions are hard to scale. If you have 100,000 active users, your server has to do a database lookup 100,000 times a minute just to figure out who is making requests.
JSON Web Tokens (JWT) solve the database bottleneck.
Instead of saving the user's data in a database and sending a meaningless ID to the client, the server puts the actual user data (the payload) directly into a token. To prevent the user from tampering with it, the server signs the token using a secret cryptographic key.
When the user sends the JWT back on their next request, the server doesn't need to look up anything in a database. It just runs a quick mathematical check on the signature. If the signature is valid, the server trusts the data inside the token.
Because the server remembers nothing and relies entirely on cryptography, this is called Stateless Authentication.
const jwt = require('jsonwebtoken');
app.post('/login', (req, res) => {
const user = db.findUser(req.body.username);
if (user) {
// We pack the user data INTO the token itself
const token = jwt.sign({ userId: user.id, role: user.role }, "MY_SECRET_KEY");
// We can send this token in a JSON response (to be saved in LocalStorage)
// OR we can put it inside a Cookie!
res.json({ token: token });
}
});
app.get('/dashboard', (req, res) => {
const token = req.headers.authorization.split(" ")[1];
// We verify the math, NO database lookup required
const decodedPayload = jwt.verify(token, "MY_SECRET_KEY");
res.send(`Welcome back, user ${decodedPayload.userId}`);
});
The Tradeoff: JWTs scale infinitely because they require zero database lookups. But they have a massive flaw: you cannot easily revoke them. Because the server isn't checking a database, it has no way to "delete" a JWT. Until the token's expiration date passes, anyone holding that token is considered authenticated.
So, we have two distinct architectures. Let's look at how they stack up against each other.
| Feature | Session-Based (Stateful) | JWT (Stateless) |
|---|---|---|
| Where is the data stored? | On the Server (Database/Redis). | On the Client (inside the token). |
| What travels over the network? | A tiny, meaningless Session ID. | A larger, encoded payload. |
| Database Load | High. Every request requires a lookup. | Zero. Cryptography verifies the user. |
| Revocation (Forced Logout) | Instant. Delete the ID from the DB. | Hard. Token is valid until it expires. |
| Scalability across multiple servers | Requires a shared database (like Redis) so all servers know the sessions. | Trivial. Any server with the Secret Key can verify any token. |
The choice between Sessions and JWTs is not about which tech is "newer." It is an architectural decision based on your specific requirements.
Use Sessions (Stateful) when:
You are building a monolithic application (frontend and backend hosted together).
Security and control are your absolute highest priorities.
You are building an app for banking, healthcare, or enterprise where you must be able to instantly invalidate a user's access, or enforce "only one device logged in at a time."
Use JWTs (Stateless) when:
You are building a distributed microservices architecture (where API A, API B, and API C all need to verify a user without bottlenecking a single database).
Your backend is serving multiple different clients (a React web app, an iOS app, and an Android app).
You are dealing with massive, global scale and need to reduce database reads at all costs.
The next time someone asks you, "Should I use Cookies or JWTs?", you now know that is a trick question.
You can use Sessions inside Cookies. You can use JWTs inside Cookies. You can use JWTs inside Authorization headers.