Keycloak and Better Auth aren't as fundamentally different as you may think! Better auth supports authn/z, being an identity _source_, being an identity provider, being an OIDC/SSO provider (so others can login using better auth), rbac, SAML/SCIM, and a ton more. It's actually really powerful! Most folks found better auth as an alternative to next-auth/auth.js - but better auth does a lot more than those.

(some of those features are enterprise only)

It's a good reminder, because in the auth landscape I wish I had just picked up Keycloak and stuck with it. Commercial auth is a bad value proposition and not the kind of infrastructure where you want to have acquisition churn happening often.

The self-hosted space is another headache. I wasted so much time trying to make smaller self-hosted auth solutions work, since Keycloak has a reputation for being heavyweight.

I looked into the Ory stack extensively trying to actually use it as advertised for self-hosted / open-source auth. It's aggressively gimped and its SSO features are emphatically _not_ open-source and are gated behind licensing, with no way to find out until you're actually running it.

It's also just unfinished. Their "stack" is a lot of cobbled-together Go mixed with incompletely rebranded acquisitions like SAML Jackson (now "Polis"), which they managed to gut so completely it went from a best-in-class OSS library to unusable.

Showing its age is also a pretty significant plus, for such a critical part of one's infrastructure. That means it's been beat up on and run through the ringer for a decade plus at this point and had lots of chances to fix CVEs and other bugs. Not to say there won't be more, but being older and time-proven for an IdP is a major positive.

If you're willing to take the pain of setting up an actual authz model, I've found OpenFGA^ to be really nice. We used it to set up some pretty complex authz involving cross-agent/user/org creation and sharing of data. It's not _simple_, but it is effective.

It's Apache 2.0 and a CNCF incubating project.

[^] https://openfga.dev/

You are asking the wrong person.

The data lives in your server, everything is yours, if that happens, you just fork or write your own. Not sure what writing yourself first buys here.

why not instead fork repo just in case but still use better auth until proven wrong? In case they go evil you just build from you forked one. At that point you would still have to either maintain your own auth or better auth fork.

With current AI your agents probably still will be better with maintaining a fork. Auth libs have pretty limited API surfaces comparing to e.g. ui frameworks.

This is kinda like the ORM vs no-ORM argument. I think that off-the-shelf auth will accelerate your development for sure (like an ORM) but eventually, you are going to feel constrained by the framework/tool you are using. You will need to work around it. You will find that using it 'correctly' results in poor performance, and so you deviate here and there. Pretty soon you tell yourself, "man I should have just used SQL" or "man, I should have just rolled my own auth". At least ~20 years of software dev has taught me this.

For an MVP or a prototype, I think it's okay to use an off-the-shelf tool. For something serious that will have long-term legs, I would do it myself. I hear all of your concerns and arguments and agree there are a lot of footguns. But again, having spent the better part of my adult life using and interfacing with these tools, I have an innate understanding of how to model auth correctly (separate it from the user, separate users from an 'org' or 'team' entity, etc).

You said it though, 'it depends' is really the right answer here.

also the conseqeunces of implementing it badly from scratch don't make sense if you can use battle-tested solution

depends what LLM you are using but most frontier models have seen almost every github/doc/best practices its very hard to get something like supabase/lovable type of mess unless you purposely prompt it to be bad without much inner knowledge but even then it is rectifiable with the right prompts