Hacker News new | ask | show | jobs
by oncensher 35 days ago
I think depending on how much integration you want, either option 1 or treating the multiple applications as a single application that can do multiple things could be good options. Also, option 2 could still avoid having to worry about your auth service going down or rate limiting you. And you could avoid JWT headaches.

Perhaps there is also an option 4, which is option 1 plus a shared user information database for things like Stripe account, profile picture, etc. That is more complex obviously, but it would still solve the issues I had with WorkOS. In particular, I think it would mostly solve "syncing external auth provider state with your user state is a bug center." In particular, the awkwardness around sequencing of account creation and deletion would largely go away because that would be managed as in 1, and the extra shared information would be just that. (But maybe you would want to delete it if the user deletes all their accounts?) And you wouldn't be forced to use webhooks to get updates to shared user state. You could put it in a shared Convex database, for instance, or use some other solution of your choosing.

1 comments

Yeah, I see two common patterns with people using an external auth server.

1. store everything user related in there, rely on APIs or syncing if the application needs user attributes

2. store nearly nothing in there, just credentials, MFA, account recovery info and anything else related to authentication. All profile data is stored in each app

Both can work, they just have tradeoffs.