Node.js Authentication Overview

Session-Based vs Token-Based Authentication

Session-based authentication stores a session identifier in a cookie after login; the server keeps track of that session's associated user in memory, a database, or a store like Redis, and looks it up on every request. Token-based authentication (typically JWT) issues a self-contained, signed token after login; the server verifies its signature on each request without needing to store anything server-side.

Neither approach is universally "better", sessions are simple and easy to revoke instantly, while tokens scale more naturally across multiple servers or services without shared session storage, at the cost of harder instant revocation.

// Simplified authentication flow, either approach
app.post('/login', async (req, res) => {
  const { email, password } = req.body;
  const user = await findUserByEmail(email);

  const validPassword = user && await verifyPassword(password, user.passwordHash);
  if (!validPassword) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }

  // Session-based: req.session.userId = user.id;
  // Token-based:   const token = signToken({ userId: user.id });

  res.json({ message: 'Logged in' });
});

Both approaches share the same login step, verifying credentials, they differ only in how the server remembers the authenticated user afterward.

The Authentication Flow

1. Client submits credentials (email + password)
2. Server verifies credentials against stored hash
3. Server issues proof of identity (session cookie or JWT)
4. Client sends that proof on every subsequent request
5. Server verifies the proof before processing the request

• Authentication verifies identity; authorization (a separate concern) decides what an authenticated user can do.
• Passwords must never be stored in plain text, see the Password Hashing lesson.
• Session cookies rely on server-side lookups; JWTs are self-contained and verified cryptographically.
• Both approaches need HTTPS in production to protect credentials and tokens in transit.

Authentication Approaches Cheatsheet

A high-level comparison of the two main strategies.

Authentication vs Authorization

These two terms are often confused but answer different questions. Authentication confirms who the user is, authorization decides what that authenticated user is allowed to do (which routes, which resources, which actions). A request can be authenticated but still fail authorization, e.g. a logged-in user trying to access another user's private data.

Choosing Between Sessions and Tokens

Server-rendered applications (where the browser talks directly to the same server rendering HTML) often favor sessions, they're simple and revocation is trivial. APIs consumed by mobile apps, single-page apps, or multiple backend services often favor JWTs, since there's no shared session store required across services.

Common Mistakes

• Confusing authentication (who you are) with authorization (what you're allowed to do).
• Storing passwords in plain text or with a fast, unsalted hash instead of a dedicated password-hashing algorithm.
• Sending authentication tokens or session cookies over plain HTTP instead of HTTPS.
• Assuming JWTs can be instantly revoked the same way a server-side session can.

Key Takeaways

• Authentication verifies identity; authorization governs permissions for an already-authenticated user.
• Session-based auth relies on server-side lookups; token-based auth (JWT) is self-contained and stateless.
• Sessions offer instant revocation; tokens scale better across multiple stateless servers.
• Both approaches require HTTPS and secure password storage to be safe in production.