hckrnws

This is a nice set of tools. Very useful.

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

"Better Auth’s pitch is simple: Let developers implement everything from simple authentication flows to enterprise-grade systems directly on their databases and embed it all on the back end."

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?

Yeah and it was terrible. Your password would be stored as an unsalted MD5 hash if you were lucky.

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.

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

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?

> Yeah and it was terrible. Your password would be stored as an unsalted MD5 hash if you were lucky.

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.

So pumped for Bereket. Better Auth is awesome.

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

Gonna use n8n model, have these one click deploys with cloud db and everything or self host for free with many cut off features.

I think they’re rolling out their own managed auth service, may have already done so actually.

Pretty sure auth is not something I want a self-taught dev (or even most CS-graduate devs) writing.

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.

Besides being a self-taught developer, Bereket also did at least three years of a university CS program before dropping out to work full-time. Source: his CV.

I don’t know about you, but most everything I know on those subjects is self taught. University is overrated for computer science.

> University is overrated for computer science.

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.

That means you are a terrible learner and don't stand a chance where people do it for curiosity and fun

> The black hats have way more experience and way more time invested in this space than most any normal dev.

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.

Black hats have to be right once, white hats have to be right every time.

They can spray and pray, you have to write proofs.

if blackhat is wrong nobody will hear about it

if software dev/blue team is wrong, it leaves a giant gaping hole in the system open for anyone to exploit 24/7

>They didn't find a school that would teach them about crime, right?

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.

I learnt to program (in a very basic way) before doing the whole paper qualification thing. Am I self taught? Is that some kind of signifying badge one loses once one gets a 'proper' education? I also know many people _with_ the paper qualification I wouldn't necessarily trust

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?

It's funny, we've watched for two decades as the click-driven dynamics of the internet have degraded the meanings of words. At first, I was outraged on a daily basis. Then, as we all did, I learned, against my will, to forgive. "Can't blame them for chasing clicks! Who among us wouldn't cheapen a word if it meant a view?"

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.

Like many others here, I too have degree in computer science, and I will say this much. Not all degrees are created equally. Did I learn a lot? Absolutely. Could I have learned it all on my own? No. Could others learn it all on their own? Absolutely.

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.

> I learnt to program (in a very basic way) before doing the whole paper qualification thing.

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.

Auth is really not difficult to write. It's don't roll your own crypto, not don't roll your own auth. People need to stop spreading this fud.

I also ran into this trying to upgrade my company's auth strategy. The hardest part of auth is convincing people that... it's not actually as hard or dangerous as they think it is. It was an uphill and ultimately unsuccessful battle of mine. People can't even divorce JWTs as simple, verifiable json data blobs from the entirety of the OAuth2 spec. You see it on HN, with hundreds of circular comment threads and I've seen it in real life.

I would recommend that people don't do auth not because it's easy to be insecure, it's that auth sometimes needs agility. Auth sometimes needs to "grow" and adapt to the ecosystem, just like any other part of your product.

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.

Yes, people mix up the concepts of authentication and authorization (access control). Authentication can be really simple if you rely on a standard like JWT.

Authorization is what's difficult and dangerous.

Auth is actually really hard, with many really subtle high impact mistakes one can make.

What? No!

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

None of those things are difficult to do correctly.

Yeah, one would think so. Evidence in the wild shows otherwise.

Plenty of evidence in the wild also shows that programmers in general should never be trusted.

> Storing password hashes in an inappropriate manner

The problem isn't how you store the hash it's how you generate the hash.

Counterexample: Storing the bcrypt hash by appending it to a CSV file containing the usernames and hashes of all users then having a login process where that CSV file is downloaded to the client and the password is verified locally against that CSV file using client-side JavaScript would probably be very bad.

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.

The short answer: Bcrypt with 12 rounds.

Good enough for almost any startup in 2025.

With 5M you can get white hat audits. Even big boys like Okta have had serious fuckups [1].

[1] https://trust.okta.com/security-advisories/okta-ad-ldap-dele...

So it’s a bad idea, but somehow a guy in Ethiopia writes his own auth and builds a whole company around it and gets $5 million?

He must be really good at selling lol

Everything in life is hard there.

Auth, in my experience, isn't actually that hard to write.

OAuth, or any form of SSO, is not something you want to roll yourself.

Crypto is absolutely not something you want to roll yourself.

Yeah it’s not difficult if you know all the specs.

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.

> Yeah it’s not difficult if you know all the specs.

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.

But given that BetterAuth is an open source project with a large following, and also given that they just got funding so they can hire more help, now we can evaluate BetterAuth's competency in terms of their ability to coordinate help.

Also, as far as I know, they aren't reimplementing the core auth libraries/specs mentioned

OAuth is very complicated and fuzzy though.

I am not surprised anyone makes mistakes trying to integrate it anywhere.

Related:

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)

clickpass, YC s07

helllll ya!

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

Will this be monetized with the classic SSO enterprise subscription play? Would be nice if they are transparent on how they plan to make money.

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.

Curious how this compares to something like Ory Kratos? And what would the projected revenue stream be?

If i get it correctly, it solves the problem, to store data on MVP/Prototype Auth providers like Superbase, Auth0 or Firebase.

How does it compare to something mature like keycloak?

And what is the difference to just self-host superbase?

The killer feature is that it's embeddable into your app. You don't have to host anything besides your app and your app's database.

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.

> The killer feature is that it's embeddable into your app. You don't have to host anything besides your app and your app's database.

That's why they're gonna monetize by building a cloud service?

I mean right now it's JS's devise. There's always time in the future for them to ruin it.

Why does a JavaScript auth library have to raise five million?

Because the author of this library is an ambitious startup founder and would like to grow his tool into a business.

Can anyone compare Better Auth with something more barebones like Lucia?

lucia is deprecated https://github.com/lucia-auth/lucia/discussions/1707

Lucia has been converted into a kind of tutorial, which is another way of saying the author is going to college now and is busy or interested in other things.

As an aside OpenAuth seems dead. No activity for 2 months.

No activity for 2 months implies death?

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?

This space is too hot and the author behind OpenAuth is awesome and fast, so this is not his usual tempo. You're free to read the tea leaves, but I wouldn't bet on this one.

No activity for nearly 3 months with 67 open issues, 32 open PRs (many as simple as "fix typo") might signify that not a lot of time is being put into the project.

no lucia author has himself said that he s deprecating this https://github.com/lucia-auth/lucia/discussions/1707

cant wait.. i guess on the 27th they are dropping support for SAML

Love this news! Amazing by Bereket!

Glad to hear Peak XV getting it's moment on a competitor's forum. Jokes aside, congrats Bereket.

Trump will kick him out of the US.

He just raised enough for a golden ticket