Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Supabase to Clerk to Better Auth

blog.val.town

Post reply on HN
Print view View original

201–210 of 259 posts

Re: From Supabase to Clerk to Better Auth

#201

Post by Orygin »

pdimitar wrote: post #72
transitorykris wrote: post #45

Earlier quoted context omitted.

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.

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.

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

Re: From Supabase to Clerk to Better Auth

#202

Post by Orygin »

LVB wrote: post #176
ipnon wrote: post #130

Earlier quoted context omitted.

It’s not that crazy! Or hard. If you can store a hashed password in your users table, and keep the salt secret, you have working auth.

And then the client asks for SAML & OIDC support, and codes via SMS, and god knows what else.

Indeed. Password auth was always easy to do, and it seems half the commenters here think that's all you need in modern times.

Then customers come and ask for SSO, SAML, OIDC, their niche auth protocol, 2FA, Pass phrases, etc...

And now your auth is a mess and a dedicated job to maintain and evolve.

Re: From Supabase to Clerk to Better Auth

#203

Post by luodaint »

Notable that in each step, there’s an added abstraction; specifically, an authentication abstraction is the hardest one to reverse.

Using a passwordless login from scratch (magic link + Google OAuth2, sessions stored in Postgres without an external auth vendor) gets us around that altogether. The fears about why one would avoid it are generally not justified. Deliverability is the only true problem. Address that, with a proper provider for transactions, and we’re in boring territory – which is the most delightful kind.

To move from Clerk to Better Auth is logical if the choice is between sovereignty and convenience. It’s the core problem that any group doesn’t want to confront right away: “How much of this am I truly willing to own?”

Re: From Supabase to Clerk to Better Auth

#204

Post by brabel »

dvt wrote: post #132
JSR_FDED wrote: post #128

So let me be the one to invite ridicule and scorn by admitting I wrote my own auth code. It was fiddly and boring at the same time. It also wasn’t rocket science, and it works well. I’ll be the first to admit that there are cases where this is a bad idea, I’m just responding to the chants of never roll your own auth. Knowing every single line of code involved allowed me to add some location-based functionality for on…

Kind of funny how something that used to be routinely self-written has been outsourced to libraries. I must’ve written auth like a few dozen times back in the PHP days, not particularly hard or complicated. There’s a million tutorials on how to salt and store passwords. I’ve had my sites attacked many times, but never breached. (JWT, OAuth, etc. has added a ton of surface area, however. So these days it’s inevitably…

Username and password as the only option to authenticate is really getting obsolete. You need to support social login, passkey, email links, maybe SMS or some other less secure methods depending on your target market… and more often also new standards like verifiable credentials with wallets managing credentials, including logins. Good luck writing your own implementations.

Re: From Supabase to Clerk to Better Auth

#207

Post by jdmichal »

ButyTh0 wrote: post #161
SkyPuncher wrote: post #121

Earlier quoted context omitted.

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

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

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

Re: From Supabase to Clerk to Better Auth

#208

Post by exi2 »

jdmichal wrote: post #207
ButyTh0 wrote: post #161

Earlier quoted context omitted.

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

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

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.

Re: From Supabase to Clerk to Better Auth

#209

Post by cpursley »

Orygin wrote: post #200
the__alchemist wrote: post #80

Earlier quoted context omitted.

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.

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