[dead]
From Supabase to Clerk to Better Auth
191–200 of 259 posts
Re: From Supabase to Clerk to Better Auth
#192Can 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
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.
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...
Re: From Supabase to Clerk to Better Auth
#193Can 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
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.
> 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
Re: From Supabase to Clerk to Better Auth
#194Earlier quoted context omitted.
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.
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?
Well the disadvantage is that you're responsible for your companies keycloak.
Re: From Supabase to Clerk to Better Auth
#195Earlier quoted context omitted.
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.
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…
> 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.
Re: From Supabase to Clerk to Better Auth
#196Earlier quoted context omitted.
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.
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…
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.
Re: From Supabase to Clerk to Better Auth
#197Earlier quoted context omitted.
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.
> 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“…
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.
Re: From Supabase to Clerk to Better Auth
#198Earlier quoted context omitted.
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?
Well the disadvantage is that you're responsible for your companies keycloak.
Exactly. Do you want to become ops? Because that's how you become an ops team.
Re: From Supabase to Clerk to Better Auth
#199Earlier quoted context omitted.
That's great for B2C, but B2B demands SSO.
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.
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
Re: From Supabase to Clerk to Better Auth
#200Earlier quoted context omitted.
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…
I see Postgres etc as the builder. Supabase is more like the realtor; a middle man extracting profits and complicating the situation.
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.