Reminder - KeyCloak was donated to CNCF so a safe choice

https://www.keycloak.org

https://www.cncf.io/blog/2023/04/11/keycloak-joins-cncf-as-a...

how is this related to better auth ? In my understanding, keycloak and better auth are fundamentally different. I would compare keycloak more with Ory for example.

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.

Probably the first time reading that the Ory stack is unfinished! Sorry you had a frustrating time, but there's 10 years of development and many happy customers + adopters who see it differently! Polis / Boxy still works as before, we didn't gut or take away anything.

Open source development needs to be paid by someone - most of the time people complaining about paying for software are working themselves (for money!) in some company making huge bucks, or looking up to "successful (as in money) tech leaders".

For Ory, B2B login is a good value differentiator, because it's required by companies selling to other companies meaning they can spend some money on licenses to further develop software.

Ory powers the largest technology providers, and super small solo projects. It's robust, stable, Apache2 licensed. It's the best CIAM tech out there that's free (!!).

In the end, everyone is entitled to their opinion but the "open source can't make money" train is honestly a bottom tier opinion and I'm tired of reading it on HN, probably written by people making $100K+ a year for writing software and using open source daily (without paying a dime).

It's like the people complaining that Wikipedia is collecting too many donations, while they cheer on Apple or Anthropic or whoever raking in billions of dollars.

Somehow, only if it's open source / non profit it's bad to make money. If it's proprietary nobody gives a damn. Says a lot about society.

I really want to love KeyCloak. I've had really bad experiences with weird uptime bugs and crash loops that kept me from giving it an honest retry over the last couple years.

It also really shows its age, imo. The interface is clunky, roles and groups having overlapping responsibilities is confusing, making custom UIs for it makes me feel ancient, etc.

I really can't complain though. There is simply no alternative that's as open atm. It's also not easy to make one ( I tried :( ).

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.

Is keycloak still the only real game in town for open source authorization (not authentication; that part is totally fungible)?

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/

Congrats BetterAuth! It was the system I was considering before I rolled my own auth system around the passwordless concepts of: OPT + Passkeys + Google login. It is quite nice and simple and I've ported it to 3 separate projects now just via LLM:

https://ben3d.ca/blog/passwordless-login-system

If you are building a user system with a database already, adding passwordless auth is easy.

Bereket Here

the team at Vercel has been my biggest inspiration and always reflected many of the reasons we started working on Better Auth. This would allow us to focus more on what made better-auth great in the first place It hasn't even been 2 years since we started but thank you everyone from the open-source community for helping us make an impact in short amount of time. There is a lot to do to improve on open source auth and im really excited to be back focusing full time on building

You're saying that BetterAuth will remain 100% free and open source, will continue to be maintained, and unlocked from Vercels ecosystem?

You are asking the wrong person.

I used Better Auth for my mobile app backend. It works okayish. My biggest complaints are the OpenAPI specification gets little care, as it mainly caters for JS frontend, and breaking changes in patch version are more common than most packages.

Bummed. Vercel is not a great steward of open source. Happy that Bereket got an exit, though.

So, it's just a matter of time until they destroy this project in favour of their cloud interests. Such a shame, it is (was) a nice open source project.

can Vercel give any assurance that they won’t add a reliance on their closed-source cloud offering for the package? especially given their ownership of next-auth too

i really loved better-auth’s DX but the nature of their database adapters means it’s relatively easy to switch over to another provider/library

From what I remember, next-auth is kind of dead and Better Auth developers have been maintaining security of next-auth for some time now. (or was it Vercel that did the maintaining?)

Better Auth is the go-to solution for many people using Nextjs, so it makes sense that Vercel puts some effort in maintaining it.

I have never had issues running Nextjs in regular containers, it is just a good open source solution, I don't see why it would be any different with Better Auth.

Better Auth is great, I use it for all my projects. Congrats to the team!

Congrats to Better Auth. I'm in the auth space and see all kinds of things.

Anything that makes it easier for developers to build secure applications is a win!

Uggggg I just implemented Better Auth for our new product - time to start looking for backup plans. I used to be a huge Vercel fanboy but everything they have done in the last few years turns into a complicated mess.

Silent execution of tremor was a pain in the ass trying to upgrade to nextjs 15 / react 19: https://github.com/tremorlabs/tremor/issues/148

Love better-auth, and congrats to the team!

Ah, here we go again.

Glad I decided to roll my own auth rather then using some library. I had a feeling that eventually they will join Vercel.

Yeah, we rolled our own auth as well. Everybody says you shouldn’t, it’s a risk, etc etc.

but to me that’s less risk than our auth getting bought by somebody whose business goals don’t necessarily align with mine.

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.

I prefer to maintain my code, tailored for my need, than maintaining a massive library that has support for every authentication method there is, while trying to be as generic as possible and fit every business.

This is amazing although I would really like for them to explore filling the backend gaps. An acquisition of Trigger.dev or Inngest would be the obvious move and nobody would be surprised. Thoughts?

I was wondering when that would happen, it was meant to be since the beginning

I nearly considered using them recently. So glad I dodged the bullet!

Ain't nobody buying Jose, yet

Umm.. so what did you end up using?

Auth is not hard to roll yourself. Crypto: don't do it. Auth? Easy peasy.

Oh man, it really depends(tm). If you are building a small internal app, sure, but you'd often still be better off leveraging a social provider or employee directory.

I work in the auth space (for FusionAuth) and we run into plenty of folks that started out rolling auth themselves. Just username and password right? A bit of hashing, salting and leveraging a built-in crypto library.

But then you need to add account recovery. And then MFA. And then registration. And then progressive registration. And then webhook integration. And then passkeys. And then SAML integration. And the delegated SAML setup. And then and then and then.

You're distracted from your core application by feature requests for your login system.

You have lots of options nowadays. Use a library provided by your framework (Rails, Spring, and Django have them), use a tool like Better Auth, use a third party system like FusionAuth or Auth0. But don't build undifferentiated functionality that impacts your user experience.

PS Of course, where I stand depends on where I sit, but I firmly believe that you should not build an auth system the same way you should not build a database.

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.

Unfortunately its a common misconception, it feels easy, however auth is a lot more harder to do it right, specially when it comes to recovery. A simple example, protocol like TOTP (time based OTP) uses the concept of shared secret and almost every implementation stores the secret as it is in their databases

Correct! As a Ruby dev, I started using rodauth and never looked back! https://rodauth.jeremyevans.net/

Rolling auth by yourself is very messy. Storing tokens correctly, rotating and using correct tokens, with correct parameters and so on. Endless footguns.

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