Architect Auth flow

[zenlex]

• Need to design/implement user registration form (Will use OAuth with GitHub for actual auth, but need moderation flow for verifying users)
• Need to determine what user data we intend to persist / make available to microservices (while maintaining bounded contexts)
• Figure out backing service setup / needs (Redis, DB, etc.) or JWT flow
• Decide on protocol for microservices using session data vs state.

[helmturner]

We considered implementing Auth.js on the front-end and a redis-based session store, but as you mentioned, at some point down the road we'll probably be managing plumbing between a number of different services and applications with various stacks.

RE: Your suggestion of Clerk, that's probably our best bet. It's build on top of Auth.js (they maintain the library now), and it comes with integrations for just about everything we might need. It's built on open source, so if we need anything they don't have we can do it. Plus, in my experience, they've always been quite responsive and quick to add requested features!

[zenlex]

Yeah I think Clerk is a good choice at least to start with. Just need to figure out what user data we actually want to persist and where. Auth.js will use a database session if we want it to. Trying to think through where we might want to run a less secure but simpler and probably ok JWT flow vs if/where we'd want db sessions. Kinda hard to determine at this point without more high level discussions about some anticipated features/datasets. Like:

• what do we want to make available via session to microservices?
• what user data might we want to persist beyond a single session?
• do we want to allow microservices to write to the session (under their own key) and retrieve?
• what, if any, services do we provide via the gateway to allow microservices read/write to a central db (e.g. where we'd persist user profile data, or other persistent data that could span sessions but maybe not be specific only to a given service)?

[zenlex]

In the interest of following my own advice about not building stuff we don't need until we need it, here's where I'm thinking we'll start:

• Use Clerk for Auth and Session management and User Profile management for front end (including role management/verification)

• API gateway ingress will validate the JWT/Session from Clerk

I'm thinking I'll also add on to the gateway eventually:

• 'UserData' microservice built into the API gateway that hits a redis cache with persistence
  • Key = GH username, Val = JSON where root level keys are microservice names
  • Microservices can read/write to the userData service via requests to the gateway, gateway will manage tying user to service data (limited size data - large/complex datasets should be handled by backing services bound to the individual microservice)

This way we're managing microservice 'sessions' at the gateway level, and just tying them to users by getting the user from Clerk to give us the cache key instead of baking arbitrary microservice 'session' data into the user profile metadata.

To start I'll build in the routing part of that service but use clerk userprofile metadata for now to keep it simple, so services could read/write their own meta to a user profile, managed by the gateway.

Then if/when that gets unwieldy we can add the redis cache to move any microservices user meta out of clerk

The microservices shouldn't know anything about clerk directly essentially.

**Clerk user metadata is limited to 8kb

[zenlex]

I made a picture of my word salad 😅 @helmturner this make sense with your previous clerk experience and the wild west microservices architecture we're trying to keep open? (I left the front end authed UI flows ambiguous at this point as I think what I'm working on should be agnostic of that)

[helmturner]

LGTM, but when are you hoping to have this shipped? Are you trying for this by Tuesday?