session VS cookie-session

https://github.com/expressjs/session/issues/360 this is an issue I think that's very close to mine, no concrete solutions though..

Passport needs to be initialized as middleware as well. And it requires a session middleware for storing state and user data. The most common session middleware is express-session.

You need to pick a session store for your cookies. By default, I think express-session uses an in-memory store which means sessions are reset every time the server restarts. Redis is what I'd generally recommend for managing session stores, but setting up Redis is ANOTHER configuration update. There are a bunch of other options, too, such as using a Mongo database as a session store.

If you want to store your session data manually on Redis, check here. But in this article I will use Express session middleware which can work with Redis for user session management.

This problem can be solved by using a "session store" library such as connect-redis (see express-session's documentation for the list of session store libraries for Express.js). The idea is to keep session tokens in a dedicated database, and each time the user makes an HTTP request with their session token, the server receiving the request will consult this database to learn whether the request comes from the authenticated user or not. Performance suffers consequently, as retrieving data from a database always takes some time.

The lack of logout and XSS are problems, but I ran into a couple apps that completely forgot to expire sessions due to lacking framework support. In nodejs's cookie-session and @google-cloud/connect-firestore sessions never expire. This issue impacts downstream software including, awkwardly enough, Google's Passkey demo apps. There isn't interest in fixing this.

Make sure your app is actually using a JWT framework, not a lesser version, and implements basic security practices.

[1] https://github.com/expressjs/cookie-session

[2] https://github.com/googleapis/nodejs-firestore-session

Side note: a JWT in an HttpOnly cookie, which is what some people advocate, is still a cookie-based session. Using a library like cookie-session would already give you the ability to have a signature-verified JSON payload, just like using a JWT would.

Frameworks usually sign cookies by default, or at least offer an option to do so. Some (like Ruby on Rails) can encrypt them for you too. There's nothing really stopping you from storing data in them just like you would a JWT. In fact, frameworks and session libraries often use this cookie storage by default (even in the Node ecosystem, e.g: koa-session, express cookie-session), since an in-memory store can grow to an arbitrary size. Of course, you can also just store a JWT in a cookie, which has the advantage of being standardized in terms of claims and signing algorithms etc.