Session and Token Management Store Recommendation

[janmchan]

We are migrating our first SPA into BFF. One of the point of discussion is how we will persist the session and tokens. We've decided to store it in a postgres database but is now conflicted on how to structure this per project. Can you guys share your thoughts?

1. One database per application one table each for sessions and tokens.
2. One database and then separate the tables by schema using the application name then one table each for sessions and tokens.
3. Create an abstraction through API that will expose CRUD operations using internal endpoints for token and session. This will be one database and one table each for sessions and tokens.

The first option probably the most straightforward but is getting some push back regarding the need to provision a dedicated db for each application. Option 2 is a compromise to only use a single DB. Option 3 will generate some latency and also end up using a single Db but we don't expect a high volume of sessions (<10,000) so I'm trying to simulate if this is feasible.

[wcabus]

We cannot really answer this question as it's more a consultancy than a support-related one. If you're seeking specific guidance, we can connect you to one of our partners to help with this on a consultancy basis. Feel free to contact us for more details.

That said, I can share my personal thoughts: I wouldn't recommend storing sessions and tokens through an API simply because of the additional overhead it would introduce per call. Sharing a single database or provisioning a database per application seems both viable, as long as you ensure proper schema separation and security when going for a single database option.
I don't know where you're hosting/provisioning the databases. If you're on Azure, you may be able to use database pooling to provision a database per application while sharing resources across these databases in a pool.