Comment by tornikeo

It’s just a few fields until it’s not.

SSO, SAML, SCIM, OIDC, OAuth, 2FA, passwordless auth, verification tokens, etc etc, And, variations of each for wildly popular systems you’ll be expected to integrate with but don’t support the exact spec.

For a while at my company, half our support engineers time went to handling random SSO issues that came up in our home built auth system.

Why pay someone to build a house? I’m sure you could do it yourself…but that doesn’t mean that is the best use of your time in all cases. The analogy is basic but apt; not everyone needs or wants to run (or create) every mechanism. I don’t do all of my own hosting either and it’s not because I couldn’t, it’s that it isn’t worthwhile in my cases.

To expand a bit more: if a business is faced with a choice to save some money by increasing risk, having people who’s job it isn’t managing and supposedly securing that information, or to have a third-party who job is literally to handle and worry about those things, who carries independent insurance, and who is on the hook if they lose customer data, and in exchange the business is simply taking the risk of associating with business that could do a poor job — which of those options sounds more appealing from a business sense? It’s a lot easier to blame someone else than earn back trust for your own major mistakes because you tried to write your own software to save a little money.

That’s the SaaS value proposition.

Because auth is a productivity tarpit. Anything plan on doing with auth looks simple but almost never is. Homegrown auth can easily sunk half of your dev and support teams.

Of course, we're not talking about email/password with "remember me" checkbox kind of auth.

Don't you wanna level up your career to become an architect? You can draw a box, call it "User Management" and slap "Clerk" or some other SaaS on it, and assume it's managed for you. This allows you to shove whatever requirements you want in that magic blackbox as you feel "it doesn't bring value" for you to implement.

I must as intelligent as you because I also never understood why things like supabase even exist. I believe this shows how much front-end dev world is detached from how things can simple and secure by default.

BetterAuth is users in your own database. So you don’t have to!

People are very scared of messing up authentication and getting hacked. They would rather offload that responsibility to a third party and not think about it.

Start any greenfield project, hand-coded auth takes up 50% of the development time of the entire MVP

I am just as confused as you. My 2c: For a broad range of requirements, running your DB directly and managing auth with Django or similar is easier. Perhaps at enterprise scale, this changes.

People are afraid to touch dangerous things, like passwords and payment systems. Depending on their skill level, they should indeed be afraid.

It feels like a good idea when you are early on in building your product and what matters is quickly iterating on the core features that define your product.

It’s not just the table, it’s also the auth and many other things that you know you will need but you would prefer to focus on other stuff.

Almost always you start by saying that you will replace that when the time comes and you have proved you have a product and now it’s time to actually build the real thing.

Some teams do that and some other, never migrate away and that’s how the GTM of companies like Clerk works.

Some people enjoy vendor locked managed services for their core infrastructure. Typically this decision is made when building from zero to one in resource constrained environments, and the long term play is to move to your own table/db when it becomes sustainable to do so. The only reason to move to a managed service after having done the work to setup self owned systems is when you need to either a) CYA or b) reduce headcount

The only project where this was the case that I didn't hate it was at a former employer, and it gave the responsibility of securing users to Auth0 and minimized our PII and attack surface, since even the login page was not hosted or controlled by us. Worse case you somehow hacked our users and got some free entree reward they had, otherwise good luck trying to get very little data.

It allowed us to do SSO for small one-off marketing / campaign focused sites. I could give a specific login URL and it would always log you in if you were already logged on.

I'm working at a tiny non-IT company. Outsourcing this work and the security of not having my non IT trained coworkers being able to touch the server is great (but a VM would do the same ofcourse, while costing money). Most of all, we currently don't even need paid tiers of supabase since our software is so small.

Given, I feel if you run supabase at a big company you are either lazy and probably have too much budget to spend on useless costs.

AuthN is hard and generic, authZ is easy and specific. Offload authN, and keep your users table in your Hetzner.

You are not supposed to offload your users table, you are supposed to offload your password field.

I wrote an article about this: https://ciamweekly.substack.com/p/ciam-for-the-single-applic...

The tl;dr of the article is that there are auth specific features that are not differentiated but that users expect. Just like you might outsource pieces of functionality like data storage and message sending to specialized servers/libraries/applications, you can do the same with authentication.

The article could use some improvements, tbh, it is 2.5 years old.