> I don’t think it’s great to see a truly free project get absorbed into a commercial venture.
Auth.js and NextAuth.js didn't seem to be in a healthy state. Work on NextAuth.js v5 began way back in May 2023.[1][2] NextAuth.js v5 was renamed to Auth.js in August 2023.[3] v5.0.0-beta.0 was released in October 2023.[4] Balázs Orbán, the main contributor to Auth.js and NextAuth.js, quit in January 2025.[5][6] v5 is still in beta after all this time. It never had a stable release.
That may be true but doesn't contradict the point of the parent commenter.
If Auth.js wanted to give up, that would be fine (although disappointing, since multiple options is always healthy, especially for something as critical as auth)
but this deal where they are "becoming part of BetterAuth" and recommending that new users use BetterAuth on the project README is concerning to me
Fair concern but I don’t think Auth.js was ever “truly free,” considering it was supported by many companies (big or small) including someone like Clerk even running ads on the docs site.
We started Better Auth with the vision of making high-quality auth (with simple abstractions, great docs, extensive set of features...) and make it accessible to everyone . It didn’t start as a commercial venture, at first it was a purely oss project I created. The reason it evolved into a commercial venture is that we saw new ways to make owning your auth even more accessible and scalable for companies.
The reason we’re bringing Auth.js under Better Auth is that the Auth.js team is moving on, and we don’t want the project to be abandoned, that would hurt trust in open-source auth as a whole. We’ve already seen that happen at smaller scaller with Lucia. If that weren’t the case, we’d actually benefit from Auth.js being deprecated, since we’re effectively the next most people would go for and we wouldn't have to take this risk and responsibilities.
Full disclosure, I work for FusionAuth, a commercial auth vendor which sponsored NextAuth.
People gotta eat. It's not like NextAuth didn't have commercial support from sponsors. I'm not privy to the details of how much money was involved, but you can read other comments about Clerk and Vercel and how they influenced the project.
Which will invariably lead to that open source project to become less and less useful if implemented separately from the SaaS platform. I’ve seen this game plan often enough.
Not outright crippled; just strategically neglected compared to the paid variant, unless it’s effectively useless without paying. And then Vercel steps in, buys the whole thing, and Better Auth becomes „Next.js“ first, ideally only fully effective on Vercel.
I would say once a company becomes vc funded, it will have some different priorities.
Although Deno seems to be working out good so far. They are providing value to the general JS eco system. And yes there is Deno deploy, but competent sysadmin and DevOP people will have no trouble running it on their own and scaling.
I don’t know the story, but I’m not surprised. I led an effort to switch my company to Auth0 recently and they’re… bad. They have very poor support for anything even barely outside of normal, and when things are working correctly they not very good.
But when you have a requirement to move to a third party SaaS service, I suppose Auth0 is maybe the best of a bad bunch.
Same, I felt like I was writing my own auth. They don’t seem to understand that we’re trying to get away from the complexity of auth. I’ve talked with their sales people but may as well be talking to a wall.
I interviewed for an SRE position at Auth0 years ago. My interviewer told me it was all held together by duct tape and prayers. I'm glad I didn't end up taking that position.
Sure, everyone ends up having a dim perspective on what they manage usually. But this was especially noticeable as he explained to me how many incidents they'd have daily, what their on-call was like, etc. In an world full of castles built with toothpicks and elmers glue this came off like it was built with wet cardboard and chewing gum.
I’ve seen a lot of talk about Auth0 but I want to put a callout to get a check on how folks feel about AWS cognito. I am Cognito vs Auth0 and I’d love to hear some real world experiences
This framework has made auth such a non-issue for me. The setup is easy and the usage is consistent framework to framework. So glad to see that they’re continuing to do well.
There are solutions out there for golang (FusionAuth, my employer, is one) but I think you are looking for one that integrates directly into an application the way that better-auth does (just like devise for rails, or Django's user model).
I'm working on something[0]. It actually supports Go, JS, and Rust (through the power of server-side WASM). Python and others are planned. It's unlikely to ever have all the features and polish of BetterAuth/OpenAuth, but I've been absolutely loving the DX for my projects that need auth.
I've seen this, and the fact that it's written in Go is kind of irrelevant if I have to manage an external service. I just want it to be simple like what other languages have.
Extremely complex and requires running another multiple services. I just want auth, I don't want to set up kubernetes to orchestrate all the components of Ory.
Rauch got a heck of a deal: hire NextAuth/Auth.js lead developer, use zombified Auth.js as a funnel to Clerk (a portco) with prominent CTAs on every page.
Then a replacement to zombified Auth.js pops up, but this time he's early so I would take bets on him having a slice. Use your closeness (via having hired the lead dev) to facilitate "absorbing" (read: erasing) the last dregs of Auth.js, successfully replacing it with a duopoly you've invested in both sides of!
Bonus: Having raised (which you helped with) they can't undercut Clerk on some shoestring budget.. they'll fail!
With Auth.js, I assume they control the database layer? I.e. can i supply my own functions for reading and writing to the DB, or I have to use their Kysely stuff?
I've been using Clerk and it seems fine. I'm sure there's some drama, because everything comes with drama, but I just want to get on with building stuff.
I am bummed by this, basically sounds like they’re sunsetting future development into Auth.js.
I tried Better Auth and it was not usable for what I wanted to do - I manage my own database schema and expose it through a permissioned GraphQL API. With Auth.js I just needed to implement a documented set of functions with specified input and output types, like creating users, storing tokens, etc. - however I wanted to - and then it all just worked with my own custom GraphQL API as the backend.
But with Better Auth it’s all insanely general, where the data types are “whatever a particular plugin wants” meaning the any type in TypeScript; and the only thing you can do is delegate responsibility for design of database schemas and execution of data migrations to whatever plugin developers decide you need for the particular authentication methods you support.
Way beyond the pale for an auth library in my opinion, I thought I was dumb and just didn’t understand the library but when I asked the community about it, they told me that’s by design - plugins determine their own data model. This isn’t a matter of me having a weird use case with the whole GraphQL thing, I can’t imagine anyone who takes their data modeling/security seriously would be fine with delegating that kind of control to plugin developers.
(Yes I know you can make your own adapters, but the interface for that is literally “implement a general purpose SQL-like query executor” where the models that you’re querying/mutating are arbitrary strings - so basically no control over your schema. It literally just takes in a code: string value for eval’ing your migrations! Insane! [1])
When I saw the announcements before about Better Auth, emphasizing not that it was innovative nor technically good in any way, but instead focusing on the fact that its developer was self-taught and has only been coding for a few years [2], I tried to restrain myself from assuming anything about how it might be designed, especially since it seems everyone was hyping it up… but I’m not so confident my prejudices were totally wrong.
I guess this is marginally better than the status quo where Auth.js was basically unmaintained and not being developed further at all. Which is to say, the state of open source auth libraries in JS is surprisingly poor.
1. We won’t sunset Auth.js unless we’re confident that anyone currently using it can migrate to Better Auth without any issues, which is quite difficult right now. So we don’t expect to do that anytime soon and chances are we will never require everyone to migrate.
2. The features we offer through plugins don’t exist in NextAuth, so that shouldn’t be a problem. You can use the core library for almost all of NextAuth’s features, and we provide most plugins first-party. Of course, you can choose not to use a plugin, write your own, copy and modify one, or only use the first-party ones we provide. We handle the database so you can own your auth without writing the logic yourself.
3. Auth.js hasn’t been actively maintained for a while. Our main reason for bringing it under Better Auth was to avoid a sudden deprecation, as that would directly harm the open-source auth ecosystem by eroding trust. Something we’ve already seen happen on a smaller scale with Lucia Auth.
I guess what I’m saying is that I think the part about delegating databases to Better Auth relegates it to being only useful for throwaway projects and companies with low quality technical vision, and there is no actively developed alternative that can do any better.
Patches are better than nothing but I am disappointed with the state of auth in JS.
NextAuth has supported delegating your db for years, companies like cal.com, deel.com and many others use that directly (not just for stateless jwt). I don’t really see the difference here, except that we handle more for you. And of course, If you don’t want to delegate your database, you can keep using NextAuth with stateless auth and we plan to add support for that as well.
There are already many companies with lots of users and revenue using Better Auth from simple auth setups to organizations, billing and what not.
If your question is more about whether we should allow database adapters to be written directly by developers (some people ask that) that’s just not realistic at the scale of what we handle. No one is realistically going to write hundreds of queries manually
Sorry for being dismissive - but I think that’s just a failure of imagination.
Does every app using an adapter for Better Auth need to implement every plugin’s many thousands of operations, even if they’re only using basic functionality and a handful of operations?
Auth.js differed in that you could let them handle it if you’re doing your low impact side product, but once you did care you can opt out. You’re telling me that Better Auth knows better what you need than you do, and so giving you the option to opt out would just be too onerous for you to decide if you want to do it or not.
Why couldn’t Better Auth plugins individually declare what they need and let you implement those functions as you need them?
For what it’s worth my company also makes money in a sensitive industry, Auth.js did everything we need regarding authentication (and we just use other things entirely for billing/etc, which arguably is much more modular), and we only had to implement like 8 functions that took a day and has worked since we started a few years ago. Probably would take me an hour or two today thanks to AI.
Honestly I’m fine with Better Auth taking its stance, but basically saying “you should use Better Auth unless you have this one random fad technical issue, why would you need any alternative like Auth.js??” while saying that there will only be security patches; and no real probable alternative I can think of; and that stance is basically a non starter for what I believe to be a large set of use cases, rubbed me wrong.
I’ll take patches over nothing, but that doesn’t invalidate my feeling that auth in JS is in a sorry state and this isn’t making it better as far as my concerns go. Anyway who am I to talk, I’m not going to make an alternative regardless.
> Does every app using an adapter for Better Auth need to implement every plugin’s many thousands of operations, even if they’re only using basic functionality and a handful of operations?
No, and actually if you really really wanna override the core database calls, we have a way to do so. You just need to write a hook or custom plugin to override the `internalAdapter`.
> Auth.js did everything we need regarding authentication
I don’t think this is true. Any sufficiently complex project has had to add a lot of customization and logic on top of NextAuth to make it even somewhat complete. I was one of those people, which is exactly why I started Better Auth.
> auth in JS is in a sorry state
That’s been the case long before we started Better Auth, it’s the reason we built it in the first place. I hope we’ll be able to change that narrative. But I think what we already have is something other ecosystems can only wish for. Some references:
Now, this response was "not on my bingo card" as the youths say. I find it surprising that Swift would come up on a discussion about JavaScript auth libraries.
Can you tell us more about what you are looking for?
Sorry it was a bit off-topic (not related to Auth.js).
I'm specifically asking about Better-Auth, as I'd love to use it in an iOS app but the client library is all JS. I'd even consider writing my own client library, but there is virtually no documentation on how to do so.
Part of it is that most of the libraries that came before we’re tightly coupled to a particular framework that itself went out of fashion, like Passport and Express, which is a problem because frameworks themselves have been moving in and out of fashion very rapidly; or are coupled with service offerings from vendors, like Auth0.
Auth.js is actually one of the first attempts that tries to be framework and vendor agnostic while still including a good deal of the batteries you need to make a full authentication system, which they only recently did, as they were originally tied to next JS like every other library in the graveyard of authentication libraries.
If you just want to specifically do an OAuth handshake or salt and hash a password or produce a JWT, those libraries are all rock solid. But a full batteries included framework and vendor agnostic solution hasn’t really existed until recently.
Same. I've personally never had issues with any auth packages, granted I've never used auth0. Personally, they all seem quite similar, especially in the react world.
Anything that can help me utilize oauth standards is fine to me.
It’s not that auth is unsolved in other languages/frameworks, but it’s often way too complex or configuration-heavy. If adding passkey support to my app is going to take 2 hours, that’s two hours I’m spending away from building my core product. For smaller projects, that’s not time that I could afford.
For example, if I want to add passkeys to my .NET CORE app, this is the guide Microsoft provides:
For some projects, the flexibility of other solutions might be needed. But for ease-of-use and development speed, better-auth has been a clear winner for me.
Excuse me, incoming contrarian!
learn.microsoft, is for learning about the concepts as well as the practical applications. Also for user facing security, wouldn't you want all the knowledge available to you? Much easier to find the foot guns in these kinds of situations.
Better Auth has raised $5M. I don’t think it’s great to see a truly free project get absorbed into a commercial venture.
> I don’t think it’s great to see a truly free project get absorbed into a commercial venture.
Auth.js and NextAuth.js didn't seem to be in a healthy state. Work on NextAuth.js v5 began way back in May 2023.[1][2] NextAuth.js v5 was renamed to Auth.js in August 2023.[3] v5.0.0-beta.0 was released in October 2023.[4] Balázs Orbán, the main contributor to Auth.js and NextAuth.js, quit in January 2025.[5][6] v5 is still in beta after all this time. It never had a stable release.
[1] https://github.com/nextauthjs/next-auth/pull/7443
[2] https://github.com/nextauthjs/next-auth/discussions/8487
[3] https://github.com/nextauthjs/next-auth/commit/a996ab57e8ffc...
[4] https://www.npmjs.com/package/next-auth/v/5.0.0-beta.0
[5] https://github.com/nextauthjs/next-auth/commits?author=balaz...
[6] https://x.com/balazsorban44/status/1943635445235040488
That may be true but doesn't contradict the point of the parent commenter.
If Auth.js wanted to give up, that would be fine (although disappointing, since multiple options is always healthy, especially for something as critical as auth)
but this deal where they are "becoming part of BetterAuth" and recommending that new users use BetterAuth on the project README is concerning to me
Fair concern but I don’t think Auth.js was ever “truly free,” considering it was supported by many companies (big or small) including someone like Clerk even running ads on the docs site.
We started Better Auth with the vision of making high-quality auth (with simple abstractions, great docs, extensive set of features...) and make it accessible to everyone . It didn’t start as a commercial venture, at first it was a purely oss project I created. The reason it evolved into a commercial venture is that we saw new ways to make owning your auth even more accessible and scalable for companies.
The reason we’re bringing Auth.js under Better Auth is that the Auth.js team is moving on, and we don’t want the project to be abandoned, that would hurt trust in open-source auth as a whole. We’ve already seen that happen at smaller scaller with Lucia. If that weren’t the case, we’d actually benefit from Auth.js being deprecated, since we’re effectively the next most people would go for and we wouldn't have to take this risk and responsibilities.
Not only is Auth.js truly free, it's truly abandoned.
Exactly
Full disclosure, I work for FusionAuth, a commercial auth vendor which sponsored NextAuth.
People gotta eat. It's not like NextAuth didn't have commercial support from sponsors. I'm not privy to the details of how much money was involved, but you can read other comments about Clerk and Vercel and how they influenced the project.
I wrote more about the difficulties of OSS business models here a few years ago: https://www.mooreds.com/wordpress/archives/3438
while i agree, in this case at least it looks like the money raised is for a future SaaS auth solution built on top of the open-source project
Which will invariably lead to that open source project to become less and less useful if implemented separately from the SaaS platform. I’ve seen this game plan often enough.
Good for them, bad for the rest of us.
> I’ve seen this game plan often enough.
I probably haven't been around as long as you. Could you provide an example of one that comes to mind?
Auth.js: Vercel hired the lead dev and it stopped improving, leading to better-auth
Isn’t Vercel’s CEO an investor of Clerk? A direct competitor to all these FOSS auth libraries.
Yes, see: https://news.ycombinator.com/item?id=45393382
Now better-auth had raised $5M so they can't undercut Clerky by too much or they'll fail
Time for Vercel to hire the lead dev of Better Auth next?
I bet Vercel buys better-auth and makes it a first party auth solution
thebestmotherfuckingauth.com
Elasticsearch
Redis
Mongo
Bitnami
Gitlab
SourceGraph
Cockroach
prisma
We all know how this ends. The open source project ends up being crippled to the point it's no longer useful.
Not outright crippled; just strategically neglected compared to the paid variant, unless it’s effectively useless without paying. And then Vercel steps in, buys the whole thing, and Better Auth becomes „Next.js“ first, ideally only fully effective on Vercel.
I would say once a company becomes vc funded, it will have some different priorities.
Although Deno seems to be working out good so far. They are providing value to the general JS eco system. And yes there is Deno deploy, but competent sysadmin and DevOP people will have no trouble running it on their own and scaling.
Thing is though, where will they get their returns?
consulting? deploy hosted? (why not just use cf workers/vercel/etc.)
if there was a way for the industry to support these things by everyone pitching in, that'd probably be the best but I don't see that happening soon
[dead]
> Chances are, if you’ve used ChatGPT, Google Labs, Cal.com or a million other websites, you’ve already interacted with Auth.js.
I missed OpenAI migrating away from auth0. They must have been one of their largest customers - anybody know the story?
I don’t know the story, but I’m not surprised. I led an effort to switch my company to Auth0 recently and they’re… bad. They have very poor support for anything even barely outside of normal, and when things are working correctly they not very good.
But when you have a requirement to move to a third party SaaS service, I suppose Auth0 is maybe the best of a bad bunch.
Auth0 went downhill after being acquired by Okta.
And I guess it's also EXPENSIVE.
Same, I felt like I was writing my own auth. They don’t seem to understand that we’re trying to get away from the complexity of auth. I’ve talked with their sales people but may as well be talking to a wall.
I interviewed for an SRE position at Auth0 years ago. My interviewer told me it was all held together by duct tape and prayers. I'm glad I didn't end up taking that position.
To be fair that's the views of SREs everywhere
Sure, everyone ends up having a dim perspective on what they manage usually. But this was especially noticeable as he explained to me how many incidents they'd have daily, what their on-call was like, etc. In an world full of castles built with toothpicks and elmers glue this came off like it was built with wet cardboard and chewing gum.
And as a software dev they’re not wrong lol
You can probably infer some from their Ory case study: https://www.ory.sh/case-studies/openai
I’ve seen a lot of talk about Auth0 but I want to put a callout to get a check on how folks feel about AWS cognito. I am Cognito vs Auth0 and I’d love to hear some real world experiences
They migrated SSO/SAML to WorkOS, and consumer auth to forked open source.
Ory also claims they are used by openai, so I guess they built their solution on Ory services + better-auth?
"anybody know the story?"
what story??? chance are if you are planet scale enterprise, you are big enough to maintain or create or fork popular custom OSS auth themselves
I mean can you imagine the cost ??? also the effect of third party that hold your entire user data
This framework has made auth such a non-issue for me. The setup is easy and the usage is consistent framework to framework. So glad to see that they’re continuing to do well.
I really wish there was such an easy off-the shelf auth solution for Go
Agreed.
There are solutions out there for golang (FusionAuth, my employer, is one) but I think you are looking for one that integrates directly into an application the way that better-auth does (just like devise for rails, or Django's user model).
I'm not aware of any such library for golang. This reddit thread might be helpful: https://www.reddit.com/r/golang/comments/1le9q65/is_there_a_... with some options to evaluate.
I'm working on something[0]. It actually supports Go, JS, and Rust (through the power of server-side WASM). Python and others are planned. It's unlikely to ever have all the features and polish of BetterAuth/OpenAuth, but I've been absolutely loving the DX for my projects that need auth.
[0]: https://github.com/lastlogin-net/decent-auth
https://github.com/authelia/authelia?
I've seen this, and the fact that it's written in Go is kind of irrelevant if I have to manage an external service. I just want it to be simple like what other languages have.
https://github.com/ory/kratos ?
Extremely complex and requires running another multiple services. I just want auth, I don't want to set up kubernetes to orchestrate all the components of Ory.
This is funny to me because when someone asked re: Better Auth "better than what?" my off-the-cuff response was "better than Auth.js" and here we are.
Used and loved both products. Great to see they are joining forces.
They're not. Better Auth is only 'maintaining' Auth.js to push people towards Better Auth.
Rauch got a heck of a deal: hire NextAuth/Auth.js lead developer, use zombified Auth.js as a funnel to Clerk (a portco) with prominent CTAs on every page.
Then a replacement to zombified Auth.js pops up, but this time he's early so I would take bets on him having a slice. Use your closeness (via having hired the lead dev) to facilitate "absorbing" (read: erasing) the last dregs of Auth.js, successfully replacing it with a duopoly you've invested in both sides of!
Bonus: Having raised (which you helped with) they can't undercut Clerk on some shoestring budget.. they'll fail!
The prophecy continues :) https://news.ycombinator.com/item?id=40321997
Great news for dev simplicity, Better Auth is just... better.
With Auth.js, I assume they control the database layer? I.e. can i supply my own functions for reading and writing to the DB, or I have to use their Kysely stuff?
I've been using Clerk and it seems fine. I'm sure there's some drama, because everything comes with drama, but I just want to get on with building stuff.
I haven't tried Clerk, but if the money spent actually makes things easier, then it seems like a good fit for certain projects.
Better Auth didn't take more than an hr to setup in my repo, which is already pretty bare-bones to begin with.
I am bummed by this, basically sounds like they’re sunsetting future development into Auth.js.
I tried Better Auth and it was not usable for what I wanted to do - I manage my own database schema and expose it through a permissioned GraphQL API. With Auth.js I just needed to implement a documented set of functions with specified input and output types, like creating users, storing tokens, etc. - however I wanted to - and then it all just worked with my own custom GraphQL API as the backend.
But with Better Auth it’s all insanely general, where the data types are “whatever a particular plugin wants” meaning the any type in TypeScript; and the only thing you can do is delegate responsibility for design of database schemas and execution of data migrations to whatever plugin developers decide you need for the particular authentication methods you support.
Way beyond the pale for an auth library in my opinion, I thought I was dumb and just didn’t understand the library but when I asked the community about it, they told me that’s by design - plugins determine their own data model. This isn’t a matter of me having a weird use case with the whole GraphQL thing, I can’t imagine anyone who takes their data modeling/security seriously would be fine with delegating that kind of control to plugin developers.
(Yes I know you can make your own adapters, but the interface for that is literally “implement a general purpose SQL-like query executor” where the models that you’re querying/mutating are arbitrary strings - so basically no control over your schema. It literally just takes in a code: string value for eval’ing your migrations! Insane! [1])
When I saw the announcements before about Better Auth, emphasizing not that it was innovative nor technically good in any way, but instead focusing on the fact that its developer was self-taught and has only been coding for a few years [2], I tried to restrain myself from assuming anything about how it might be designed, especially since it seems everyone was hyping it up… but I’m not so confident my prejudices were totally wrong.
I guess this is marginally better than the status quo where Auth.js was basically unmaintained and not being developed further at all. Which is to say, the state of open source auth libraries in JS is surprisingly poor.
[1] https://github.com/better-auth/better-auth/blob/f6cbdcc84ee5...
[2] https://techcrunch.com/2025/06/25/this-self-taught-ethiopian...
1. We won’t sunset Auth.js unless we’re confident that anyone currently using it can migrate to Better Auth without any issues, which is quite difficult right now. So we don’t expect to do that anytime soon and chances are we will never require everyone to migrate.
2. The features we offer through plugins don’t exist in NextAuth, so that shouldn’t be a problem. You can use the core library for almost all of NextAuth’s features, and we provide most plugins first-party. Of course, you can choose not to use a plugin, write your own, copy and modify one, or only use the first-party ones we provide. We handle the database so you can own your auth without writing the logic yourself.
3. Auth.js hasn’t been actively maintained for a while. Our main reason for bringing it under Better Auth was to avoid a sudden deprecation, as that would directly harm the open-source auth ecosystem by eroding trust. Something we’ve already seen happen on a smaller scale with Lucia Auth.
I guess what I’m saying is that I think the part about delegating databases to Better Auth relegates it to being only useful for throwaway projects and companies with low quality technical vision, and there is no actively developed alternative that can do any better.
Patches are better than nothing but I am disappointed with the state of auth in JS.
NextAuth has supported delegating your db for years, companies like cal.com, deel.com and many others use that directly (not just for stateless jwt). I don’t really see the difference here, except that we handle more for you. And of course, If you don’t want to delegate your database, you can keep using NextAuth with stateless auth and we plan to add support for that as well.
There are already many companies with lots of users and revenue using Better Auth from simple auth setups to organizations, billing and what not.
If your question is more about whether we should allow database adapters to be written directly by developers (some people ask that) that’s just not realistic at the scale of what we handle. No one is realistically going to write hundreds of queries manually
Sorry for being dismissive - but I think that’s just a failure of imagination.
Does every app using an adapter for Better Auth need to implement every plugin’s many thousands of operations, even if they’re only using basic functionality and a handful of operations?
Auth.js differed in that you could let them handle it if you’re doing your low impact side product, but once you did care you can opt out. You’re telling me that Better Auth knows better what you need than you do, and so giving you the option to opt out would just be too onerous for you to decide if you want to do it or not.
Why couldn’t Better Auth plugins individually declare what they need and let you implement those functions as you need them?
For what it’s worth my company also makes money in a sensitive industry, Auth.js did everything we need regarding authentication (and we just use other things entirely for billing/etc, which arguably is much more modular), and we only had to implement like 8 functions that took a day and has worked since we started a few years ago. Probably would take me an hour or two today thanks to AI.
Honestly I’m fine with Better Auth taking its stance, but basically saying “you should use Better Auth unless you have this one random fad technical issue, why would you need any alternative like Auth.js??” while saying that there will only be security patches; and no real probable alternative I can think of; and that stance is basically a non starter for what I believe to be a large set of use cases, rubbed me wrong.
I’ll take patches over nothing, but that doesn’t invalidate my feeling that auth in JS is in a sorry state and this isn’t making it better as far as my concerns go. Anyway who am I to talk, I’m not going to make an alternative regardless.
> Does every app using an adapter for Better Auth need to implement every plugin’s many thousands of operations, even if they’re only using basic functionality and a handful of operations?
No, and actually if you really really wanna override the core database calls, we have a way to do so. You just need to write a hook or custom plugin to override the `internalAdapter`.
> Auth.js did everything we need regarding authentication
I don’t think this is true. Any sufficiently complex project has had to add a lot of customization and logic on top of NextAuth to make it even somewhat complete. I was one of those people, which is exactly why I started Better Auth.
> auth in JS is in a sorry state
That’s been the case long before we started Better Auth, it’s the reason we built it in the first place. I hope we’ll be able to change that narrative. But I think what we already have is something other ecosystems can only wish for. Some references:
- https://www.youtube.com/watch?v=dNY4FKXwTsM - https://www.reddit.com/r/golang/comments/1le9q65/is_there_a_...
removed the notice about vercel like 3 hours after the announcement https://github.com/nextauthjs/next-auth/commit/9215909ffd7ae...
Wonder when they are going to remove the sponsors list?
https://next-auth.js.org/sponsors
Labuba driven development
Please add support for Swift!
Now, this response was "not on my bingo card" as the youths say. I find it surprising that Swift would come up on a discussion about JavaScript auth libraries.
Can you tell us more about what you are looking for?
Sorry it was a bit off-topic (not related to Auth.js).
I'm specifically asking about Better-Auth, as I'd love to use it in an iOS app but the client library is all JS. I'd even consider writing my own client library, but there is virtually no documentation on how to do so.
Thanks for explaining.
I saw the same sentiment for golang in other comments.
No real suggestions for ya, sorry!
Wow this is such a natural fit! Used both products, better auth is a clear successor. What a great path forward
[dead]
[dead]
[dead]
only in javascript where auth is such a big issue.
in rails you can use the rails 8 auth or a better alternative authentication-zero. before it was devise.
java - spring security, shiro etc. but just complex things.
alternatively - use services like fusionAuth
Part of it is that most of the libraries that came before we’re tightly coupled to a particular framework that itself went out of fashion, like Passport and Express, which is a problem because frameworks themselves have been moving in and out of fashion very rapidly; or are coupled with service offerings from vendors, like Auth0.
Auth.js is actually one of the first attempts that tries to be framework and vendor agnostic while still including a good deal of the batteries you need to make a full authentication system, which they only recently did, as they were originally tied to next JS like every other library in the graveyard of authentication libraries.
If you just want to specifically do an OAuth handshake or salt and hash a password or produce a JWT, those libraries are all rock solid. But a full batteries included framework and vendor agnostic solution hasn’t really existed until recently.
Why is auth "such a big issue" in JS? I've used a number of solutions but haven't had big issues with them.
Same. I've personally never had issues with any auth packages, granted I've never used auth0. Personally, they all seem quite similar, especially in the react world.
Anything that can help me utilize oauth standards is fine to me.
It’s not that auth is unsolved in other languages/frameworks, but it’s often way too complex or configuration-heavy. If adding passkey support to my app is going to take 2 hours, that’s two hours I’m spending away from building my core product. For smaller projects, that’s not time that I could afford.
For example, if I want to add passkeys to my .NET CORE app, this is the guide Microsoft provides:
https://learn.microsoft.com/en-us/aspnet/core/security/authe...
Contrast that to better-auth (which is 7 lines of code total in server changes, and virtually no change to client API usage):
https://www.better-auth.com/docs/plugins/passkey
For some projects, the flexibility of other solutions might be needed. But for ease-of-use and development speed, better-auth has been a clear winner for me.
Excuse me, incoming contrarian! learn.microsoft, is for learning about the concepts as well as the practical applications. Also for user facing security, wouldn't you want all the knowledge available to you? Much easier to find the foot guns in these kinds of situations.
It’s Microsoft. Did you expect less than 30 pages of useless techno-babble?
In case if you don't know, Auth.js is not a frontend-only framework. It uses a backend server to make it secure.
So it basically has no difference from the alternatives you mentioned.
> make it secure
It's convenient, I'll give them that. Secure? https://projectdiscovery.io/blog/nextjs-middleware-authoriza...
Well, that has nothing to do with JS itself though.