[oncensher]

Had a similar journey recently. Started with Stack Auth, found it unusable in production due to extremely hard rate limits and bad performance even when not rate limited. Switched to WorkOS AuthKit, which works much better and supports useful enterprise features. But inclined to BetterAuth for new projects.

- Syncing external auth provider state with your user state is a bug center. It helps to keep as little state as possible in the auth provider, but there is still some. - Refreshing JWT access tokens every few minutes is another bug center and honestly there is no need to do this if you control your own auth. - WorkOS does not have a complete API. It is built on the assumption that you have one product per billing account and a fixed number of environments (staging, production, and they can give you another one if you ask support). You have to whitelist redirect and other URLs in the dashboard, and there doesn't seem to be an easy way for agents to do it.

Outsourcing auth does not make much sense IMO. The less you can split your state over multiple services the fewer problems you will have. Sometimes it is inevitable, like for payments, or if you need specialized databases for performance reasons. But for auth there is really no good reason if good libraries are available. To people who say that using a service will help you get started faster, none of the problems I hit with auth services had to do with having high scale -- most of them hit before I even launched.

[grinich]

Hi I'm the founder of WorkOS.

We're working on multi-app support. The large majority of our customers only have 1 app (ChatGPT, Claude, Cursor, etc.) but this isn't the case for developers building lots of side projects.

Also working on shipping an agent-friendly Dashboard. Stay tuned :)

Would love to hear any more feedback: [e-mail]

[mooreds]

> 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/

[oncensher]

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.

[mooreds]

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.