Glazing over, I just wanted to give props and say that whatever good happens to better-auth, it deserves it.
Launch HN: Better Auth (YC X25) – Authentication Framework for TypeScript - https://news.ycombinator.com/item?id=44030492 - May 2025 (106 comments)
Better Auth – Authentication library for TypeScript - https://news.ycombinator.com/item?id=42272707 - Nov 2024 (32 comments)
Show HN: Comprehensive authentication library for TypeScript - https://news.ycombinator.com/item?id=41678652 - Sept 2024 (44 comments)
better auth gives off the same shape. that gets well adopted because it survives scaling without needing a rewrite
same pattern and diff origin place. someone holding the whole stack in their head long enough to ship something
I am also interested on how they plan to monetise it. I love the library and the success story but hope that the weight of this VC money doesn’t impact its awesomeness
There are times when Cognito makes a ton of sense (I wrote about some of them here[0]). There are other times when it doesn't.
What I keep wondering and asking is "why doesn't AWS invest more in Cognito?"[1]
0: https://fusionauth.io/blog/how-to-migrate-from-cognito#when-...
It most certainly will at some point.
Any more I'm missing?
It's almost always part of the box not the chocolates, and so is an excellent candidate for outsourcing. I can see why companies attack this space.
Definitely /s
How is your lack of geographical knowledge relevant to any of this?
It doesn't matter where the country is located on the map. If you happen to be a citizen of a developing country, your opportunities are extremely limited, and that is why I'm curious how he managed to get into the US and make a startup out of something that doesn't make sense to be one.
Do people in the US still think that people living abroad are playing with rocks and sticks all day when they are not hunting for food?
Is YC not super competitive and in order to get in you and your co-founder would have to have graduated from some super prestigious university ala MIT?
The DX is quite nice, even though not well suited for existing projects as it is hard to migrate existing users. There is no easy way to keep existing sessions or do a legacy login, then migrate a user to the new better-auth supplied hashing function.
I found this https://better-auth-ui.com/
But those who hadn't started using better auth more. And now I guess its crazy how I felt as if this would be just a small project like lucia in the sense of its just created for the passion and the art, but now it has raised 5 mill$ , I wonder if the community wanted this to be an artisanal like project like lucia before its end or what the community thinks of this move. Since VC and open source have some inherent compromises with each other and I guess I just wanted to write this to hear more about people who are using better auth in prod and what they think of what this VC funding.
I agree so much with the enshittifcation but like, I never understand why atleast open source projects need VC funding/ if they really want to earn money, might as well bootstrap it and try to get some Business customers for support etc.
But if you are saying that to get business customers, I need vc funding, then I guess it forces some enshittifcation.
I am okay with having a SaaS solution but what I truly don't understand is why we need vc funding.
I truly love developers wanting to earn money with open source. I appreciate them because they are essentially giving us gifts and being altruistic and I want to live in a world where people who can, do support them. But I am not okay with is some corporation now deciding the direction to go for open source (and that corporation doesn't care about the craft or the community, they want money.. they want returns since its just a number to them really) and that force of direction really alienates communities and just forks appear and just tbh it becomes messy.
I am more than curious as to why enterprises want VC funded OSS products. Yes you rely on them for a longer amount of time, but it also increases the chances of rugpull quite significantly imo. I don't think that one should just get VC funding just because entreprises like it. Should they?
Maybe I am so alienated with startup culture but I just want anything I build to not burn piles of cash that I need to rely on someone else, and I'd rather be profitable from (day one?) with my own bootstraped company / basically being a indie hacker like you I suppose. I get why some companies need VC funding and they become startups but I don't think that literally everything should be startup I am not sure.
One of the things that tends to come up is support. Now a small OSS startup with no funding and maybe even no way to pay them gets an automatic no in most cases.
My guess is that it is less about VC money and more about “I know I will have someone to call as long as I am willing to pay” kind of thing. VC money tells the company someone else is confident enough about this so I can be too.
Just my non-expert opinion.
I didn't like the fact that it doesn't have a built-in sign-in ui components, but glady https://github.com/daveyplate/better-auth-ui solves it.
I hope they will also develop a self-hosted standalone service/node which hosts accounts and can support JWTs which I could verify on my own servers so the BetterAuth node would issue JWTs signed with a secret key I provided as an ENV var, then I could verify the JWTs on my own servers. This would be a neat decoupling. Could be offered as a SaaS service as well.
I'm also keeping tabs on https://github.com/stack-auth/stack-auth
It's usually best to verify JWTs using an asymmetric keypair, that way the BetterAuth node can sign the JWT, and your servers can use something like JWKS to get the public key.
Lessens where the secret key needs to be.
The exception is if:
* you control all the nodes and are confident in the security of all of them now and going forward AND * speed is critical (using HMAC to sign JWTs is faster) AND * you've benchmarked and signing speed is a significant portion of response time
* you control all the nodes and are confident in the security of all of them now and going forward AND
* speed is critical (using HMAC to sign/verify JWTs is faster) AND
* you've benchmarked and signing speed is a significant portion of response time> Engida says Better Auth, currently free to use, will focus on improving its core features and launch a paid enterprise infrastructure that plugs into its open source base. This will give developers the flexibility to self-host or opt for Better Auth’s cloud add-ons as needed.
So open-core and cloud hosting, it seems.
Better Auth is mostly focused on the front end.
You could use the two together, although I haven't seen anyone do that.
I have wasted so much time on third-party authentication frameworks like Ory Kratos that I wish we'd just written our own internal auth library. With Kratos we ended up customising it so heavily we could have just written our own. Same goes for ones that provided a frontend such as Keycloak.
Better Auth has nothing to do with front end.
I addressed that here, straight from the article. Basically open-core and hosting.
How does it compare to something mature like keycloak?
And what is the difference to just self-host superbase?
I can't understand why people who aren't Google scale do it any other way. When you're at the point where you need a separate auth service I'd call that good problems to have.
An embeddable library is great for one application; simplifies development and deployment. You can have foreign keys directly to user ids. It's the reason Devise or Spring Security are great for single applications
Yet breaking out authentication to a separate service is one of the first things broken out a certain scale. Why?
* single sign-on between applications (if you have more than one)
* eliminate a user data silo (if you have more than one application)
* different security/legal requirements between PII/credentials of users and application data
* a desire to hang multiple applications off of one identity store for data consistency
* separate deployment cadences
(The multiple app case is much stronger for IAM/Workforce, part of why Okta is a 17B company.)
Such a migration can be complex, so if you can see needing any of the above things soon, it can make sense to start with a sep auth server. You don't need to be google scale to get the benefits.
0: https://fusionauth.io/articles/identity-basics/complete-auth...
That's why they're gonna monetize by building a cloud service?
It also does a bunch of other auth things, like OIDC.
As an aside OpenAuth seems dead. No activity for 2 months.
Is this the core reason that we have a proliferation of packages, arguably doing the same thing, slightly differently, in some ecosystems… We’ve become this impatient?
However, my comment is a larger commentary. Imagine if a scientist went off and did research for 2 months and didn’t provide any updates about what they were doing? Would we assume their project was dead? Or a writer who publishes a short story and says “I will turn this into a 500 page novel.” 2 months later… no novel… must be dead!
Why can’t we, instead, assume that people who work on open source are sometimes taking a break? Why can’t we create more fluidity around software… fork it… try to integrate it later? The git model was literally designed around this, but we’ve instead decided to live in a centralized shithole where only the original author is smart enough to make useful contributions… and when they don’t… for whatever reason, we shit can the project and start from scratch.
Revolving door.
one of the best libraries in the ecosystem. it's basically open-source Clerk without the baggage of needing to trust someone else's security story
Its absolutely bonkers to me that web development has gotten to a point where this is a novel pitch. Up until not that long ago ALL auth was done directly in your own database and embeded in your own backend. Am I missing something?
Web devs use abstractions for lots of things. There's no reason auth should be a hill to die on.
Enterprise customers did the math on what a security breach lawsuit could cost and started demanding verifiably decent security, which meant some off-the-shelf off-premises solution.
That’s basically where we are now, and it’s the reason that most of Better Auth’s users are early-stage startups — they need to scale quickly, and they don’t have many pesky enterprise/governmental customers who might want to see a certification.
This is why we end up with businesses running services where a receptionist has access to customer passwords. Those who designed the system weren't even in a position to understand why that was a critical flaw in the design, let alone a problem that needed fixing.
Not really. What happened is that some service providers started offering managed services, some of them completely for free and snazzy UIs that became de-facto standards. Developers could onboard onto fully functioning auth services in minutes with barely any development work and no service to manage.
Why do you think Google's sign-in flows are ubiquitous?
These days I tend to favor having auth built-in, via an "old school" web framework that provides an extensible auth system out of the box. Then we’ll extend that system with a managed 3rd party service to handle SAML when that starts to come up in sales conversations, because the setup is annoying and we can lean on the vendor to deal with whatever weird old IdP the client shows up with.
That's so 2001.
Bcrypt was in the default PHP libraries in 2013. It's been available in Python even longer.
This pattern of outsourcing the most basic of application responsibilities is lazy and exposes you to needless fragility and cost burdens.
There are a million and one libraries and frameworks that will handle all of this for you, meeting industry standards, without having to pay to be coupled at the hip to some SaaS vendor that will undoubtedly raise prices on you when they hit growth pains.
You're being rented a partial solution to something that has long been solved. And this - your customer relationship - is such a core function to your business that you shouldn't outsource it.
I was 14 learning PHP in 2003 and every tutorial insisted you salt and use a more secure hashing algorithm.
It’s weird to see people say things so boldly that are so wrong.
if (md5($_POST['password'])) == password_col) // success!
Oauth2, JWT's, hashes, timestamps, validations, and such, are all totally simple until they're not. The black hats have way more experience and way more time invested in this space than most any normal dev.
Anyway, the students grokking computer science are usually the better craftsmen, too.
It's mostly overrated, but not entirely so.
The vast majority of software development that I've learned has been outside of school, but there are a couple of core CS (and data science) concepts that I never would've learned if not for uni.
What I came out with was a far broader picture of what's been done in computing and, more importantly, how to find and read information about it. The biggest difference between me and my colleagues who haven't been to uni is when they run across something they haven't done before they are completely lost, whereas I'm usually able to say "hmm, that sounds like a graph problem, I think there's an algorithm for that".
Having said that, what I didn't come out with was how to do testing, version control, CI etc. Luckily that stuff is easy to learn on your first job.
Yes, a self-taught-dev should not write their own hashing-algorithms and so on, sure. But if Oauth2 is so complicated and hard to get right (and test), well then maybe the standard isn't so great.
Surely the black hats you refer to are themselves self-taught? They didn't find a school that would teach them about crime, right? In that case it seems like self-taught can be good enough.
They can spray and pray, you have to write proofs.
The difference between the bad guys and good guys isn't what they've learned. It's how the use what they've learned.
Any cybersec course worth its price tag is going to teach you all about penetration testing, exploits, etc. It's pretty hard to come up with a good defense if you don't learn about how the attacks work.
if software dev/blue team is wrong, it leaves a giant gaping hole in the system open for anyone to exploit 24/7
Rhetorical questions of course as we all know it's a clickbait title, but perhaps it would be nice for this label to stop being thrown around like it has any real consistent meaning or significance?
That being said, I didn't go to some fancy university -- just a small unheard-of state school of no notoriety. I think I benefited more from the learning environment and structure than from the actual instruction I received. Maybe I would have had better feeling about my degree had I attended a prestigious university, but honestly, most of what I learned was quite surface-level knowledge that came straight from the textbooks anyway.
I feel no superiority over those without a degree. In fact, quite the opposite. I feel a bit of shame that I do not know as much as I probably should despite having a degree.
Fundamentally, I agree with you. A piece of paper doesn't mean much. Based on the interview questions that are commonly asked, it seems like our industry doesn't find degrees that meaningful either.
But - and this is the funny part - I feel like my teen-angsty self has been vindicated. I'm so burnt out on exaggeration, not a single news site has gotten regular clicks from me in over a decade, nor do I comment or read comments. I listen to a little history dork YouTube before bed, or for tutorials. I'm free.
This sort of take is disingenuous. No one needs to go to a university to learn the syntax of a programming language, or to build up from a "Hello, world" program. That's not what a university is for.
That's not software engineering either.
In the very least an engineering exposes students to a curriculum which covers the necessary topics which allow someone to be competent at an engineering discipline.
Now, being a salesman and an engineer are two separate skills,so I don't really see a problem in having a "self-taught" programmer pitching a service and a business plan. However, as a prospective customer,having an auth service rolled out by people who clearly are not auth experts... That sounds like multiple downsides bundled with barely no upside.
Except that auth might not be a core part of your insurance or tax app, and you'd rather spend your energy on the part of "agility" that has to do with the core parts of your app.
I worked for a social media company before and we also rolled our own auth and we didn't regret it. High user accounts are a special case and you should know ahead of time.
But for B2B? Beware. You might get hit with an ask for active directory support.
Authorization is what's difficult and dangerous.
There are plethora of mistakes one can make in implementing AuthN/AuthZ, and many of them almost immediately will lead to either the direct leak of PII or can form the start of a chain of exploits.
Storing password hashes in an inappropriate manner -> BOOM, all your user's passwords are reversible and can be used on other websites
Not validating a nonce correctly -> BOOM, your user's auth tokens can be re-used/hijacked
Not validating a session timestamps correctly -> BOOM, your outdated tokens can be used to gain the users PII
BetterAuth is likely an improvement against the status quo for many companies if they have already decided to roll their own auth, as it at least already provides pre-made blocks of functionality that are hopefully battle-hardened rather than building completely from scratch.
If you’re just a developer who works on CRUD apps all day or never touches a backend then yea you probably don’t have the skills but auth is a solved problem and you can learn to do it right. A team of engineers can definitely put together an auth system.
The problem isn't how you store the hash it's how you generate the hash.
Cryptography part is fine but storage or the auth process isn't.
You would like to think that no-one would write their app that way, but there are plenty of slightly less worse things that happen in practice and vibe coding probably introduces all sorts of new silliness.
Good enough for almost any startup in 2025.
[1] https://trust.okta.com/security-advisories/okta-ad-ldap-dele...
OAuth, or any form of SSO, is not something you want to roll yourself.
Crypto is absolutely not something you want to roll yourself.
The issue is 99% don’t know them and are not very good at following them. And the cost of error is very high.
I’ve seen a lot of startups that failed to implement even google oauth securely.
So yeah it’s a far cry from fud and you really should not do it unless you are actually good.
I don't think this is a valid point. Specs only cover a single responsibility: interoperability. This is not a critical requirement of auth services, unless you have a hard requirement on federated auth.
I am not surprised anyone makes mistakes trying to integrate it anywhere.
Recently I wanted to add auth to my pet project, and between (a) using better-auth, then integrating 3rd party mailer service, and rolling out my main dashboard (b) leeching off free tier of Auth0 or Clerk and getting all batteries included I've chose the latter.
The fact that better-auth doesn't come with barebone dashboard is criminal.
For pet project it doesn't matter if I have to integrate Resend or Clerk, it's still some mental overhead I have to account for, but with Clerk at least I don't have to manage my users using sql queries.
People say it's better because you can embed it in your app. I don't buy that either. If I'd have to rollout better-auth I'd do that as a separate app, just to encapsulate database, dashboard, and integrations.
Anyway, glad it's getting traction, I just don't get all the hype around it.
No, it isn’t. Take a breath.
Agreed that a builtin dashboard would be nice, but it’s not necessary by any means – you’ll still be building your own dashboard around your ORM models, which is of course what Better Auth uses, too.
But if you’re looking for something more like Clerk, maybe try Logto or Authentik?
People choose Better-Auth because they want to own their user auth and users table themselves. Auth can be complex, but it's such a key and important piece of your business that outsourcing it to a 3rd party should be much closer to a last resort than a first impulse. If that 3rd party ever shuts down, has downtime, or your account gets suspended for whatever reason, users won't even be able to login to your app. That is a HUGE risk that I am not sure you are accounting for.