Authentication Basics: logins, sessions and protected routes

What is authentication, exactly?

Every app with user accounts has the same three moments:

1. Signup — "I am Ali, here is my password." The server creates the account.
2. Login — "It is me again, here is my password." The server checks and says "prove it on future requests with *this*."
3. Every request after that — the browser attaches the proof, and the server checks it before touching private data.

The "proof" is either a session (the server remembers you and gives your browser a session ID, usually in a cookie) or a token (a signed string your browser carries; the server verifies the signature instead of remembering anything). The login screen you see is just step 2's user interface — the interesting machinery is steps 1 and 3.

Why can't the server just store my password?

Because databases leak. Backups get copied, old servers get sold, a bug exposes a table — and if passwords sit there in plaintext, every user's password is suddenly public, including the ones they reused on other sites.

So the server stores a hash: the password run through a one-way function. Given the password, the server can recompute the hash and compare; given only the hash, nobody can recover the password. Two extra ingredients make it strong:

• A salt — random data mixed in before hashing, so two users with the same password get different hashes (this defeats precomputed "rainbow table" attacks).
• A slow function — password hashing uses deliberately slow algorithms (scrypt, bcrypt, argon2) so trying billions of guesses takes years, not minutes.

How does a login actually work, step by step?

Follow one user, Ali, through the whole flow:

1. Register: Ali sends ali@example.com + a password. The server salts and hashes the password, stores email → salt:hash, and never stores the password itself.
2. Login attempt: Ali sends email + password again. The server looks up the stored hash, re-hashes the password *he just sent* with the stored salt, and compares. Match → login succeeds.
3. Token issued: The server creates a signed token — a small payload ({ email: "ali@example.com" }) plus a signature made with a secret only the server knows. It hands the token to Ali's browser.
4. Protected request: Ali asks for /dashboard. His browser sends the token along. The server recomputes the signature with its secret: if it matches, the token is genuine and untampered with; the server trusts the email inside it and answers. If not — 401 Unauthorized.

The server never needs to "remember" Ali between requests. The token *is* the memory, and the signature is what makes it trustworthy.

Sessions vs tokens — which should I learn first?

Both solve the same problem. The difference is *where the memory lives*:

• Sessions: the server keeps a table of "who is logged in" (session ID → user). The browser carries only the session ID in a cookie. Logging out is easy — delete the row. The cost: every server must share that table, which gets awkward as you add servers.
• Tokens (e.g. JWT): the server keeps nothing; the token carries the user info and a signature. Any server with the secret can verify it. The cost: you cannot easily cancel one token — you wait for it to expire, or keep a revocation list.

Learn the *concept* once (proof of login, verified per request) and both make sense. The demo below uses tokens because the whole flow fits in one file with no database; the Node & Express course lesson "Protecting Routes with Tokens (JWT)" builds the production-shaped version.

What is a protected route?

It is an ordinary route with a guard in front of it. In Express the guard is middleware — a function that runs before the handler:

// the guard: runs before any protected handler
function requireLogin(req, res, next) {
  const token = req.headers.authorization;   // the browser's proof
  const user = verifyToken(token);           // null if missing/forged
  if (!user) return res.status(401).send("Unauthorized — please log in first");
  req.user = user;                            // the handler now knows who asked
  next();                                     // let the request through
}

app.get("/dashboard", requireLogin, (req, res) => {
  res.send(`Welcome back, ${req.user.email}!`);
});

That is the whole pattern: check the proof, reject with 401, or attach the user and continue. Every framework has its version; the idea never changes.

Worked example: register, login and a guarded dashboard in Node

This script is the complete flow in one runnable file — no packages to install, only Node's built-in crypto module. Passwords are hashed with scrypt (a real password-hashing function); tokens are signed with HMAC (a hand-built teaching model of what JWT libraries do — see "What production does differently").

const crypto = require("crypto");

// ---- Password hashing with scrypt (a real password-hashing KDF) ----
function hashPassword(password) {
  const salt = crypto.randomBytes(16).toString("hex");
  const hash = crypto.scryptSync(password, salt, 64).toString("hex");
  return `${salt}:${hash}`;
}
function verifyPassword(password, stored) {
  const [salt, hash] = stored.split(":");
  const attempt = crypto.scryptSync(password, salt, 64).toString("hex");
  return crypto.timingSafeEqual(Buffer.from(hash, "hex"), Buffer.from(attempt, "hex"));
}

// ---- Signed tokens (teaching model of what JWT libraries do) ----
const SECRET = "demo-secret-change-me";
function createToken(payload) {
  const body = Buffer.from(JSON.stringify(payload)).toString("base64url");
  const sig = crypto.createHmac("sha256", SECRET).update(body).digest("base64url");
  return `${body}.${sig}`;
}
function verifyToken(token) {
  const parts = String(token).split(".");
  if (parts.length !== 2) return null;
  const [body, sig] = parts;
  const expected = crypto.createHmac("sha256", SECRET).update(body).digest("base64url");
  if (sig.length !== expected.length) return null;
  if (!crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected))) return null;
  return JSON.parse(Buffer.from(body, "base64url").toString());
}

// ---- In-memory "database" of users (in a real app: PostgreSQL) ----
const users = [];

function register(email, password) {
  if (users.find(u => u.email === email)) return "Error: email already registered";
  users.push({ email, passwordHash: hashPassword(password) });
  return `Registered ${email}`;
}
function login(email, password) {
  const user = users.find(u => u.email === email);
  if (!user) return "Error: no account with that email";
  if (!verifyPassword(password, user.passwordHash)) return "Error: wrong password";
  return createToken({ email });
}
function protectedDashboard(token) {
  const claims = verifyToken(token);
  if (!claims) return "401 Unauthorized — please log in first";
  return `Welcome back, ${claims.email}! Here is your private dashboard.`;
}

// ---- The story, step by step ----
console.log(register("ali@example.com", "correct-horse-123"));
console.log(register("ali@example.com", "another-pass"));      // duplicate email
console.log(login("ali@example.com", "wrong-pass"));           // wrong password
const token = login("ali@example.com", "correct-horse-123");   // correct login
console.log("token issued:", typeof token === "string");
console.log("plaintext stored?", users[0].passwordHash === "correct-horse-123");
console.log(protectedDashboard(null));                         // no token
console.log(protectedDashboard("fake.token"));                 // forged token
console.log(protectedDashboard(token));                        // valid token

Save it as auth-demo.js, run node auth-demo.js, and you get exactly this (Node.js v24.22.1):

Registered ali@example.com
Error: email already registered
Error: wrong password
token issued: true
plaintext stored? false
401 Unauthorized — please log in first
401 Unauthorized — please log in first
Welcome back, ali@example.com! Here is your private dashboard.

Read the output like a security checklist: duplicate registration is refused, a wrong password gets no token, the stored record contains no plaintext password (false), and the dashboard rejects both a missing token and a forged one — only the genuinely signed token gets through.

What production does differently

The demo teaches the concepts honestly, but a real app swaps four things:

• Passwords: use a maintained library (bcrypt, argon2) rather than calling scrypt yourself — the library handles salt generation, cost factors and safe comparison for you. This is exactly the course lesson "Register and Login: Hashing Passwords Safely".
• Tokens: use a tested JWT library instead of hand-rolled HMAC code — the demo's verifyToken is 10 lines; the edge cases it skips (algorithm confusion, key rotation) are why libraries exist. This is the course lesson "Protecting Routes with Tokens (JWT)".
• Transport: serve everything over HTTPS and store the token in an HttpOnly cookie where the site's threat model calls for it, so stolen tokens can't be read by injected scripts.
• Secrets and storage: the signing secret lives in an environment variable, never in source code; users live in PostgreSQL, not an in-memory array.

Common mistakes

• Storing passwords in plaintext — or with a fast hash. MD5 and SHA-256 are built for speed, which is exactly what helps an attacker guessing passwords. Password storage needs a *slow* function: bcrypt, argon2 or scrypt.
• Hand-rolling crypto in a real app. The demo's token code is a teaching model. Production uses tested libraries — the bugs in home-made token verification are subtle and the payoff for attackers is total.
• Putting tokens where any script can read them without thinking it through. localStorage is convenient and readable by JavaScript — which means readable by any cross-site-scripting payload too. Understand the trade-off before choosing; many apps prefer HttpOnly cookies.
• Hardcoding the signing secret in source code. Secrets in code end up in git history, screenshots and shared repos. Environment variables exist for exactly this.
• Guarding most routes but forgetting one. An unprotected /api/users next to a guarded /api/profile is a breach, not a partial win. The verification must run on *every* route that touches private data.

Frequently asked questions