Passport.js session serialization: configuring serializeUser to store minimal user identifier

Direct answer

serializeUser should return only the stable primary key that uniquely identifies the user in your persistence layer—typically user.id, user._id, or a UUID. deserializeUser receives that single value, performs a lookup, and passes the fully populated user object to done(null, user). Custom strategies that attach additional properties to req.user during the initial authentication will not have those properties automatically restored on subsequent requests; deserializeUser must explicitly re-attach any fields your application expects beyond the database record.

Established behavior vs. application-specific risk

Passport’s session middleware stores whatever serializeUser returns as the session payload. Returning the primary key is the documented pattern for minimizing session size. The authentication strategy runs only during the initial login; after that, passport.session() invokes deserializeUser on every request to hydrate req.user. This behavior is orthogonal to the strategy used.

Whether custom strategies continue to work depends on whether downstream code expects properties that were attached during authentication but are not part of the standard user record. For example, an OAuth strategy might attach accessToken or refreshToken to req.user at login time. If route handlers or middleware read those fields on later requests, they will be undefined unless deserializeUser re-populates them from a separate store or a database column.

Implementation steps

1. Change serializeUser to return the identifier:

   passport.serializeUser((user, done) => {
     done(null, user.id);
   });

2. Update deserializeUser to fetch the full record and re-attach any non-database fields your application requires:

   passport.deserializeUser((id, done) => {
     User.findById(id)
       .then(user => {
         if (!user) return done(null, false);
         // Re-attach fields expected by custom strategies or middleware
         user.permissions = loadPermissionsFor(id);
         done(null, user);
       })
       .catch(err => done(err));
   });

3. Ensure deserializeUser is registered before any middleware or route that accesses req.user.

Verification

After login, inspect the session store directly. In Redis, the session key should contain only the identifier rather than a serialized user object:

redis-cli GET "session:<session-id>"

Add temporary logging inside deserializeUser to confirm it receives the identifier and returns the expected shape. Finally, exercise a protected route and assert that every property consumed by your controllers exists on req.user.

One diagnostic that changes the recommendation

Do any custom strategies or downstream middleware depend on req.user properties that are attached only during the initial authentication and are not stored in your user table? If yes, you must either persist those fields in a separate server-side store keyed by the user ID or re-fetch them in deserializeUser. If no, the identifier-only pattern is sufficient.