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

91–100 of 259 posts

Re: From Supabase to Clerk to Better Auth

#91

Post by allthetime »

zuzululu wrote: post #2

what do you get from Better Auth btw? When I used it last year, I still found it lacking and it seemed to be run by one guy.

I’m setting up a new system (Auth for user facing app, client facing dashboards, internal tool usage, etc.)… it has anonymous app users who can be upgraded to real users upon Auth, organizations, multi-tenant capabilities, all kinda of sign in options… haven’t written a single line of special code this is all handled by included plugins and defaults. It just works and I own all the data.

Re: From Supabase to Clerk to Better Auth

#93

Post by sudb »

manishsharan wrote: post #57

Has anyone used Keycloak for actual production? I have often thought about it but I stick to Auth0 just because I don't know if Keycloak has a good track record?

Yes! I used keycloak for multitenant auth and it worked fine - a little dated but functional. Nowadays I'd probably stick to something like Clerk/BetterAuth/Supertokens.

Re: From Supabase to Clerk to Better Auth

#94

Post by jonas21 »

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

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.

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.

Re: From Supabase to Clerk to Better Auth

#95

Post by mooreds »

impulser_ wrote: post #81
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.

Majority of apps are B2C apps, they don't need any of this. All you need is Apple and Google Oauth.

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

Re: From Supabase to Clerk to Better Auth

#96

Post by mooreds »

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

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.

Re: From Supabase to Clerk to Better Auth

#97

Post by mooreds »

rbbydotdev wrote: post #22
bekacru wrote: post #19

Hey, Bereket from Better Auth here. I started Better Auth to solve this exact issue for myself, and it later turned into a company. It always give me joy to just see others getting the same value from it :) There is a lot to work on, would love to know what we can improve

Do you think the complexity of auth in the browser, is because browsers don't do enough?

FedCM might be of interest to you. It's one effort to make browsers do more around authentication.

Wrote an article about that here: https://fusionauth.io/articles/authentication/fedcm (hosted at my employer's website)

Re: From Supabase to Clerk to Better Auth

#98

Post by behailu »

coreylane wrote: post #74
behailu wrote: post #58

Earlier quoted context omitted.

Hey hey! Qq: you guys plan to support Python backends or is there a way for us to do this?

Works fine with my fastapi backend using the JWT plugin. I run better-auth as a standalone service. https://better-auth.com/docs/plugins/jwt

Aha very cool thanks

Re: From Supabase to Clerk to Better Auth

#99

Post by mooreds »

oncensher wrote: post #71

Had a similar journey recently. Started with Stack Auth, found it unusable in production due to extremely hard rate limits and bad performance even when not rate limited. Switched to WorkOS AuthKit, which works much better and supports useful enterprise features. But inclined to BetterAuth for new projects. - Syncing external auth provider state with your user state is a bug center. It helps to keep as little state a…

> Outsourcing auth does not make much sense IMO. The less you can split your state over multiple services the fewer problems you will have.

I agree with the general principle. Fewer moving pieces make for more stable applications ("choose boring technology"[0]).

However, I was wondering what you do when you have more than one application that the same userbase wants to access. I can see 3 options:

1. make them register/have credentials for each application (not a great user experience)

2. use a standalone auth server and deal with the increased complexity

3. pick one of your applications to 'own auth' and have the other applications delegate to it. congrats, you've just invented a standalone auth server that is coupled to one of your apps

What am I missing?

0: https://boringtechnology.club/

Re: From Supabase to Clerk to Better Auth

#100

Post by mooreds »

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.

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?

Post reply on HN