Passport.js serializeUser/deserializeUser lacks built‑in schema‑version guard

Goal

Define a reliable strategy to keep existing sessions valid or safely invalidate them when the user model changes (fields added, removed, or renamed).

Constraints

• Passport.js stores only what serializeUser returns; deserializeUser receives that opaque payload on every request.
• No core hook exists to attach a schema version, run a migration, or automatically purge stale sessions.
• The underlying express-session store treats the session blob as opaque, so migration must happen inside deserializeUser or via custom middleware.
• Adding a version check on every request adds latency; short TTLs limit exposure but increase login frequency.

Open questions

1. What pattern embeds a schema version in the serialized payload without breaking existing sessions?
2. Can middleware intercept deserializeUser to enforce version checks without per‑request overhead?
3. What are the trade‑offs between short rolling TTLs and explicit session invalidation for schema migrations?