Passport.js session serialization vs passport-jwt with session:false when the load balancer already pins sticky sessions

Short answer

Use a Redis-backed session store from day one. Given your stated constraints—revocation matters and sticky affinity is guaranteed only for now—the classic serializeUser/deserializeUser model with a shared session store is the more defensible trade-off. passport-jwt with session: false is a good fit when you can tolerate a revocation window or when you already have shared state for refresh-token rotation or token-version checks. It does not remove shared state if revocation is hard.

What is confirmed vs likely

Confirmed behavior: with session-backed Passport, serializeUser stores an identifier in the session and deserializeUser turns it back into req.user on each request. With passport-jwt and session: false, Passport does not create or read a session, so deserializeUser is not part of the request path. Confirmed: stateless JWTs cannot be revoked before exp without some shared check. Likely for your app: the operational simplicity of deleting a Redis session on logout or account disable will outweigh the theoretical statelessness benefit.

Why Redis sessions fit your constraints

• Logout and account disable become a store delete. Any node can serve the next request, so losing affinity or rebalancing does not break authentication.
• Sticky sessions only mask the shared-state problem. If you use the default in-memory store, a node failure drops that node's sessions; that is not production-safe.
• You avoid refresh-token rotation races, clock-skew edge cases, and a second token lifecycle to test.

What JWT would actually require

Short access-token exp plus refresh rotation limits the revocation window but does not eliminate it. To disable an account immediately, you still need a denylist keyed by jti, a per-user token version, or a refresh-token store. That is shared state. If you store JWTs in browser cookies, you also reintroduce CSRF concerns; if you store them in browser storage, you accept XSS exfiltration risk.

Latency: does session: false help?

Only if your deserializeUser performs a database lookup on every request. If it does, skipping it is a real saving. But a Redis session lookup is also one network round trip, and JWT verification is local CPU work. If you add a revocation check for JWT, the gap shrinks or disappears. Measure with your real session payload and user-fetch cost rather than assuming JWT is faster.

Running both strategies side by side

It is supported, but keep the middleware scoped. Register both strategies, then choose per route:

app.use(passport.initialize());

// Browser routes
browserRouter.use(passport.session());

// API routes
apiRouter.get('/me',
  passport.authenticate('jwt', { session: false }),
  handler
);

Pitfalls: calling passport.session() globally and then req.login() on API requests can silently create sessions. Session users and JWT claims may have different shapes, so normalize req.user. CSRF protection belongs on cookie-session routes; bearer-token routes generally do not need it, but cookie-stored JWTs do. Logout must clear the session and any refresh cookie.

Verification steps

1. Disable a test user. Confirm a session-backed request fails immediately and a JWT-backed request fails only after exp or refresh denial.
2. Stop one app node while a user is logged in. With Redis sessions, the next request should still authenticate after the load balancer rebalances.
3. In the hybrid setup, inspect req.session after API calls to confirm session: false routes never create session cookies.

Version assumption: Express 4 and the Passport 0.6/0.7 line. Test logout and session regeneration on your exact patch before relying on them.

One detail that changes the latency advice

Does your current deserializeUser query the database on every request, or does the session already carry enough user data? If it queries every time, session: false may save a hop. If it does not, the latency argument for JWT is weak.