bekacru

Yeah, Vercel has already done this before like with Nuxt, Svelte and other. But I also do want to have a better story for auth with all those frameworks and Nextjs as well.

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 think auth is complicated outside of browsers too. But browsers do make some things uniquely confusing, especially cookies and general security primitives are full of footguns

Hey, Bereket from Better Auth here. I started Better Auth to solve this exact issue for myself, and it later turned into a company. It always give me joy to just see others getting the same value from it :) There is a lot to work on, would love to know what we can improve

There is light mode and you can change themes with cmdk + change theme

You can use PAT

Hey HN, I’m Bereket from Better Auth.

A couple of weeks ago, I started hacking on a project to improve GitHub, mostly because I was tired of the current experience (like many others) and no one seemed to be doing much about it.

It’s still very early and pretty ambitious, but I hope you like it. It’s open source as well.

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.

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_...

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

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.

We’ve had early access to it for a while now, we’re already running a lot of performance critical workloads on it and it’s been working wonderfully. Congrats sam and the team on setting a new standard for what highly performant managed Postgres should look like :)

1. Depends on whether you need RLS or not. We're working on improving the Better Auth + Supabase RLS story by collaborating with them, but if you're not relying on RLS for authorization, I’d go with Better Auth. You’ll get more features, and it’ll feel more integrated with your backend rather than your database. Plus, if you ever want to switch database providers you can.

2. Yeah, you’d need to migrate to Better Auth and move your user table to your main schema. We have a migration guide for Supabase.

3. It’s just additional features built on top of the framework, not a 3rd party auth service. You’ll still use the framework, and when you need those features, you can connect it to the infra to enable them.

As I mentioned in the post, our goal is to help developers own their Auth. And now that we’re funded, it’d help us pursue this goal even more aggressively and give people more confidence.

Yes. You should check the SSO plugin which would allow you to store the config in your db and can retrieve it dynamically.

Thanks for the kind note! And good suggestion. I was meaning to update that for a while.

Not many people are implementing passkeys yet, and we don’t want to force that on users. Also, the plugins we provide are still tightly integrated with the framework, you don’t even need to install a separate package, just import them.

- Not right now, but there’s already an open issue and a PR in progress.

- We don’t use JWTs directly, and sessions always require state (it’s not stateless). And yeah, both the client and server handles automatic session refresh.

- Yes, we support both multiple sessions or having different organizations open in different tab: https://www.better-auth.com/docs/plugins/multi-session

- Yes, that’s possible, you just need to set the `prompt` parameter to `select_account`

Appreciate the kind words :)) Yeah, it’ll mostly be high-level features. We do plan to offer paid support seems like there’s demand for it, and it helps give teams more confidence when choosing the library.

You should be able to get all the features you get from Firebase and much more. The only major downside right now is that we don’t have a Firebase/Firestore adapter yet. So if that’s the database you’re using, you’d need to use a different one for your auth service.

The commercial offering is essentially a dashboard that connects directly to your existing setup and gives you a way to manage users and view analytics. You can also integrate additional services like bot and fraud protection as needed

Thanks for the kind words - really appreciate it! And yes, it connects directly to your existing setup (the dashboard is mostly just a UI). What you’re really “buying” from us are the additional features on the dashboard like bot protection, analytics, etc...when you need them. We’re still figuring out the pricing, but most likely, the base dashboard will just be free ;)

Yes, that’s exactly what we’re aiming for. I think there are many reasons to tightly couple auth with your app. As you said, self-hosting auth servers and integrating them often isn’t a fun experience and that’s one of the reasons 3rd party auth providers became so popular.

In the JavaScript/TypeScript ecosystem, libraries like NextAuth still have a huge number of users for the same reason: ease of use. And with the rise of full-stack TypeScript apps where both the frontend and backend live together and share a strong type system, it makes even more sense to keep all your context in one place.

That said, if you ever decide to self-host Better Auth in a dedicated container, you still can.

I'm frustrated by how expensive decent web analytics services are. I built this project a year ago, and I’m now making it free forever :)) It’s open-source, and I’m covering the server costs for now. If demand grows and the server can’t keep up, we might consider crowdfunding, but it should be fine for now. I’m not actively maintaining it, but since it’s open source, feel free to improve it!

Hey, author of Better Auth here. I created Better Auth because I couldn’t find any other auth library that goes beyond simple login with OAuth. Even then, the only properly maintained ones were NextAuth (Auth.js) and Lucia (which is now deprecated). I’m not sure where the idea of "too many auth libraries" is coming from.

https://better-auth.com :)

The only place where "node" is necessary is for password hashing, and as there’s no cryptographically secure way to hash passwords on CF Workers or other edge runtimes it's not really an option. At this stage of the project, supporting Deno isn't a priority but for those not using email and password auth, CF Workers and other edge/serverless runtimes should work just fine

Thanks. Yeah that should be supported down the road.

Thanks for the suggestion. Surprisingly, it’s actually quite easy to search for. There aren't much false positives. It’s already the first result that comes up on Google.

Thanks for the kind words! I don’t think a single library should support two fundamentally different session methods—it adds unnecessary complexity, especially with the plugin ecosystem. That said, I could see it being added as a plugin if there’s a real need.