[tornikeo]

Can someone more intelligent then me tell me why should I offload my postgres users table to some 3rd party provider? Like what is so hard about keeping that table in my VM on hetzner that I have to give it off to someone else? It's not payments, it's just a few fields of data

[SkyPuncher]

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.

[sreekanth850]

I don’t know when we became this lazy. Auth is hard, sure, but putting your users table and sessions behind a vendor API is not something cool. Tell me one feature that is not supported by libraries like OpenIddict (You can build around) or Keycloak?

[sevenzero]

I think the main argument usually is time savings. Personally I just always do E-Mail and password auth, yea its old and not the shiny new thing, but it doesn't require me to integrate 200 different ways of doing auth.

We should be able to demand users remembering their passwords, I dont like to cater towards users who simply dont want to put in the work to use my product.

Will I lose potential users over this? Yes. Does it feel bad knowing I am in control and wont have to offload to 3rd party vendors? Hell no.

[dotancohen]

That's great for B2C, but B2B demands SSO.

[sevenzero]

Not really, we do B2B. E-mail & password is good enough for our customers. They really really dont care about what kinda auth we use.

[Orygin]

Great for you but that's not the case for a lot of B2B contracts we have. A lot of them require integrating with their SSO, not just for login but for permissions too

[williamdclt]

Depends on your industry I guess. My personal experience is that small-to-medium companies ask for SSO, large and enterprise _require_ it.

[sreekanth850]

Same here, Just email + password, no google dependency initially. If more users ask we will think of it. but again you don't need a cloud vendor for all this.

[zarzavat]

You do you but most businesses if given the option between supporting OAuth to reduce friction on signups, or only supporting password auth, will choose the option that makes them more money.

You don't have to use a 3rd party service for OAuth. You can do it in house.

[sevenzero]

Yea I know, I just don't want my app to have a google logo on it, or whatever other companies people use to login with. E-mail and password will forever be my go to solution.

I want intentional users not the ones that click "sign up with google", try out the app once and never come back. Also I don't have the time to learn how to properly integrate more auth methods into my app. I want my own user table, I want predictability on how a user model looks and I want to be in control of everything.

[selfmodruntime]

Well the disadvantage is that you're responsible for your companies keycloak.

[Gareth321]

Exactly. Do you want to become ops? Because that's how you become an ops team.

[hylaride]

If you're a SaaS vendor, you want to make onboarding and logging in as easy as possible and being able to do things like add a "login with google/apple" button or other third party SAML/SSO tooling is one way to do that. Supporting that workflow sucks as it can involve very finicky integrations involving certificate trusts, etc.

[whstl]

Those authentication providers require you to do the same Google/Apple OAuth certificate configuration yourself, and you even have to pay the 99 euros for Apple.

SAML/SSO is indeed finicky, but the problematic part (mapping attributes) is often done by IT teams, ESPECIALLY if you use a third-party provider.

[grinich]

WorkOS has a built-in workflow for all the complex SAML/SCIM attribute mapping.

https://workos.com/docs/directory-sync/attributes

Also certificate renewal flows:

https://workos.com/changelog/certificate-renewal-flow

(I'm the founder.)

[SkyPuncher]

Not sure what laziness has to do with this. It’s all about tradeoffs.

Auth isn’t something I want to think about. There are a lot of hidden traps.

[jarym]

"home built auth system" is bound to have "random SSO issues". You fix them, that's how things mature.

[SkyPuncher]

Yep, it’s just a drag. It’s not our core product value so any effort we put into it is a drag.

[ButyTh0]

Rather than just use an email solution Google built GMail into a massive email solution despite it not being a core product

Sometimes that's just an opportunity

[jdmichal]

> ... not being a core product

Technically true, because Google's core product is ads. Also fundamentally wrong, because Gmail serves as a massive source of ad targeting information, in addition to being a high-engagement canvas to display those ads.

[exi2]

Google has not been scanning gmail mails for ad targeting since 2017. I think after 9 years we can finally let that one go.

Ad display I'll still grant you of course.

[ButyTh0]

Sure, now it is.

It was an unproven long shot when they built it.

[tomrod]

Supabase's auth is MIT licensed and OSS, is it not?

https://github.com/supabase/auth/blob/master/LICENSE

[ctm92]

Supabase is OSS but it's a real pain to actually self host it

[theturtletalks]

Couldn’t you get Claude to go into Supabase’s auth code and make your custom like their’s but adapted to your stack?

[linkregister]

"Claude, make my custom like their's but adapted to my stack. Make no mistakes"

[rubogubo]

I'm guessing they simply didnt want to spend the time and money doing that

[janderson215]

Possibly didn’t want to accept the additional risk that comes with rolling your own auth as well.

[amluto]

Is this perhaps a reason to have a Users table that is separate from the table of data on how you authenticate that user?

[moooo99]

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

fwiw, we also have entire staff dealing with SSO issues among our employees and users, despite relying on external services to handle auth.

A problem domain as complex as authentication is bound to habe issues of some sort. But I am not sure if I would be so fond of „outsourcing“ something as integral to my services as the access to these services

[Gareth321]

There is a trust component for sure, but a business requires assessing the value of time against revenue. I can say for our org that using an off the shelf solution like Clerk saves us time and money and we believe the risk is very small relative to the savings. Maybe the cost for you is not large right now, but when you've got 20 enterprise customers all asking for specific OIDC integrations configured with Private Link, custom domains, and private clusters, an auth solution starts looking mighty fine.

[sebmellen]

Just use Ory Kratos and self host it.

[EtienneK]

That’s when you install Keycloak.

[faangguyindia]

is it just me? who just uses magic links delivered via email or telegram as backup?

[vinckr]

Personally I hate magic links via email with a passion and will actively avoid products that have this as the only authentication method

[impulser_]

Majority of apps are B2C apps, they don't need any of this.

All you need is Apple and Google Oauth.

[sandeepkd]

If you are just starting out its probably a good idea. Think about the use case when google bans either your app or bans your app user?

[deaux]

Then your business is entirely screwed anyway because you've just lost half the market

At least to me it sounded very much like they were talking about mobile.

[mooreds]

It depends on your use case.

If you are a B2C app, you are probably more concerned about:

- social providers (Apple and Google being the big ones, but others could play a role--FB or Tiktok for example)

- easy registration (but not too easy, you want to avoid bot spam)

- self-service account management (updating profile fields, consents [CCPA, GDPR, others], resetting passwords

- single sign-on between your apps (if you have multiple)

- language support (for your backend, and mobile/web front end)

- cost

- possibly MFA, possibly passkeys

[therealpygon]

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.

[the__alchemist]

I see Postgres etc as the builder. Supabase is more like the realtor; a middle man extracting profits and complicating the situation.

[Orygin]

Does Postgres talk OpenID connect directly? Does it integrate SAML easily?

Oh you still have to build the auth system yourself? Well maybe a realtor does sound good now.

[cpursley]

No, but most serious major stacks have officially supported or popular maintained libraries which handle all of this out of the box already.

[pietz]

This comment is more ridiculous than ever in 2026.

[gessha]

If you’re implying that people should __always__ roll their own services and never vendor out non-core parts, the security industry would love to learn where you work.

[arikrahman]

Yes the analogy doesn't work here because that is much more cost prohibitive and labor intensive.

[ajdegol]

Because of AI or because hackers are hyper targeting infra clusters?

[dnnddidiej]

Emperor, meet clothes.

[notatoad]

>that doesn’t mean it’s the best use of your time in all cases

Okay, so… what are those cases? I’m also curious.

[elevation]

> Okay, so… what are those cases? I’m also curious.

If you're willing to make a third party SaaS's uptime the ceiling for your own org, you can delegate auth. Github might not be a good choice for SSO.

If you're not threatened by per-user-per-month fees, you can delegate auth.

If your threat model is compatible with a third party having visibility into your user's network location and the frequency and duration of their activities across your org, you can delegate auth. (Okta will probably not inform your competitor that your main sales guy is in North Carolina this week and has logged in from the conference room wifi of your competitor's main client.)

If you can trust the third party to not allow an interloper to bypass your requirements, you can delegate auth.

[fnoef]

This is such an absurd take.

For starters, if I'm a "house builder" by trade, then yeah, I am going to build the house myself. Otherwise, why should the client pay me, and not the guy I'm subcontracting?

Secondly, there is no such thing as a "house builder" profession. It consists of a lot of different trades people, some of them having legal power to sign off your house build (for example an electrician). Now, we could try to push for something similar in software engineering, and say require you to have an "authentication engineering certificate" in order to handle code related to auth, and only a person holding the certificate can allow such code for production use. But I'm pretty sure all the vibe coders and tech bros will cry how unfair and bureaucratic the system is.

But of course the entire SWE profession is based on grifting, and extracting as much money as possible from the customers while cutting the costs. If you are so afraid to save passwords to a database, then at least don't call yourself a software engineer.

[square_usual]

> For starters, if I'm a "house builder" by trade

You're not a house builder, you're a widget maker who needs a house to live in. Auth is almost never your startup's core competency or offering. Spending one of your very valuable five engineers on the auth tarpit while you lose deals because SSO is hard could be life and death for you.

[therealpygon]

Clearly!

It’s humorous that these conclusions are that the only option is SaaS or write it yourself, while my comments were about not doing things yourself, not that a SaaS is the only answer. Interesting that is how you felt the need to take it.

People are rarely as clever as they think they are at preventing others from doing something, while others only need to find one thing wrong. “Write it myself” is about the dumbest answer to that problem if you do not have the same level of resources to commit to that specific problem as can be solved by someone else.

Not really a hot take to state something so…basic..but you’re welcome to conclude what you like.

[eddythompson80]

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.

[egorfine]

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.

[aatd86]

I wonder if it is not people being notoriously lazy or clueless at an astonishing degree. How often do you hear that password were saved in plaintext? Surprisingly high in this day and age.

People not knowing what salt and pepper is... Vulnerabilities almost as if on purpose...

Perhaps it is actually not THAT hard but just like error handling, people don't want to do the unsexy parts and want to delegate those tasks to someone else perhaps. There must be a behavioral pattern there...

[selfmodruntime]

Your comment has a bit of an inexperienced smell. Business auth infinitely more complex than saving a user and salting/hashing his password.

> There must be a behavioral pattern there...

The pattern is that your comment is very far from reality.

[aatd86]

My point is that people mess up things as basic as salt and pepper, or encryption at rest. People are not even trying...

If we deal with the intricacies of rbac, abac, acl mixed with scopes ,sso, saml, oidc, mfa, etc... I don't find these too conceptually, complex.

I mean, it should be avoidable complexity. Most of the complexity is technical debt, bad implementations etc. But by itself it is not THAT complex.

[selfmodruntime]

No. OIDC and in general identity management + entitlements in a large business organization is complex because we need that complexity.

[aatd86]

We are speaking about incidental complexity vs. essential/inherent complexity. Inherent complexity is dealing with an XML format that is prone to vulnerabilities because people don't know how to parse properly or the protocol was badly spec'd back in the day in the case SAML for instance. Or ill-defined scopes, etc...

Having had the chance to try and implement libraries to interface with those systems a couple times, most people agree that implementations are far from perfect or streamlined. We call this incidental/accidental complexity.

[egorfine]

> want to delegate those tasks to someone else perhaps

And this someone's name begins with "Cla" and ends with "ude".

So we're going to have a lot more vulnerabilities in the auth code going forward.

[aatd86]

Apparently a mythos loop will mitigate that. /jk

We will see I guess... It could also be an opportunity to audit systems in automated ways.

[jarek83]

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.

[dnnddidiej]

Do you say the same about AWS RDS. Are you saying VMs is all you need and it is a doddle for anyone with FE only experience to set up, maintain and scale.

[kevmo314]

Yes many people do say the same about AWS RDS.

[f3408fh]

Yeah you’re a bit confused. Supabase has nothing to do with frontend other than providing SDKs and some frontend components to integrate with their backend.

[oompydoompy74]

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

[tornikeo]

Why better auth and not, postgres in docker? What is it better about better auth compared to the ol reliable postgres?

[oompydoompy74]

I think you are misunderstanding. Better Auth just uses your existing database… It’s just a library.

[mvkel]

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

[princevegeta89]

I would disagree here. You probably need OAuth with popular social services and implement username, password or OTP-based auth overall. For an MVP, you don't need to care about more details beyond this; it is hardly 10% of the entire effort, if not 5%.

[awestroke]

It takes like an hour. So that's a quick mvp then

[transitorykris]

Social logins, email logins, password resets, multi-tenant, organizations, many to many users to organizations, etc etc. Not necessary for MVP, but can definitely be painful hacking in later if the MVP hits.

[koliber]

What you are talking about is in a large part authentication. You can do authentication using an external service and still have your user table locally. You can also do authorization locally with a local session table while leaving authentication to a SaaS.

[RedShift1]

By the time you're so big you need all of that, there will be other people at the table to "hack that in".

[SkyPuncher]

I strongly disagree. If you’re selling to other businesses, much of that is an expectation.

[pdimitar]

Social logins, multi-tenant and organizations are very far from table-stakes for an MVP.

Whether it's painful to put in later or not is sadly nothing that the managers and executives concern themselves with.

[Orygin]

Depends on the company and product. The SSO/Social login, multi tenant and multi platform are indeed needed for my MVP.

[pdimitar]

Indeed it depends of course. Though I don't find it fair for those requirements to be presented as table-stakes and required, as my original parent comment seems to have done.

[xmcp123]

All I am seeing here is Django modules

[the__alchemist]

Django, Rails etc handles this.

[mvkel]

So... you just have to not build your web app in the most popular web app language? Somehow i think there will be big time debt from that decision

[xmcp123]

Not as big as the debt you will get from having to implement it all yourself. And it's not like he's suggesting you use cobol - there is not an issue of finding people who can work with both rails and django, so the popularity isn't really relevant.

[the__alchemist]

Those are both very popular languages for web backends, and both of those platforms are mature and robust.

[jadbox]

I feel seen. It's compounded if you also need to add HIPAA row-level security compliance that spans to every form of resource.

[xmcp123]

…use Django, install auth modules

[cpursley]

Mature frameworks generally handle auth out of the box.

[the__alchemist]

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.

[jonas21]

That's what they did. They migrated to Better Auth, which stores everything in your DB. It's the equivalent of Django auth for the Typescript ecosystem.

[il]

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.

[sandeepkd]

Unfortunately this is a common premise and on surface its a good idea too to let a expert in particular domain handle it. Where it gets muddy is when this third party are themselves learners and just see this as a good business opportunity

[rubslopes]

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

[sevenzero]

I roll both of these at work, from auth to cashless payments to regular online payments. It's not as hard as people make it out to be. Probably a lot harder at big companies with huge attack surfaces and attention though.

[giancarlostoro]

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.

[cpard]

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.

[Viveletta]

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.

[sudoshred]

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

[normie3000]

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

[pbalau]

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

[drbscl]

Better Auth is basically just a library / scripts that you run in your application.

[mooreds]

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.