Passport deserializeUser and stale session data: is there a supported way to refresh the cached user object?

Answer

No. Passport does not expose a built-in option, middleware hook or configuration flag to invalidate or automatically refresh the deserialized user object when the database record changes. The supported extension point is deserializeUser itself. Whatever it returns becomes req.user for that request.

For the goal of reflecting role, permission, suspension or profile changes without logout, the sanctioned approach is to make deserializeUser look up the current record on each authenticated request. There is no roadmap or open proposal for built-in stale-session handling in Passport’s session API.

Confirmed facts

• serializeUser writes an identifier into the session. Passport does not cache a user object.
• deserializeUser is invoked once per authenticated request to turn that identifier back into req.user.
• Passport has no server-side validity check beyond what your deserializeUser performs. Session TTL in the store, e.g. Redis, only bounds how long the session identifier persists.

Likely explanation and practical patterns

The “cached user” is not in Passport, it is the result you return from deserializeUser. Re-querying per request is the documented intended use and gives immediate freshness on the next request.

Common production trade-offs:

1. Per-request DB lookup in deserializeUser. An indexed primary-key lookup is usually cheap enough. This is mandatory for hard revocation such as account suspension.
2. Short-TTL cache inside deserializeUser, e.g. Redis with a few seconds TTL, plus explicit invalidation of that cache key on user writes. This reduces DB load while bounding staleness.
3. Session re-write on change. After a profile/permission update you can call req.login(user) to re-run serializeUser and overwrite the session copy for that session only. This does not affect other devices.

Performance and consistency guidance is not documented by Passport. Measure query cost in deserializeUser under load before adding caching. Caching re-introduces staleness; the TTL and invalidation on writes determine worst-case delay.

Steps for this case

1. Ensure deserializeUser fetches the user by the stored id on every request and returns the fresh record or null to end the session.
2. If query cost is a concern, add a short-TTL cache around that lookup and delete the cache key on any user update path.
3. Set a reasonable session maxAge and touch on activity to bound how long stale session identifiers persist in the shared store.

Verification: log calls inside deserializeUser during a test session, change a user role in the DB, make a new authenticated request without logging out, and confirm req.user reflects the change. Inspect session store TTL for the session key to confirm persistence bounds.

One diagnostic detail that changes the recommendation: do you require immediate revocation across all devices, or is per-session refresh acceptable? Cross-device instant revocation requires a DB lookup or cache invalidation in deserializeUser; per-session refresh can be achieved with req.login after a change.