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.
> Some important context is that Clerk is a major success. They just raised 50 million dollars and they have lots of satisfied users.
And even more users who are looking to escape. Clerk is just a mess. They are trying to cram EVERYTHING into their libraries: Web3 crap, Stripe, etc. Clerk's JS blob is now triggering the browser inspectors for being slow to load.
Every time when we upgraded React, Clerk libraries were the biggest pain with their transitive dependencies. We had issues with Stripe libraries with conflicting versions, etc.
And forget about debugging it. The libraries are obfuscated, and the TS code is impenetrable mess of abstractions to support "isomorphic" code that can run transparently on the frontend and backend.
And their platform itself is lacking important functionality, like freaking audit logs and versioning. Somebody (probably) accidentally changed a setting in their console, and we couldn't trace back when it happened or who did it.
Edit: oh yeah, and don't forget their unreliability. I had to wake up on Sunday to deal with Clerk failing the API calls for token refreshes last week.
Better auth is great! I love how it's way more hackable than using a something like Clerk. We were able to add a plugin to allow auth via iframe postMessage (embedded in a CRM) and everything worked seamlessly.
I enjoyed the Supabase migration article from a while ago (https://blog.val.town/blog/migrating-from-supabase) as well. There's a shortage of good, honest writing on long-term engineering decisions, please keep up the blog!
Does Better Auth still have the weird design to be everything “request header based”? I remember running admin scripts and tests to be very hacky due to it cause if you skipped that plugins wouldn’t run
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
You could almost call the comparison between Clerk and Better Auth unfair. One is a service and one is a library, apples to oranges. Any third-party service integrated into a stack is a liability, libraries as well, but to a lesser degree. It’s about time for more services to be replaced by libraries. Better Auth really shows how to do that imo, it’s a library that integrates on the frontend, backend, and database. This is why it’s so good.
This is why I'm so thankful I went with Lucia early. They sort of sunset their library and replaced it with documentation (and some small utilities) for how to manage and host authentication for yourself. It's always presented as some big, scary thing you can't manage yourself, but I found that taking the week to learn how security and basic salting works, I was able to feel more confident about how everything worked.
If anything I feel like Clerk adoption is becoming the norm in recent years. I started using it about a year ago and found it to have troublesome reliability.
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.
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?
i'm currently in the process of evaluating switching our b2b app off clerk too. a customer asked for custom roles (diverging from our default set), which is technically possible on clerk now with role sets, but it's a bit of a workaround rather than first class.
thankfully i'm familiar with better auth from a side project, but migrating SSO/SCIM sounds like it might be a bit of a pain
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 help you get your own started here: https://clerk.com/docs/guides/secure/basic-rbac
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 money by increasing risk, having people who’s job it isn’t managing and supposedly securing that information, or to have a third-party who job is literally to handle and worry about those things, who carries independent insurance, and who is on the hook if they lose customer data, and in exchange the business is simply taking the risk of associating with business that could do a poor job — which of those options sounds more appealing from a business sense? It’s a lot easier to blame someone else than earn back trust for your own major mistakes because you tried to write your own software to save a little money.
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 must as intelligent as you because I also never understood why things like supabase even exist. I believe this shows how much front-end dev world is detached from how things can simple and secure by default.
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.
People are very scared of messing up authentication and getting hacked. They would rather offload that responsibility to a third party and not think about it.
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.
The only project where this was the case that I didn't hate it was at a former employer, and it gave the responsibility of securing users to Auth0 and minimized our PII and attack surface, since even the login page was not hosted or controlled by us. Worse case you somehow hacked our users and got some free entree reward they had, otherwise good luck trying to get very little data.
It allowed us to do SSO for small one-off marketing / campaign focused sites. I could give a specific login URL and it would always log you in if you were already logged on.
Some people enjoy vendor locked managed services for their core infrastructure. Typically this decision is made when building from zero to one in resource constrained environments, and the long term play is to move to your own table/db when it becomes sustainable to do so. The only reason to move to a managed service after having done the work to setup self owned systems is when you need to either a) CYA or b) reduce headcount
It feels like a good idea when you are early on in building your product and what matters is quickly iterating on the core features that define your product.
It’s not just the table, it’s also the auth and many other things that you know you will need but you would prefer to focus on other stuff.
Almost always you start by saying that you will replace that when the time comes and you have proved you have a product and now it’s time to actually build the real thing.
Some teams do that and some other, never migrate away and that’s how the GTM of companies like Clerk works.
I'm working at a tiny non-IT company. Outsourcing this work and the security of not having my non IT trained coworkers being able to touch the server is great (but a VM would do the same ofcourse, while costing money).
Most of all, we currently don't even need paid tiers of supabase since our software is so small.
Given, I feel if you run supabase at a big company you are either lazy and probably have too much budget to spend on useless costs.
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.
> A hard lesson you learn building a complex system is that its reliability is the minimum of the combined reliability of its critical parts.
It's worse than that, the combined availability is the product of all components in the critical path. If your software, the authentication layer, and the cloud provider each have 99% availability, and any one of them can bring your service down, then your final availability is just 97%. With eleven components like that you have zero nines of availability.
That's why reducing components and going for reliable solutions is so important. I'm happy that the team took this path.
Learned this one the hard way during the last major CloudFlare outage. I don't use them, but their outage bricked my app for hours anyway because the Auth0 public keys used to verify JWTs were served behind CloudFlare, breaking the entire auth chain. Fun!
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?
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 as possible in the auth provider, but there is still some.
- Refreshing JWT access tokens every few minutes is another bug center and honestly there is no need to do this if you control your own auth.
- WorkOS does not have a complete API. It is built on the assumption that you have one product per billing account and a fixed number of environments (staging, production, and they can give you another one if you ask support). You have to whitelist redirect and other URLs in the dashboard, and there doesn't seem to be an easy way for agents to do it.
Outsourcing auth does not make much sense IMO. The less you can split your state over multiple services the fewer problems you will have. Sometimes it is inevitable, like for payments, or if you need specialized databases for performance reasons. But for auth there is really no good reason if good libraries are available. To people who say that using a service will help you get started faster, none of the problems I hit with auth services had to do with having high scale -- most of them hit before I even launched.
We're working on multi-app support. The large majority of our customers only have 1 app (ChatGPT, Claude, Cursor, etc.) but this isn't the case for developers building lots of side projects.
Also working on shipping an agent-friendly Dashboard. Stay tuned :)
Would love to hear any more feedback: mg@workos.com
81 comments
[ 3.1 ms ] story [ 81.7 ms ] threadAnd even more users who are looking to escape. Clerk is just a mess. They are trying to cram EVERYTHING into their libraries: Web3 crap, Stripe, etc. Clerk's JS blob is now triggering the browser inspectors for being slow to load.
Every time when we upgraded React, Clerk libraries were the biggest pain with their transitive dependencies. We had issues with Stripe libraries with conflicting versions, etc.
And forget about debugging it. The libraries are obfuscated, and the TS code is impenetrable mess of abstractions to support "isomorphic" code that can run transparently on the frontend and backend.
And their platform itself is lacking important functionality, like freaking audit logs and versioning. Somebody (probably) accidentally changed a setting in their console, and we couldn't trace back when it happened or who did it.
Edit: oh yeah, and don't forget their unreliability. I had to wake up on Sunday to deal with Clerk failing the API calls for token refreshes last week.
Easy to use and high reliability. Some of these other providers are not the best at reliability.
Anyone remember Auth0 and passportjs?
The churn of auth services is never ending, but I suppose so are the standards.
Heya, Auth0 is still around! They got bought by Okta in 2021 but still have a free tier and we see them in a lot of bake-offs.
- https://github.com/agoodway/introspex (generate Ecto Schemas from postgres tables)
- https://github.com/agoodway/pgrest (Supabase/PostgREST compatible query engine)
I also found this helpful in the migration: https://github.com/supabase-community/supabase-ex
Nothing for auth, I basically did a one-off script for that. Phoenix auth stuff that comes out of the box is great.
Would think twice before using it in the future.
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?
thankfully i'm familiar with better auth from a side project, but migrating SSO/SCIM sounds like it might be a bit of a pain
I think we have the most advanced RBAC system. You can even map roles from custom IdP groups via SCIM.
More info here: https://workos.com/guides/user-provisioning-scim
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 help you get your own started here: https://clerk.com/docs/guides/secure/basic-rbac
To expand a bit more: if a business is faced with a choice to save some money by increasing risk, having people who’s job it isn’t managing and supposedly securing that information, or to have a third-party who job is literally to handle and worry about those things, who carries independent insurance, and who is on the hook if they lose customer data, and in exchange the business is simply taking the risk of associating with business that could do a poor job — which of those options sounds more appealing from a business sense? It’s a lot easier to blame someone else than earn back trust for your own major mistakes because you tried to write your own software to save a little money.
That’s the SaaS value proposition.
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.
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.
It allowed us to do SSO for small one-off marketing / campaign focused sites. I could give a specific login URL and it would always log you in if you were already logged on.
It’s not just the table, it’s also the auth and many other things that you know you will need but you would prefer to focus on other stuff.
Almost always you start by saying that you will replace that when the time comes and you have proved you have a product and now it’s time to actually build the real thing.
Some teams do that and some other, never migrate away and that’s how the GTM of companies like Clerk works.
Given, I feel if you run supabase at a big company you are either lazy and probably have too much budget to spend on useless costs.
Of course, we're not talking about email/password with "remember me" checkbox kind of auth.
It's worse than that, the combined availability is the product of all components in the critical path. If your software, the authentication layer, and the cloud provider each have 99% availability, and any one of them can bring your service down, then your final availability is just 97%. With eleven components like that you have zero nines of availability.
That's why reducing components and going for reliable solutions is so important. I'm happy that the team took this path.
no need for 3rd party provider.
- Syncing external auth provider state with your user state is a bug center. It helps to keep as little state as possible in the auth provider, but there is still some. - Refreshing JWT access tokens every few minutes is another bug center and honestly there is no need to do this if you control your own auth. - WorkOS does not have a complete API. It is built on the assumption that you have one product per billing account and a fixed number of environments (staging, production, and they can give you another one if you ask support). You have to whitelist redirect and other URLs in the dashboard, and there doesn't seem to be an easy way for agents to do it.
Outsourcing auth does not make much sense IMO. The less you can split your state over multiple services the fewer problems you will have. Sometimes it is inevitable, like for payments, or if you need specialized databases for performance reasons. But for auth there is really no good reason if good libraries are available. To people who say that using a service will help you get started faster, none of the problems I hit with auth services had to do with having high scale -- most of them hit before I even launched.
We're working on multi-app support. The large majority of our customers only have 1 app (ChatGPT, Claude, Cursor, etc.) but this isn't the case for developers building lots of side projects.
Also working on shipping an agent-friendly Dashboard. Stay tuned :)
Would love to hear any more feedback: mg@workos.com