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

131–140 of 259 posts

Re: From Supabase to Clerk to Better Auth

#131

Post by j45 »

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…

It's not that crazy. It can take time to do and get right, and is time away from other things.

Even if done for fun/learning, it can teach how the details of auth work to better appreciate and understand how other systems work and what to look out for.

I prefer to use existing things if possible, but if it was getting unreasonable to get it how it was needed, it wouldn't be off the table.

Re: From Supabase to Clerk to Better Auth

#132

Post by dvt »

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 harder to do.)

Re: From Supabase to Clerk to Better Auth

#133

Post by tomrod »

jarym wrote: post #65
SkyPuncher wrote: post #52

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

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

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

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

Re: From Supabase to Clerk to Better Auth

#134

Post by mvkel »

the__alchemist wrote: post #82
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.

Django, Rails etc handles this.

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

Re: From Supabase to Clerk to Better Auth

#135

Post by colinclerk »

pdantix wrote: post #104
elAhmo wrote: post #34

Using Clerk, quite unhappy with it. No proper RBAC (roles are tied to organizations, not stored on user itself, so you cannot have a concept of global admin or something like that, unless you use metadata for storing arbitrary key value paris), and more than once in the past weeks/months it had a downtime causing the whole app to fail. Would think twice before using it in the future.

i'm currently in the process of evaluating switching our b2b app off clerk too. a customer asked for custom roles (diverging from our default set), which is technically possible on clerk now with role sets, but it's a bit of a workaround rather than first class. thankfully i'm familiar with better auth from a side project, but migrating SSO/SCIM sounds like it might be a bit of a pain

[dead]

Re: From Supabase to Clerk to Better Auth

#136

Post by SahAssar »

ipnon wrote: post #130
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…

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.

I'm not discouraging anyone from writing your own auth, but if you have even a little bit higher requirements it becomes more complex. For example I have audited codebases where the TOTP code was enough to get a valid token (without a password, due to a bug), where there was no rate limits on password attempts and one where the password lockout system meant that you could DDoS all admin access trivially, etc, etc. That's even before you need to integrate with a third party via something like OIDC or SAML or SCIM which are probably needed for a product used by businesses these days.

It is hard for serious use-cases. That does not mean you should not do it, but know what tradeoff you are doing in the build-vs-buy equation. Know that this part of your system probably requires more testing, review and expertise than your core product.

Re: From Supabase to Clerk to Better Auth

#137

Post by colinclerk »

billybones wrote: post #85
notbekacru wrote: post #31

Earlier quoted context omitted.

> And even more users who are looking to escape. Uhm, companies like Replit and several other large startups are actually adopting Clerk. I guess if your world mainly revolves around X (formerly Twitter), it can seem like everyone is moving away from Clerk. Also, Better Auth’s X presence is pretty much centered around criticizing every auth provider out there, so the discourse there tends to skew heavily negative.

> Also, Better Auth’s X presence is pretty much centered around criticizing every auth provider out there, so the discourse there tends to skew heavily negative. This from an account created 2 hours ago, with a username that’s a negation of the BetterAuth founder… If you’re Clerk stakeholder why not just come out as yourself and engage openly!

Clerk cofounder here: I hope this isn’t a Clerk stakeholder! It’s definitely misaligned with our culture around not speaking about competitors and instead playing our own game.

Re: From Supabase to Clerk to Better Auth

#138

Post by colinclerk »

cyberax wrote: post #73
notbekacru wrote: post #31

Earlier quoted context omitted.

> And even more users who are looking to escape. Uhm, companies like Replit and several other large startups are actually adopting Clerk. I guess if your world mainly revolves around X (formerly Twitter), it can seem like everyone is moving away from Clerk. Also, Better Auth’s X presence is pretty much centered around criticizing every auth provider out there, so the discourse there tends to skew heavily negative.

Clerk looks _really_ good initially. It's perfect if you want to prototype something and not care about auth. It's only when you start getting into the details that you begin to suffer. For example, there's _still_ no way to do offline auth on mobile. So that your application could be opened if there's no connectivity at the moment. But hey, you can do the Metamask Web3 blockchain thingie! I have never used Twitter/X…

Clerk cofounder here - appreciate the feedback and forwarding to the mobile team!

Re: From Supabase to Clerk to Better Auth

#139

Post by sudoshred »

tornikeo wrote: post #35

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

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

Re: From Supabase to Clerk to Better Auth

#140

Post by MrDarcy »

Recently went with a vendor of an agentic observability and evaluation product built on Supabase and Clerk. The number of vulnerabilities and CVE’s and outright… I don’t even know the words, coming from this stack is staggering.

Be very very wary of any vendor selling something built on this Supabase + Clerk stack. That alone is a very strong indicator they do not understand basic security or data protection.

Post reply on HN