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

241–250 of 259 posts

Re: From Supabase to Clerk to Better Auth

#241

Post by joekrill »

> Better Auth checked a lot of boxes right out of the gate: high code quality,

Maybe I have high standards, but I absolutely would not describe Better Auth as having "high code quality". It has certainly been improving, but when I first looked at this project it felt really rushed and thrown together, with little automated tests. There's was virtually no logging last I looked, so there's little options to monitor what's happening. I think they've added hooks now so you can "bring your own logging", I guess. And they finally added audit logs but that's only if you use their managed services.

Having said that, I actually use Better Auth, and I'm a huge fan despite those criticisms. I love that it's open source and extendable (there's a free 3rd-party audit logging addon, actually). It's super straight-forward to implement compared with similar products (Ory Kratos, Keycloak, etc). You don't even need a separate DB if you don't want - you can have it create tables in your existing database. And it _is_ improving quickly.

Re: From Supabase to Clerk to Better Auth

#242

Post by grinich »

whstl wrote: post #235
hylaride wrote: post #216

Earlier quoted context omitted.

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.

WorkOS has a built-in workflow for all the complex SAML/SCIM attribute mapping.

https://workos.com/docs/directory-sync/attributes

Also certificate renewal flows:

https://workos.com/changelog/certificate-renewal-flow

(I'm the founder.)

Re: From Supabase to Clerk to Better Auth

#243

Post by SahAssar »

Capricorn2481 wrote: post #215
SahAssar wrote: post #136

Earlier quoted context omitted.

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

> and one where the password lockout system meant that you could DDoS all admin access trivially What happened there?

Password attempt lockouts where not scoped to anything besides the account itself. By just spamming a few attempts per account you could lock all admin accounts meaning that there was no admin to unlock the other accounts.

The only solution in such a case would be to manually remove the lockout flags in the db.

Re: From Supabase to Clerk to Better Auth

#244

Post by oncensher »

mooreds wrote: post #99
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 regist…

I think depending on how much integration you want, either option 1 or treating the multiple applications as a single application that can do multiple things could be good options. Also, option 2 could still avoid having to worry about your auth service going down or rate limiting you. And you could avoid JWT headaches.

Perhaps there is also an option 4, which is option 1 plus a shared user information database for things like Stripe account, profile picture, etc. That is more complex obviously, but it would still solve the issues I had with WorkOS. In particular, I think it would mostly solve "syncing external auth provider state with your user state is a bug center." In particular, the awkwardness around sequencing of account creation and deletion would largely go away because that would be managed as in 1, and the extra shared information would be just that. (But maybe you would want to delete it if the user deletes all their accounts?) And you wouldn't be forced to use webhooks to get updates to shared user state. You could put it in a shared Convex database, for instance, or use some other solution of your choosing.

Re: From Supabase to Clerk to Better Auth

#245

Post by anotherevan »

nkmnz wrote: post #229

For me, the real issue of switching auth providers hasn’t been touched: do thy all use the same hashing functions or how did they move the password hash column across providers? Running them in parallel and rehashing on first login?

If the provider is worth its salt¹ it will prefix the stored password with the hash that was used. That way it can update the hash when the user next logs in if it is out of date.

E.g.: {argon2}…

¹ See what I did there?

Re: From Supabase to Clerk to Better Auth

#246

Post by SkyPuncher »

sreekanth850 wrote: post #160
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.

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?

Not sure what laziness has to do with this. It’s all about tradeoffs.

Auth isn’t something I want to think about. There are a lot of hidden traps.

Re: From Supabase to Clerk to Better Auth

#247

Post by nkmnz »

anotherevan wrote: post #245
nkmnz wrote: post #229

For me, the real issue of switching auth providers hasn’t been touched: do thy all use the same hashing functions or how did they move the password hash column across providers? Running them in parallel and rehashing on first login?

If the provider is worth its salt¹ it will prefix the stored password with the hash that was used. That way it can update the hash when the user next logs in if it is out of date. E.g.: {argon2}… ¹ See what I did there?

I see what you did there, but I assume you mean "prefix the stored hash with the algorithm that was used", right?

I still don't know how this would help with a migration, though. They would still need to run both auth systems in parallel until every single user has logged in again - or force everyone to create a new password. Right?

Re: From Supabase to Clerk to Better Auth

#248

Post by anotherevan »

nkmnz wrote: post #247
anotherevan wrote: post #245

Earlier quoted context omitted.

If the provider is worth its salt¹ it will prefix the stored password with the hash that was used. That way it can update the hash when the user next logs in if it is out of date. E.g.: {argon2}… ¹ See what I did there?

I see what you did there , but I assume you mean "prefix the stored hash with the algorithm that was used", right? I still don't know how this would help with a migration, though. They would still need to run both auth systems in parallel until every single user has logged in again - or force everyone to create a new password. Right?

Assuming you get get access to the hashed passwords the other party used as part of the migration data, and you know what hash was used for them, then there's nothing to stop you using them yourself.

But in reality, I doubt they would release either of those things.

Re: From Supabase to Clerk to Better Auth

#249

Post by mikelward »

moomoo11 wrote: post #15

I've just stuck with Auth0 for years now. Easy to use and high reliability. Some of these other providers are not the best at reliability.

Auth0 breaks password managers. Could you upvote https://community.auth0.com/t/request-addition-to-public-suf....
Post reply on HN