They launched this a few months ago

What is the plan if Amazon decides to launch it as a service?

And many have done this before (selling auth). 0auth, Clerk, Supabase, etc.

Any more I'm missing?

And you don't get surprise updates that trigger a cascading dependency hell.

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.

   * 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

> Better Auth is mostly focused on the front end.

Better Auth has nothing to do with front end.

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

(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?

Does it also embed two-factor authentication, confirmation/reset emails for me? Those are the reasons one might want to go with Firebase.

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?

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.

I need this answered.

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.

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

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.

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.

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.

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.

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

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.

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

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

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

Crypto is absolutely not something you want to roll yourself.

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

The issue is 99% don’t know them and are not very good at following them. And the cost of error is very high.

I’ve seen a lot of startups that failed to implement even google oauth securely.

So yeah it’s a far cry from fud and you really should not do it unless you are actually good.

please. the whole world sees this for what it is: the USian bigotry of low expectations.

The parent was using something called “figurative speech”.

https://en.m.wikipedia.org/wiki/Figure_of_speech