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"
From Supabase to Clerk to Better Auth
181–190 of 259 posts
Re: From Supabase to Clerk to Better Auth
#182Earlier 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.…
Re: From Supabase to Clerk to Better Auth
#183Earlier 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 ???
Re: From Supabase to Clerk to Better Auth
#184Can 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.
Re: From Supabase to Clerk to Better Auth
#185Earlier 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.…
Re: From Supabase to Clerk to Better Auth
#186Using 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…
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
#187Earlier 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.
Re: From Supabase to Clerk to Better Auth
#188Can 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…
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
#189Can 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
Of course, we're not talking about email/password with "remember me" checkbox kind of auth.
Re: From Supabase to Clerk to Better Auth
#190just beautiful. nothing to add, clap clap