Auth.js is now part of Better Auth
31–40 of 87 posts
Re: Auth.js is now part of Better Auth
#32Better Auth has raised $5M. 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...
Re: Auth.js is now part of Better Auth
#33Earlier quoted context omitted.
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?
Re: Auth.js is now part of Better Auth
#34Used and loved both products. Great to see they are joining forces.
Re: Auth.js is now part of Better Auth
#35Used 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.
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
Re: Auth.js is now part of Better Auth
#36Earlier quoted context omitted.
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.
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.
Re: Auth.js is now part of Better Auth
#37Re: Auth.js is now part of Better Auth
#38I really wish there was such an easy off-the shelf auth solution for Go
Re: Auth.js is now part of Better Auth
#39I 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...
Re: Auth.js is now part of Better Auth
#40only 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
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.micr…