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...
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
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.
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
Good for them, bad for the rest of us.
I missed OpenAI migrating away from auth0. They must have been one of their largest customers - anybody know the story?
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.
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
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.
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
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...
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.
Patches are better than nothing but I am disappointed with the state of auth in JS.
Better Auth didn't take more than an hr to setup in my repo, which is already pretty bare-bones to begin with.
Can you tell us more about what you are looking for?
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.
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
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.
Anything that can help me utilize oauth standards is fine to me.
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.
So it basically has no difference from the alternatives you mentioned.
It's convenient, I'll give them that. Secure? https://projectdiscovery.io/blog/nextjs-middleware-authoriza...
