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

231–240 of 259 posts

Re: From Supabase to Clerk to Better Auth

#231

Post by ButyTh0 »

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.

Sure, now it is.

It was an unproven long shot when they built it.

Re: From Supabase to Clerk to Better Auth

#232

Post by mooreds »

mooreds wrote: post #150
cyberax wrote: post #110

Earlier quoted context omitted.

We ended up caching the credentials and the JWT refresh token from Clerk, and then manually requesting the access token using the Clerk's sparsely documented frontend API. Except that to do this with Clerk, we needed to fake the cache API and then pluck the token out of the undocumented "__clerk_client_jwt" key. This is supported by Better Auth out-of-the box. It doesn't hide these kinds of stuff from you.

Sounds tough. I'd love to learn more. I wasn't able to find the Better Auth docs about this use case, can you share them here please?

I took a pass at what this would look like for FusionAuth (my employer): https://fusionauth.io/community/forum/topic/3129/offline-acc...

Re: From Supabase to Clerk to Better Auth

#233

Post by mooreds »

nateb2022 wrote: post #163
mooreds wrote: post #100

Earlier quoted context omitted.

Disclaimer: I work for a Clerk competitor, FusionAuth. Can you share your evaluation process? I'm always curious how folks evaluate auth providers. Did you do a spike? Full POC across a couple of solutions? Rely on a recommendation from a friend? Run through a quickstart and decide it worked and you had bigger problems to solve? Something else?

Nice website! I like your docs too. Small tip though, the couple obviously AI-written articles (ostensibly for SEO purposes) in your footer are a little of a code smell. Also design wise, the main logo item (vortex looking thingy) is a tad bit complex, maybe think about a redesign focused on making it more simple/recognizable. The rotating dashes on the landing page hero are a good motif though, so I'd lean into that…

Thanks for the feedback, I'll pass it on!

Re: From Supabase to Clerk to Better Auth

#234

Post by zarzavat »

sevenzero wrote: post #179
sreekanth850 wrote: post #160

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

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

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.

Re: From Supabase to Clerk to Better Auth

#235

Post by whstl »

hylaride wrote: post #216
sreekanth850 wrote: post #160

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

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.

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.

Re: From Supabase to Clerk to Better Auth

#236

Post by drbscl »

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

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

Re: From Supabase to Clerk to Better Auth

#237

Post by sevenzero »

zarzavat wrote: post #234
sevenzero wrote: post #179

Earlier quoted context omitted.

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

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.

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.

Re: From Supabase to Clerk to Better Auth

#238

Post by sevenzero »

Orygin wrote: post #199
sevenzero wrote: post #187

Earlier quoted context omitted.

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

Do permissions follow the same model everywhere with SSO or do you now have to set up permission logic everywhere for new customers? Like company A uses "admin" as role while company B uses "management" for essentially the same role?

Re: From Supabase to Clerk to Better Auth

#239

Post by cpursley »

mvkel wrote: post #37
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

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

Mature frameworks generally handle auth out of the box.

Re: From Supabase to Clerk to Better Auth

#240

Post by tornikeo »

oompydoompy74 wrote: post #38
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

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

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