Codementor Events
Discussion

Node Express Passport shared Sessions

Published Oct 20, 2017

Hey community, ๐Ÿ˜ƒ

I'd like to discusss a load balancing - single sign on - passport shared session architecture, in case someone should be interested.

The situation is as follows:

Backend:
An open number of node/express microservices(Websockets, and Database-, and Misc-Resource-RESTServices) will each run within a load balanced cluster and
act as facades to arbituary resources.
SSL will be used and IP-range restrictions and Passport-JWT.

Storage:
2 load balanced mysql(or whatever) database server clusters.

  • 1 for node/express/passport sessions
  • 1 for custom businsess data apart from session sharing

SSL will be used and IP-range restrictions for both.

Frontend:
An open number of arbituary client portals(node/express, vue, laravel, custom, etc.) again each running within a load balanced cluster need to provide single-sign-on to the whole backend and all other connected frontends.

The current approach is to install passport on every instance in each cluster and let each passport config use the same session-database(cluster).
This database only contains a user table with rudimentary userdata(email, password, etc.) and the node/express/passport session table.
As all cluster instances have their passport setup share the same session table
a single sign on is achieved and all frontends can use the same JWT to authenticate against the backend's REST interfaces.

So instead of running some sort of token server, the session will be maintained
from i.e. a mysql server(cluster).

The application must be able to handle up to 100k client post requests
per second ๐Ÿ˜ƒ
which each needs to be authenticated via passport JWT against the backend's
REST interfaces.
Of course this will produce heavy loads on the session-database(cluster) but this is acceptable and dealt with accordingly.

Alright, that's it,
hope I could make myself clear.
In case not, please let me know and I will put up some UML.

What do you think of this approach?
Do you see issues, approvements, blockers?
I set up a rudimentary test to check if SSL, IP-range restrictions and passport
login and session sharing would generally work regarding security and processes.

All seems to be running fine, better then expected, which actually makes me wonder whether I'm missing something here.
I do not have any code ready to present though, as it is all a mess currently with lots of left overs from different approaches.
But anyway, no big deal. simple node https/express servers/endpoints with standard passport setup, sharing same session table from same database.

Ok, thanks for your interest so far.
I'd welcome your thoughts on this or your sharing of experiences with similar setups or totally different approaches.

Have a nice weekend
Christian

Discover and read more posts from Christian Schluessel
get started
post comments2Replies
Christian Smith
a year ago

Hi Christian. If you want to handle 100k requests per second I would avoid calling the session database on API authentication. One of the biggest advantages of JWTs is that, depending on your security requirements, you probably donโ€™t need to look tokens up in the database in order to verify. That is accomplished with signature verification which is CPU-bound rather than I/O-bound. A signature can be verified in microseconds, whereas a database request may take several milliseconds at best.

If you need further guidance on how to use JWT effectively, I implemented one of the first open source OIDC servers, the full suite of JOSE (JWT, JWE, etc) and Web Cryptography API for Node.js a number of years ago and have architected many sophisticated auth schemes. Iโ€™m available to consult on architecture and integration if youโ€™re interested in hands-on help.

Christian Schluessel
a year ago

hi, Christian, thanks for your reply.
Unfortunately itโ€™S not only about verifying the JWT but as well to extract the useid by which user data can be extracted from the database.
but eventually we handled that by only doing this once ever 30 minutes saving the data in a cookie that expires after that period.