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.
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?
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
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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’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.
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?
> 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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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?
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
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.
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.
> is criminal
No, it isn’t. Take a breath.
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?
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
I think they’re rolling out their own managed auth service, may have already done so actually.
They launched this a few months ago
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 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.
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.
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!
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
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.
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
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?
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.
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?
> The initialisation code has a database connection string argument. YOu wouldn't do that from a frontend.
Definitely /s
[dead]
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.
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.
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
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.
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).
> 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.
Can anyone compare Better Auth with something more barebones like Lucia?
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.
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
lucia is deprecated https://github.com/lucia-auth/lucia/discussions/1707
"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.
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’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.
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?
> 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.
I unironically smell a conspiracy here.
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.
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.
You mean that for toying, personal use or hobby projects, right? Otherwise people get jaw drops or facepalms.
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.
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.
Also weary now of the monetisation strategy, as this probably means that enterprise SSO will be locked behind a massive paywall?
[dead]
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.
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.
> 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
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 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.
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.
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.
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
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?
Because it is an inyeresting fact.