At our company we use better auth for every product that has any kind of user account logic. It’s great since it’s drop-in, the plugins give so much functionality that you’d have to roll on your own in so little time and the integrations with ORMs like drizzle and prisma mean that your schemas stay the SSOT that they should be, even for auth. It’s extensible where it needs to be and brings defaults that are more than sane. Also the RPC-like TypeScript client that you also get for free is so good I don’t know how I could live without that.
Glazing over, I just wanted to give props and say that whatever good happens to better-auth, it deserves it.
supertokens did the same thing from bengaluru. didn’t start loud. just showed up with clean abstractions that didn’t leak. you could tell someone had wrestled with real auth mess before touching a single line. it worked, across teams, stacks, workflows
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
This library just hashes passwords and handles oauth2 callbacks. But it also requires a database to "store user data", which is really out of scope of an auth library. But I would like to hear how one goes from a country I've never heard about before to raising 5 mil as a JavaScript library "startup".
> 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.
> How is all of this relevant or even interesting?
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?
For folks that are using better-auth: are you using anything to build your frontend with? Or just writing it from scratch?
I was interested in trying this out but was kinda surprised to find this is just an sdk with no components.
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.
I remember how basically better auth got a huge lead because lucia was shutdown by its dev for their own reasons which I admittedly have forgotten but they made sense and the community had accepted it.
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.
This is why I love Lucia. They took the "teach a man to fish" route when they converted to a docs only approach. Now I've got my own auth system and understand a lot more about security.
I wonder how many users of Better Auth are individuals using it for their hobby projects and how many are companies/freelancers making money. Everyone is expecting great software but almost no one is contributing back in any way. If people were supporting such projects, there would be no need for vc money, right?
As an indie hacker using better auth, I’m somewhat skeptical of there now being VC money in the mix (enshittifcation is a process that starts with VC money).
But from my time working for enterprise, they often prefer OSS products that are well-funded for their stacks so they can rely on them for a longer amount of time. So I’d suppose this would help in that regard. Also having a cloak-like SaaS solution might be nice for those who don’t want to host their own infra, though I‘d advise against relying on third parties for auth.
Thanks for your comment! You really nailed as to what sort of discussion I wanted I guess.
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.
I like this vibe. As a bootstrapped company making money using open source software, I have no issue paying individual devs, I sponsor multiple projects on GitHub. VC funding, however, changes the game: now a project needs to deliver 100x returns just to survive.
I am going to give a guess on this one. I work for a large enterprise and have been involved with evaluating different OSS solutions.
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.
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.
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
Why does the article’s title state the country of origin of the developer? Does it matter? Is it a surprise that there are smart, business savvy developers across the globe?
It isn't a surprise for many, but my impression is that distribution of VC funds to African counties is highly inequitable. The article mentions that this is the first investment in an African founder for one of the involved VCs (Peak VX).
> 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.
Kratos and Better Auth are almost orthogonal to one another. Kratos provides a comprehensive back end, but no front end at all - you have to write it yourself.
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.
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.
Here's an article[0] (on my employer's website) that talks through some of the things to think about when choosing an authentication solution. (It's a bit old so doesn't discuss BetterAuth directly.)
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
You might say "I'll only have one application for the foreseeable future", but you might think about about any SaaS applications you'd want to have your customers use (support ticketing, training, public forums/communities). And mobile applications. And applications for different segments of your userbase.
(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.
Another reason to use Firebase is because they can provide a lot the advanced security (e.g. blacklists for 2FA phone numbers/emails coming from an algorthm whose innards are only known to Google).
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.
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 (Dax) 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.
There is a sibling post describing this particular project as known dead from the author.
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.
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.
"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?
I think it all started when libraries began to be replaced with "services" (I mean this in the broader context, not just auth). Integrations that were once development time or compile time, are now runtime. Two somewhat perverse incentives: developers get to offload some of their thinking (and also maintainence, reliability and scaling worries) to a service, and the service provider gets a perpetual income stream.
This is a market created by the supabases and it’s no code cousins. I frankly always considered auth so simple and fundamental, with best practices so well known that I never saw the need to use a SaaS for user auth. I guess if you want to offer all the auth methods that this library is useful and saves a lot of time.
As someone who has been at a company where for various reasons, we decided to "roll our own auth", I would have to disagree here. Don't reinvent the wheel if you can avoid doing so.
Absolutely wild take. Auth is most definitely not simple, nor are best practices well known, based on number of auth-related vulnerabilities published.
I guess everyone outside of the JS ecosystem, that has auth baked into the framework for decades, is just doing it wrong and riddled with hackers in their systems?
Yes. You're missing decades of the arms race between hackers and developers that has resulted in a degree of complexity that is too high for someone who isn't specifically trained in infosec.
Web devs use abstractions for lots of things. There's no reason auth should be a hill to die on.
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.
I called my doctors surgery because I couldn't login into their web bookings site. The receptionist said "I'll check your password" then she "oh it's all funny characters" and I realised she was reading my real password that was generated by my password manager. This was only a few years ago.
The most concerning part about the belief that bootstrappy self-taught hackers are able to tackle any type of problem just as well as experienced engineers with a solid academic background is how the ignore the fact that hacking together an implementation is a very small part of the problem, and actually knowing the problem domain is of critical importance.
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.
> 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?
I’ve taken early stage apps through a bunch of security review processes and never encountered questions about the specifics of the auth backend, beyond whether it can support the client’s specific SSO requirements.
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.
> 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.
That is a super refreshing take. When I started needing to add auth to apps (~5 years ago) the only advice I could find on auth was essentially “you are an idiot if you don’t use an auth provider”. Back then I was probably only reading r/webdev or something.
Aren’t we all self taught? I’m not sure why that part of the story is relevant. In over 15 years of this business, I’ve directly been on a team with probably 5-10 total people with a comp-sci degree — and that includes my time at Apple. Mark Zuckerberg was self-taught.
No, a lot of people go to college or "bootcamps" before entering the field. Given the amount of computer science graduates, I'd say we're not all self-taught.
How does Peak XV compete with YC? Isn't YC just more proof for Peak XV? One could argue it competes with Surge or something, but YC is technically even more early stage than Surge.
It's a tongue in cheek reference to Surge. Most APAC and EMEA founders treat Surge and YC as comparable, simply because YC's offer is comparable to a Series A round in those markets.
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.
As soon as a self-taught-dev can't write this anymore and auth is fully in the hands of only big corps, I'm pulling the plug.
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.
Strong disagree. University is not overrated for computer science, maybe it is overrated for vocational training. Because what we are discussing here is not computer science, but craft.
Anyway, the students grokking computer science are usually the better craftsmen, too.
It really depends on what you're doing. Many graduates I worked with and people from academia always wrote code so convoluted and abstracted it was impossible to follow. In the end it had the same bugs and their code was replaced with something a tenth of the size within months of them leaving.
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.
University is not just "bigger school". It gives you the time and resources to dedicate yourself to study. If you just want to write programs then of course you don't need uni. I could write programs before I went. In fact, I earnt money from it before I graduated, making me a self-taught professional programmer too.
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.
> 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.
>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?
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.
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.
> 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.
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 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.
On the flip side I was at a startup using auth0, because as you said, not a core part of the business right? Until the traction hit and they had hundreds of thousands of users. Suddenly the auth bill became untenable - users are great but there wasn’t enough revenue to cover these costs. Auth0 didn’t budge. In fact they were outright nasty to deal with. They were holding our user logins and passwords hostage and they knew it.
You don't have to buy into Okta, you can also lean on auth frameworks like auth.js. Either way you're depending on outside labor to adapt.
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.
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.
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
I'm not criticizing BetterAuth here, but the idea that rolling your own auth is easy.
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.
An improvement if their own approach would be worse than 'get a single self taught guy to roll something out'. If it's roughly the same it shouldn't be any improvement.
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.
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.
I agree completely, which is why it's enlightening to read implementations of crypto. These are often short, seemingly simple, self contained sections of code that have to be as close as possible to perfect. Even simple things like constant time comparison algorithms are beautiful little crystal palaces of code.
> 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.
Yeah, this cool "I don't care" attitude works only until one is on winning side of economy. Once its not then it is always bias against them on basis color, age, nationality, race and so on.
Ethiopia isn’t a race though? Are you saying you believe the title was trying to signal that the founder is black, not their country of origin? I’m not sure you can draw that conclusion.
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.
For production systems that need to scale and evolve over time, you’ll regret tightly coupling to Auth0 or Cognito. Don’t misunderstand me—the hosted versions of these services work well, and their hardened, managed interfaces make security testing straightforward. However, the moment you need even minor customization beyond their standard offerings, you’ll find yourself in a frustrating situation.
If Better Auth came with a simple builtin email implementation (i.e. just plug in SMTP credentials), I’d consider it perfect. (I’m not sold on Resend!)
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?
Comparing Better-Auth to Clerk or Auth0 misses the point entirely.
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.
At our company we use better auth for every product that has any kind of user account logic. It’s great since it’s drop-in, the plugins give so much functionality that you’d have to roll on your own in so little time and the integrations with ORMs like drizzle and prisma mean that your schemas stay the SSOT that they should be, even for auth. It’s extensible where it needs to be and brings defaults that are more than sane. Also the RPC-like TypeScript client that you also get for free is so good I don’t know how I could live without that.
Glazing over, I just wanted to give props and say that whatever good happens to better-auth, it deserves it.
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
This is Arnav Sahu from PeakXV. I used to work at YC. Really excited for them and Bereket, the founder. He is an outlier founder.
supertokens did the same thing from bengaluru. didn’t start loud. just showed up with clean abstractions that didn’t leak. you could tell someone had wrestled with real auth mess before touching a single line. it worked, across teams, stacks, workflows
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 like that last sentence!
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.
They launched this a few months ago
What is the plan if Amazon decides to launch it as a service?
Amazon already has Cognito. It's garbage. https://aws.amazon.com/cognito/
Not great but also far from garage for something that is extremely low cost.
I mean, it depends on your use case (and I say this as a cognito competitor).
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-...
1: https://ciamweekly.substack.com/p/trends-in-ciam
> I love the library and the success story but hope that the weight of this VC money doesn’t impact its awesomeness
It most certainly will at some point.
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.
And many have done this before (selling auth). 0auth, Clerk, Supabase, etc.
Any more I'm missing?
Auth is hard to get right, fiddly at the best of times, and is no one's core competency.
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.
Privy just got purchased by Stripe: https://privy.io/blog/announcing-our-acquisition-by-stripe
That this is not an oauth backend but a frontend library that you hook into something.
That doesn't sound right. The initialisation code has a database connection string argument. YOu wouldn't do that from a frontend.
> The initialisation code has a database connection string argument. YOu wouldn't do that from a frontend.
Definitely /s
This library just hashes passwords and handles oauth2 callbacks. But it also requires a database to "store user data", which is really out of scope of an auth library. But I would like to hear how one goes from a country I've never heard about before to raising 5 mil as a JavaScript library "startup".
> from a country I've never heard about before
How is your lack of geographical knowledge relevant to any of this?
> 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.
Did he get into the US before or after getting into YC?
How is all of this relevant or even interesting?
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?
> How is all of this relevant or even interesting?
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?
It isn’t – I was trying to make the same point basically. (I’m not in the US, though I haven’t started a $5M company yet, either.)
[dead]
[dead]
For folks that are using better-auth: are you using anything to build your frontend with? Or just writing it from scratch? I was interested in trying this out but was kinda surprised to find this is just an sdk with no components.
I found this https://better-auth-ui.com/
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.
I remember how basically better auth got a huge lead because lucia was shutdown by its dev for their own reasons which I admittedly have forgotten but they made sense and the community had accepted it.
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.
This is why I love Lucia. They took the "teach a man to fish" route when they converted to a docs only approach. Now I've got my own auth system and understand a lot more about security.
And you don't get surprise updates that trigger a cascading dependency hell.
I wonder how many users of Better Auth are individuals using it for their hobby projects and how many are companies/freelancers making money. Everyone is expecting great software but almost no one is contributing back in any way. If people were supporting such projects, there would be no need for vc money, right?
As an indie hacker using better auth, I’m somewhat skeptical of there now being VC money in the mix (enshittifcation is a process that starts with VC money). But from my time working for enterprise, they often prefer OSS products that are well-funded for their stacks so they can rely on them for a longer amount of time. So I’d suppose this would help in that regard. Also having a cloak-like SaaS solution might be nice for those who don’t want to host their own infra, though I‘d advise against relying on third parties for auth.
Thanks for your comment! You really nailed as to what sort of discussion I wanted I guess.
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.
I like this vibe. As a bootstrapped company making money using open source software, I have no issue paying individual devs, I sponsor multiple projects on GitHub. VC funding, however, changes the game: now a project needs to deliver 100x returns just to survive.
I am going to give a guess on this one. I work for a large enterprise and have been involved with evaluating different OSS solutions.
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.
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
I'm in the auth space.
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
Why does the article’s title state the country of origin of the developer? Does it matter? Is it a surprise that there are smart, business savvy developers across the globe?
It isn't a surprise for many, but my impression is that distribution of VC funds to African counties is highly inequitable. The article mentions that this is the first investment in an African founder for one of the involved VCs (Peak VX).
Because it is an inyeresting fact.
Better Auth is brilliant! My only criticism is that it's too tightly coupled with Kysely.
Congrats, very good library. I wonder what's going to be the business model though, since the library main difference is that it's not a cloud service
From the article:
> 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.
Curious how this compares to something like Ory Kratos? And what would the projected revenue stream be?
Kratos and Better Auth are almost orthogonal to one another. Kratos provides a comprehensive back end, but no front end at all - you have to write it yourself.
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 is mostly focused on the front end.
Better Auth has nothing to do with front end.
> And what would the projected revenue stream be?
I addressed that here, straight from the article. Basically open-core and hosting.
https://news.ycombinator.com/item?id=44388741
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.
Here's an article[0] (on my employer's website) that talks through some of the things to think about when choosing an authentication solution. (It's a bit old so doesn't discuss BetterAuth directly.)
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?
You might say "I'll only have one application for the foreseeable future", but you might think about about any SaaS applications you'd want to have your customers use (support ticketing, training, public forums/communities). And mobile applications. And applications for different segments of your userbase.(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...
> 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.
Does it also embed two-factor authentication, confirmation/reset emails for me? Those are the reasons one might want to go with Firebase.
It does 2FA. You have to implement emails yourself, but honestly it’s not that big of a deal (you likely have to do other emails for your app anyway).
It also does a bunch of other auth things, like OIDC.
Another reason to use Firebase is because they can provide a lot the advanced security (e.g. blacklists for 2FA phone numbers/emails coming from an algorthm whose innards are only known to Google).
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
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 (Dax) 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.
There is a sibling post describing this particular project as known dead from the author.
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.
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
They're talking about Open Auth.
https://github.com/toolbeam/openauth
[dead]
"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?
I think it all started when libraries began to be replaced with "services" (I mean this in the broader context, not just auth). Integrations that were once development time or compile time, are now runtime. Two somewhat perverse incentives: developers get to offload some of their thinking (and also maintainence, reliability and scaling worries) to a service, and the service provider gets a perpetual income stream.
This is a market created by the supabases and it’s no code cousins. I frankly always considered auth so simple and fundamental, with best practices so well known that I never saw the need to use a SaaS for user auth. I guess if you want to offer all the auth methods that this library is useful and saves a lot of time.
As someone who has been at a company where for various reasons, we decided to "roll our own auth", I would have to disagree here. Don't reinvent the wheel if you can avoid doing so.
Absolutely wild take. Auth is most definitely not simple, nor are best practices well known, based on number of auth-related vulnerabilities published.
I guess everyone outside of the JS ecosystem, that has auth baked into the framework for decades, is just doing it wrong and riddled with hackers in their systems?
You mean that for toying, personal use or hobby projects, right? Otherwise people get jaw drops or facepalms.
I'm curious about this too. How does this, for example, compare to Django's built-in auth?
I need this answered.
Yeah, and all the popular web frameworks include authn and authz as a core component.
Yes. You're missing decades of the arms race between hackers and developers that has resulted in a degree of complexity that is too high for someone who isn't specifically trained in infosec.
Web devs use abstractions for lots of things. There's no reason auth should be a hill to die on.
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.
I called my doctors surgery because I couldn't login into their web bookings site. The receptionist said "I'll check your password" then she "oh it's all funny characters" and I realised she was reading my real password that was generated by my password manager. This was only a few years ago.
The most concerning part about the belief that bootstrappy self-taught hackers are able to tackle any type of problem just as well as experienced engineers with a solid academic background is how the ignore the fact that hacking together an implementation is a very small part of the problem, and actually knowing the problem domain is of critical importance.
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.
That system was probably designed 30 years ago, and small businesses continue to use them. Happened to me as well.
> 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?
I’ve taken early stage apps through a bunch of security review processes and never encountered questions about the specifics of the auth backend, beyond whether it can support the client’s specific SSO requirements.
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.
> 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.
That is a super refreshing take. When I started needing to add auth to apps (~5 years ago) the only advice I could find on auth was essentially “you are an idiot if you don’t use an auth provider”. Back then I was probably only reading r/webdev or something.
That last sentence is possibly taken from <https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...>: “If you have customers, never outsource customer service.”
Thanks, I agree.
Yeah. Same thing with AI.
What are you talking about?
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.
That's not how I remember it. There was a lot of
floating around in the PHP example code universe.I unironically smell a conspiracy here.
cant wait.. i guess on the 27th they are dropping support for SAML
Aren’t we all self taught? I’m not sure why that part of the story is relevant. In over 15 years of this business, I’ve directly been on a team with probably 5-10 total people with a comp-sci degree — and that includes my time at Apple. Mark Zuckerberg was self-taught.
No, a lot of people go to college or "bootcamps" before entering the field. Given the amount of computer science graduates, I'd say we're not all self-taught.
Glad to hear Peak XV getting it's moment on a competitor's forum. Jokes aside, congrats Bereket.
How does Peak XV compete with YC? Isn't YC just more proof for Peak XV? One could argue it competes with Surge or something, but YC is technically even more early stage than Surge.
It's a tongue in cheek reference to Surge. Most APAC and EMEA founders treat Surge and YC as comparable, simply because YC's offer is comparable to a Series A round in those markets.
Love this news! Amazing by Bereket!
Also weary now of the monetisation strategy, as this probably means that enterprise SSO will be locked behind a massive paywall?
yet another jswt solution for no good reason other than js based "backends" can't really handle requests properly.
What’s the monetisation strategy here? Raising 5M for what exactly?
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.
As soon as a self-taught-dev can't write this anymore and auth is fully in the hands of only big corps, I'm pulling the plug.
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.
I don’t know about you, but most everything I know on those subjects is self taught. University is overrated for computer science.
Strong disagree. University is not overrated for computer science, maybe it is overrated for vocational training. Because what we are discussing here is not computer science, but craft.
Anyway, the students grokking computer science are usually the better craftsmen, too.
It really depends on what you're doing. Many graduates I worked with and people from academia always wrote code so convoluted and abstracted it was impossible to follow. In the end it had the same bugs and their code was replaced with something a tenth of the size within months of them leaving.
> 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.
[flagged]
University is not just "bigger school". It gives you the time and resources to dedicate yourself to study. If you just want to write programs then of course you don't need uni. I could write programs before I went. In fact, I earnt money from it before I graduated, making me a self-taught professional programmer too.
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.
> 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.
>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.
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
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?
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.
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.
> 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 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.
On the flip side I was at a startup using auth0, because as you said, not a core part of the business right? Until the traction hit and they had hundreds of thousands of users. Suddenly the auth bill became untenable - users are great but there wasn’t enough revenue to cover these costs. Auth0 didn’t budge. In fact they were outright nasty to deal with. They were holding our user logins and passwords hostage and they knew it.
You don't have to buy into Okta, you can also lean on auth frameworks like auth.js. Either way you're depending on outside labor to adapt.
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.
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.
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?
I'm not criticizing BetterAuth here, but the idea that rolling your own auth is easy.
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.
An improvement if their own approach would be worse than 'get a single self taught guy to roll something out'. If it's roughly the same it shouldn't be any improvement.
It’s not easy, but it’s not impossible either.
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.
He must be really good at selling lol
Everything in life is hard there.
> 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.
Argon2 with defaults. Stronger and easier.
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...
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.
I agree completely, which is why it's enlightening to read implementations of crypto. These are often short, seemingly simple, self contained sections of code that have to be as close as possible to perfect. Even simple things like constant time comparison algorithms are beautiful little crystal palaces of code.
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.
OAuth is very complicated and fuzzy though.
I am not surprised anyone makes mistakes trying to integrate it anywhere.
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
[flagged]
He just raised enough for a golden ticket
Wonderfully racist! How is it relevant in any way that the dev is ethiopian? I couldn't care less. I care about the product or service.
Yeah, this cool "I don't care" attitude works only until one is on winning side of economy. Once its not then it is always bias against them on basis color, age, nationality, race and so on.
Ethiopia isn’t a race though? Are you saying you believe the title was trying to signal that the founder is black, not their country of origin? I’m not sure you can draw that conclusion.
please. the whole world sees this for what it is: the USian bigotry of low expectations.
If you don't care, why is it the only thing about this news that you're engaging with in your comment?
Ethiopia is a nation. The word you're looking for is Nationalistic.
I'm not sold on Better Auth.
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.
> is criminal
No, it isn’t. Take a breath.
The parent was using something called “figurative speech”.
https://en.m.wikipedia.org/wiki/Figure_of_speech
Even figuratively, it's not criminal.
Indeed. Laid on too thick for my taste. Histrionic given the context.
For production systems that need to scale and evolve over time, you’ll regret tightly coupling to Auth0 or Cognito. Don’t misunderstand me—the hosted versions of these services work well, and their hardened, managed interfaces make security testing straightforward. However, the moment you need even minor customization beyond their standard offerings, you’ll find yourself in a frustrating situation.
If Better Auth came with a simple builtin email implementation (i.e. just plug in SMTP credentials), I’d consider it perfect. (I’m not sold on Resend!)
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?
Comparing Better-Auth to Clerk or Auth0 misses the point entirely.
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.