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.
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
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.
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.
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?
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.
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.
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.
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
Rolling auth by yourself is very messy. Storing tokens correctly, rotating and using correct tokens, with correct parameters and so on. Endless footguns.
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.
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
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.
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.
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!
Love better-auth, and congrats to the team!
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?
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
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 was wondering when that would happen, it was meant to be since the beginning
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.
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
Rolling auth by yourself is very messy. Storing tokens correctly, rotating and using correct tokens, with correct parameters and so on. Endless footguns.
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?