Securing Express Apps with Passport Local Strategy: A Practical Walk‑through

The problem: raw passwords and ad‑hoc auth

Many Express projects start with a hand‑rolled login handler that stores passwords in plain text or compares them with a simple string match. That approach breaks down fast: credential leakage, no session handling, and no standard way to protect routes. Passport.js solves the middleware side, but you still need to wire a LocalStrategy, a secure session store, and a password hash like bcrypt.

Wiring the pieces together

Three npm packages form the core stack:

• passport – authentication middleware
• passport-local – username/password strategy
• express-session – server‑side session handling

Add bcrypt for hashing. Install with:

npm i passport passport-local express-session bcrypt

Session configuration

Configure express-session before Passport middleware. Use a secret from environment variables, set cookie: { httpOnly: true, secure: true, sameSite: 'lax' } for production, and choose a store that survives restarts (Redis, MongoDB, etc.).

app.use(session({
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: { httpOnly: true, secure: true, sameSite: 'lax' }
}));
app.use(passport.initialize());
app.use(passport.session());

LocalStrategy verify function

The verify callback receives username, password, and done. Look up the user, compare the bcrypt hash, then call done(null, user) on success or done(null, false, { message: 'Invalid credentials' }) on failure.

passport.use(new LocalStrategy(
  { usernameField: 'email' },
  async (email, password, done) => {
    const user = await User.findOne({ email });
    if (!user) return done(null, false, { message: 'No user found' });
    const match = await bcrypt.compare(password, user.passwordHash);
    if (!match) return done(null, false, { message: 'Wrong password' });
    return done(null, user);
  }
));

Serialize / deserialize

Only the user identifier should live in the session. Serialize the ID, then fetch the full record on each request.

passport.serializeUser((user, done) => done(null, user.id));
passport.deserializeUser(async (id, done) => {
  try {
    const user = await User.findById(id);
    done(null, user);
  } catch (e) { done(e); }
});

Worked example: minimal login flow

Assume a User model with email and passwordHash. The login route uses passport.authenticate('local') with a custom callback to control the response.

app.post('/login', (req, res, next) => {
  passport.authenticate('local', (err, user, info) => {
    if (err) return next(err);
    if (!user) return res.status(401).json({ error: info.message });
    req.logIn(user, (loginErr) => {
      if (loginErr) return next(loginErr);
      return res.json({ user: { id: user.id, email: user.email } });
    });
  })(req, res, next);
});

Protect a profile endpoint with a tiny guard:

function ensureAuthenticated(req, res, next) {
  if (req.isAuthenticated()) return next();
  res.status(401).json({ error: 'Not authenticated' });
}

app.get('/profile', ensureAuthenticated, (req, res) => {
  res.json({ user: req.user });
});

Trade‑offs and hardening

Passport’s LocalStrategy is deliberately simple—it does not provide OAuth, MFA, or token refresh. If those features become necessary, plan a migration to a dedicated identity provider or augment with passport-jwt for stateless APIs.

Verify it works

1. Start the server (node app.js).
2. POST /login with a known email and correct password; expect a Set-Cookie header containing the session ID and a JSON body with the user object.
3. Using the returned cookie, GET /profile; the response should echo the same user data.
4. Repeat the login with a wrong password; the response must be 401 and no session cookie should be set.
5. Inspect your session store (Redis CLI, Mongo shell, etc.) – only the user ID should appear, never the password hash.

If all five checks pass, the authentication pipeline is functional and follows the baseline security posture outlined above.