←back to thread

282 points bundie | 1 comments | | HN request time: 0.439s | source
Show context
jtms ◴[] No.44383929[source]
"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?

replies(6): >>44384028 #>>44384484 #>>44384540 #>>44384697 #>>44385855 #>>44387250 #
rafram ◴[] No.44384028[source]
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.

replies(5): >>44384080 #>>44384145 #>>44384715 #>>44385363 #>>44386648 #
1. macNchz ◴[] No.44386648[source]
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.