Passport.js serializeUser Attachment Persistence Across Express-session Restores

Direct Answer

Only JSON-serializable properties attached to req.user survive an Express-session restore. Functions, class instances, Date objects, Symbols, and other non-serializable values are lost or corrupted because the session store—not Passport.js—controls serialization. Strategy-specific profile data must be reduced to plain objects and primitives to persist consistently across strategies.

Why This Happens

Passport.js stores the user object returned by serializeUser into the session. When express-session saves the session, it hands the entire session payload to the configured store. Most stores (including the default MemoryStore and common Redis/Mongo adapters) serialize via JSON.stringify or an equivalent process. Anything that JSON.stringify drops or transforms—functions, undefined, Symbol, class instances, circular references—will not reappear after the session is reloaded and deserializeUser runs.

Verification Steps

1. Add a test marker. In your serializeUser callback, attach a simple, JSON-safe property to the user object before returning it:

   passport.serializeUser((user, done) => {
     const safeUser = { ...user, __testMarker: 'verify-persistence' };
     done(null, safeUser);
   });

2. Use a JSON-backed store for the test. Configure express-session with a store that uses standard JSON serialization (e.g., connect-redis with default settings or a test-only MemoryStore). Avoid custom serializers during this verification.
3. Exercise a full cycle.
   • Log in to create a session.
   • Inspect req.user.__testMarker—it should be present.
   • Stop the server (or call sessionStore.destroy(sessionId)) to force a fresh deserialize on next request.
   • Restart the server and make a new request with the same session cookie.
   • Check whether req.user.__testMarker equals 'verify-persist'.
4. Compare before/after. Log the full req.user object before destroy and after restore. Any missing keys or transformed values (e.g., Date → ISO string) reveal what the store's serialization discards.

Strategy-Specific Profile Data

Each Passport strategy (Google, GitHub, Local, etc.) returns a profile object with its own shape. To achieve cross-strategy consistency:

• Normalize in serializeUser. Map every strategy's profile to a common plain-object schema (e.g., { id, provider, email, name }).
• Strip non-serializable fields. Remove _json, _raw, tokens, or any nested objects containing functions/class instances before passing the user to done().
• Rehydrate in deserializeUser. Use the stored id and provider to fetch fresh data from your database or the provider's API if you need live tokens or complex objects.

One Diagnostic Detail Needed

Which session store are you using in production (e.g., connect-redis, connect-mongo, custom)? The store's serialization behavior—especially any custom stringify/parse overrides—determines exactly what survives, so the verification must run against that same store configuration.