Launch HN: Better Auth (YC X25) – Authentication Framework for TypeScript
111 comments
·May 19, 2025jamesjulich
A few months ago, I found a security vulnerability for better-auth. Within 24 hours of reporting the vulnerability to the team, it was patched, a notice had been posted, and I had been credited with a CVE. THAT is how you do it, folks!
This team is top notch. The community leadership, responsiveness, and development speed has been incredible. The project itself is also great--this library is so much more flexible than others and requires much less effort to wrap my brain around. I'm so happy that this library is getting the recognition it deserves.
nikcub
Congrats on the launch! Better Auth has a level of universal love from developers that's really seen.
Just one suggestion - remove the F-bombs from the testimonials on your homepage. There are various firewall intel providers that will put you on the bad lists because of this. You usually learn this the hard way :/
bekacru
Thanks for the kind note! And good suggestion. I was meaning to update that for a while.
theogravity
Does it handle:
- Federated sign-in/out? In next-auth, it is a giant pain to implement: https://github.com/nextauthjs/next-auth/discussions/3938
- Automated refreshing of JWT tokens on the client-side? I always end up having to implement my own logic around this. The big problem is if you have multiple API calls going out and they all require JWT auth, you need to check the JWT validity and block the calls until it is refreshed. In next-auth on the server-side, this is impossible to do since that side is generally stateless, and so you end up with multiple refresh calls happening for the same token.
- The ability to have multiple auth sessions at once, like in a SaaS app where you might belong to multiple accounts / organizations (your intro paragraph sounds like it does)
- Handle how multiple auth sessions are managed if the user happens to open up multiple tabs and swaps accounts in another tab
- Account switching using a Google provider? This seems to be a hard ask for providers like FusionAuth and Cognito. You can't use the Google connector directly but instead use a generic OAuth2 connector where you can specify custom parameters when making the initial OAuth2 flow with Google. The use-case is when a user clicks on the Google sign-in button, it should go to the Google account switcher / selector instead of signing in the user immediately if they have an existing signed-in Google session.
bekacru
- 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`
theogravity
As another asked, "why?" on no JWT? It makes interfacing with our API servers so much easier as we don't need to maintain infra for sessions and wouldn't be limited by the 4kb limit for sending cookies.
doshaa
I use better auth for a real app
There is a plugin provided by better auth for jwt https://www.better-auth.com/docs/plugins/jwt
We dont need it since everything is a single "server" and cookies are good enough. JWT would be added complexity ( e.g sign out ) that i find it better to not be set as a default.
bonus reading http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...
motorest
> We don’t use JWTs directly
Why?
null
hungryhobbit
Evidently they prefer to be less secure by default.
timpetri
How did you resolve the multiple refresh calls issue? Do you use swr hooks on the front end? Been thinking about how to do this myself.
theogravity
No hooks on the FE side. We use a global lock via a promise. Our API clients are not tied to react in any way.
For all API calls, if the lock is not set, it checks if the JWT is still valid. If it is not, then the lock is set by assigning a new promise to it and saving the resolve call as an external variable to be called after the refresh is done (which resolves the held promise on the other calls, allowing the latest token to be used).
All calls await the lock; it either waits for the refresh to complete or just moves on and performs validation with the currently set token.
Looks like this:
- await on lock; if the lock has been resolved, will just continue on
- Check for JWT validity via exp check (the API server itself would be responsible for checking signature and other validity factors); if not valid, update lock with a new promise and hold the resolver. Perform refresh. Release lock by resolving the promise.
- Use current / refreshed JWT for API call
primitivesuave
Better Auth is awesome and I didn't even realize they hadn't publicly launched yet - I'm using it in production apps, and have seen it being used in all kinds of real-world use cases. IMO it's the best open-source option for a TypeScript developer who wants to implement authentication.
About the dashboard - would this just be an interface to my existing Better Auth setup (e.g. if I had customized the underlying data storage) or are you hosting credentials yourself?
You have my sincerest gratitude for building this incredibly useful library and documenting it so well.
bekacru
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 ;)
primitivesuave
Awesome! I used Better Auth for consulting work helping clients build MVPs, and if I could hand them a beautiful admin dashboard rather than linking it up to Retool or their BI tool of choice, they would instantly go for it - especially with all the bot protection and analytics features that I don't have time to build.
One of the reasons I prefer BA is because I retain a lot of flexibility with designing the rest of the system around the authentication. So for example, if I want to have an additional column per user, it's a lot easier to wrap my head around adding a new Postgres column than using some API for appending data to a user in Cognito/Auth0/Okta/etc in some rigid format.
macklemoreshair
One of our devs evaluated you guys and loved it and I do too, but you guys don’t have SCIM support which makes it really hard for us to justify moving to. We moved to an arguably inferior product because telling our product team “you’ll get scim” as part of an auth overhaul is an easier conversation. If you want enterprise customers, I’d recommend nailing down your enterprise feature set~ but the good news is that our devs liked your model the most so it’s just a matter of work for you guys to expand your functionality!
joker99
Same here, passed on it because of scim
catapart
Sold!
I've been waiting for something like this for the last year or so. There's so much that's SO CLOSE, but nothing quite as simple as "npm install -> add necessary config -> npm publish". That's what I've been waiting for and that's what it looks like you are offering here.
Very excited to spin up a new Hostinger VPS and slap this on there to provide syncing for local-first apps. If it's as easy as your docs make it seem, this will save a ton of time and headaches!
davedx
Sounds great! I'm interested to hear, how does this solution compare with open source, self-hosted authn components like Keycloak and Ory Kratos? While it's a bit more leg work integrating those, I've found that it's useful that they're self-contained and run in their own environment/container; but I have also sometimes wished that the data was more tightly integrated with my own application, which I guess is what you're aiming for.
bekacru
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.
gardnr
Most people will reach for BetterAuth when they would reach for NextAuth. Basically, when you want to integrate OIDC or SSO of some kind.
Back when I was looking at it a couple of months ago, the big thing that popped out was that BetterAuth supports email and password out of the box, where NextAuth seems to have a preachy disclaimer about how email and password is inherently insecure, so they leave you to your own devices to implement password hashing and the like.
That did give a sense that NextAuth was the first to dominate the space and feels as though they can dictate morals.
BetterAuth seems to be a bit more developer-focused.
koakuma-chan
> where NextAuth seems to have a preachy disclaimer about how email and password is inherently insecure
Yeah I needed a login & password auth last friday and I was so frustrated with NextAuth I ended up using nginx to set up http basic auth.
twodave
Is there support for dynamic sign in provider urls? One of the deal breakers (in addition to federated sign in/sign out being a pain) for us with next-auth was that we have certain customers whose security requirements include pointing subdomains that they own at our servers. So we would need to be able to use some logic to determine where the sign-in redirect should take a given user.
bekacru
Yes. You should check the SSO plugin which would allow you to store the config in your db and can retrieve it dynamically.
XavierPladevall
Super happy users :) Agree w/ what everyone has said. For us an extra benefit is the ability to host our user data in our own DB so that we can then dig into it w/ Index. Clerk keeps the data locked in and their "analytics" page is very very limited.
darcyrose
I happened to pick up Clerk for its ease of use and accessible free tier for my SaaS. The data locking was “solvable” but way too much effort as a solo dev. I had to use their webhook tool and set up a separate Inngest service to sync the data.
I’m very curious about Better Auth from what I’ve heard so far. I wish I knew about it sooner!
timsuchanek
Better auth is by far the best option out there. We've adopted it and couldn't be happier not having to manage 2 sources of truth.
akouri
Have been a proud better auth user for the last 6 months! Loved it so far, especially the fact that it's FOSS. Now that it's a venture-funded YC company, I am worried about using it. Should I be?
bekacru
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.
admiralrohan
The product looks polished. I have 3 questions:
1. If I am using Supabase for DB, should I use Supabase auth or use Better auth which would anyways use Supabase DB for saving data.
2. When using Supabase auth, they don't give access to the auth.users table and for saving additional user details like country we need a seprate profiles table. If I use Better-auth what should be the approach for saving additional details?
3. How Better Auth Infrastructure is different than Clerk or Supabase auth?
bekacru
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.
Hi HN! We’re Bereket and KinfeMichael of Better Auth (https://www.better-auth.com/), a comprehensive authentication framework for TypeScript that lets you implement everything from simple auth flows to enterprise-grade systems directly on your own database, embedded in your backend.
To be clear—we’re not building a 3rd party auth service. Our goal is to make rolling your own auth so ridiculously easy that you’ll never need one.
Here are some YouTube videos explaining how it works (we did make our own video but weren’t happy with it and these videos do a great job):
https://www.youtube.com/watch?v=hFtufpaMcLM - a really good overview
https://www.youtube.com/watch?v=QurjwJHCoHQ - also a good overview and dives a little deeper into the code
https://www.youtube.com/watch?v=RKqHrE0KyeE - short and clear
https://www.youtube.com/watch?v=Atev8Nxpw7c - with TanStack framework
https://www.youtube.com/watch?v=n6rP9d3RWo8 - a full-on 2 hour tutorial
Auth has been a pain point for many developers in the TypeScript ecosystem for a while. Not because there aren’t options but because most fall into 2 buckets: (1) Third-party services like Auth0 which own your user data, lock you into a black-box solution and are often super expensive; or (2) open source libraries like NextAuth that cover the basics but leave you stitching your own solution together from there.
For Better Auth. the kick off moment was building a web analytics platform and wanting to add an organization feature - things like workspaces, teams, members, and granular permissions. I assumed there’d be something out there I could plug in to NextAuth (the popular and kind of the only library), but there wasn’t. The only options were to build everything from scratch or switch to a 3rd party auth provider. I even tried hacking together a wrapper around NextAuth to support those features, but it was hacky. That’s when we decided to take a step back and build a proper auth library from the ground up with a plugin ecosystem that lets you start simple and scale as needed. That frustration turned into Better Auth.
Better Auth lets you roll your own auth directly on your backend and database, with support for everything from simple auth flows to enterprise-grade systems without relying on 3rd party services.
It comes with built-in features for common auth flows, and you can extend it as needed through a plugin ecosystem whether that’s 2FA, passkeys, organizations, multi-session, SSO, or even billing integration with Stripe.
Unlike 3rd party auth providers, we’re just a library you install in your own project. It’s free forever, lives entirely in your codebase, and gives you full control. You get all the features you’d expect from something like Auth0 or Clerk plus even more through our plugin system, including things like billing integrations with Stripe or Polar. Most libraries stop at the basics but Better Auth is designed to scale with your needs while keeping things simple when you don’t need all the extras.
We’re currently building an infrastructure layer that works alongside the framework to offer features that are hard to deliver as just a library—e.g. an admin dashboard with user analytics, bot/fraud/abuse detection, secondary session storage, and more. This will be our commercial offering. For this, there’s a waitlist at https://www.better-auth.build. However, this is only optional infrastructure for teams that need these capabilities. The library is free and open source and will remain so.
We’d love your feedback!