|
|
|
|
|
|
by mooreds
48 days ago
|
|
|
> Outsourcing auth does not make much sense IMO. The less you can split your state over multiple services the fewer problems you will have. I agree with the general principle. Fewer moving pieces make for more stable applications ("choose boring technology"[0]). However, I was wondering what you do when you have more than one application that the same userbase wants to access. I can see 3 options: 1. make them register/have credentials for each application (not a great user experience) 2. use a standalone auth server and deal with the increased complexity 3. pick one of your applications to 'own auth' and have the other applications delegate to it. congrats, you've just invented a standalone auth server that is coupled to one of your apps What am I missing? 0: https://boringtechnology.club/ |
|
|
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.