Live data from Hacker News

From Supabase to Clerk to Better Auth

blog.val.town

181–190 of 259 posts

Re: From Supabase to Clerk to Better Auth

#181

Earlier quoted context omitted.

Couldn’t you get Claude to go into Supabase’s auth code and make your custom like their’s but adapted to your stack?

"Claude, make my custom like their's but adapted to my stack. Make no mistakes"

You’ll have to drive the agent to do it, not a one-shot task. It’ll also require you to understand your codebase.

Re: From Supabase to Clerk to Better Auth

#182

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

Same here, Just email + password, no google dependency initially. If more users ask we will think of it. but again you don't need a cloud vendor for all this.

Re: From Supabase to Clerk to Better Auth

#183
post #159
post #132

Earlier quoted context omitted.

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…

And now the libraries have been outsourced to saas companies because ???

Because we need to move faster and cheaper, that's the future

Re: From Supabase to Clerk to Better Auth

#184

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

People are afraid to touch dangerous things, like passwords and payment systems. Depending on their skill level, they should indeed be afraid.

I roll both of these at work, from auth to cashless payments to regular online payments. It's not as hard as people make it out to be. Probably a lot harder at big companies with huge attack surfaces and attention though.

Re: From Supabase to Clerk to Better Auth

#185

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

That's great for B2C, but B2B demands SSO.

Re: From Supabase to Clerk to Better Auth

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

You're conflating authentication and authorization. Clerk is an authentication provider for the most part, it concerns itself with telling you who the user is. Based on that your business logic should be able to determine what they are entitled to do. They offer a Org/Role based RBAC but since you're doing something different I'd just scrap it entirely and roll your own authorization flow, they have a guide that'll h…

For the most part is the troubling part :D Ideally there is one vendor that handles this, as a team we don't want to deal with Clerk + something else just for RBAC, so naturally we tried to solve it via Clerk.

Their recommended guide is to pretty much have your own RBAC using key value pairs they offer, which is IMO relatively lazy and most teams come up with this on their own anyway. I wish they offered something that is not prone to someone editing a JSON input manually on their website. You can do basic stuff with it, build tooling around it, but again the fundamental model of only user having a role on the org level has its limitations.

Re: From Supabase to Clerk to Better Auth

#187

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

That's great for B2C, but B2B demands SSO.

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.

Re: From Supabase to Clerk to Better Auth

#188

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

Why pay someone to build a house? I’m sure you could do it yourself…but that doesn’t mean that is the best use of your time in all cases. The analogy is basic but apt; not everyone needs or wants to run (or create) every mechanism. I don’t do all of my own hosting either and it’s not because I couldn’t, it’s that it isn’t worthwhile in my cases. To expand a bit more: if a business is faced with a choice to save some…

This is such an absurd take.

For starters, if I'm a "house builder" by trade, then yeah, I am going to build the house myself. Otherwise, why should the client pay me, and not the guy I'm subcontracting?

Secondly, there is no such thing as a "house builder" profession. It consists of a lot of different trades people, some of them having legal power to sign off your house build (for example an electrician). Now, we could try to push for something similar in software engineering, and say require you to have an "authentication engineering certificate" in order to handle code related to auth, and only a person holding the certificate can allow such code for production use. But I'm pretty sure all the vibe coders and tech bros will cry how unfair and bureaucratic the system is.

But of course the entire SWE profession is based on grifting, and extracting as much money as possible from the customers while cutting the costs. If you are so afraid to save passwords to a database, then at least don't call yourself a software engineer.

Re: From Supabase to Clerk to Better Auth

#189

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

Because auth is a productivity tarpit. Anything plan on doing with auth looks simple but almost never is. Homegrown auth can easily sunk half of your dev and support teams.

Of course, we're not talking about email/password with "remember me" checkbox kind of auth.

Re: From Supabase to Clerk to Better Auth

#190
> And reluctantly I have to hand it to the LLMs here: with the augmentation of the robots, we were able to take the more complex route of supporting both Better Auth and Clerk for a transitional period of two weeks. Every endpoint that handled authentication would accept either kind of cookie, and users slowly moved over to Better Auth because that was the kind of session that the sign-in page provided. Like anything related to security, close reading, rewriting, and testing of all of the code was necessary to make sure we didn't self-own, and the eventual pure-Better Auth auth was handwritten entirely.

just beautiful. nothing to add, clap clap

Post reply on HN