From Supabase to Clerk to Better Auth(blog.val.town) |
From Supabase to Clerk to Better Auth(blog.val.town) |
Maybe you can help me out: I still have no idea what val.town is. I guess it's an alternative to Cloudflare Workers?
So yes, like Cloudflare Workers in some ways. Or like CodePen but fullstack. Or Replit. The val town "founding poem" was:
> If GitHub Gists could run,
> And AWS Lambda were fun
Lastly - here's the law of mother nature:
Software funded by VCs will milk you and will milk you dry. Not now, not tomorrow maybe decade or two later when the hot potato being passed around reaches to the last party holding the bag that now needs its money back with all that others had their 10x returns already taken from them by soldng them at an inflated price to the last party holding the bag.
Clerk's pricing should be evidence enough.
That’s all it takes to not use their cloud at all.
I will never go back. Lets see if in 3 years I have a different opinion, but I can't imagine so.
More like "its failures are the total of its critical components' failures" when you've got two nines on your least reliable component so most likely any critical component failure will be exclusive.
E.g.: {argon2}…
¹ See what I did there?
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?
Easy to use and high reliability. Some of these other providers are not the best at reliability.
Be very very wary of any vendor selling something built on this Supabase + Clerk stack. That alone is a very strong indicator they do not understand basic security or data protection.
no need for 3rd party provider.
But in reality, I doubt they would release either of those things.
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.
fwiw, we also have entire staff dealing with SSO issues among our employees and users, despite relying on external services to handle auth.
A problem domain as complex as authentication is bound to habe issues of some sort. But I am not sure if I would be so fond of „outsourcing“ something as integral to my services as the access to these services
All you need is Apple and Google Oauth.
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.
Okay, so… what are those cases? I’m also curious.
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.
Of course, we're not talking about email/password with "remember me" checkbox kind of auth.
People not knowing what salt and pepper is... Vulnerabilities almost as if on purpose...
Perhaps it is actually not THAT hard but just like error handling, people don't want to do the unsexy parts and want to delegate those tasks to someone else perhaps. There must be a behavioral pattern there...
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.
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.
Wrote an article about that here: https://fusionauth.io/articles/authentication/fedcm (hosted at my employer's website)
Knowing every single line of code involved allowed me to add some location-based functionality for one client, provide tailored logging to meet the needs of another client, and my favorite was winning a deal against much bigger competitors by being able to integrate with an absolutely ancient legacy system.
Just like “Goto considered harmful”, DRY, YAGNI, etc - they’re great at making you slow down and think. But they’re not inviolable.
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.
I remember when they deprecated the library and instead made it a learning resource on implementing auth from scratch. Brilliant decision, much respect to the author.
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.
1. Don't roll your own crypto
2. Don't roll your own auth strategy
3. Don't Roll your own auth code
4. Don't host your own auth infrastructure.
For the last few years level 4 has been aggressively pushed with a lot of advertising spend to push people towards prohibitively expensive hosted providers. Donning a tinfoil hat for a moment, auth as a service companies have made everything seem substantially more difficult than it is too for simple needs.
Now we're seeing a correction back to 2 and 3 as people way up the risks of SaaS vs just using a easier to manage local library and discovering it's not as scary as it's been made out to be if you follow now fairly well established patterns.
the providers aren't going anywhere, people still need them for a variety of reasons but their time as the default is ending and whether this is good is to be determined.
Then when you really start thinking about it, the list of requirements grows.
Of course it’s still totally doable for an average developer, but takes time and mistakes can be catastrophic. And maybe the time is better spent developing stuff that differentiates you from others.
- 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.
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.
Edit: Meaning I would use it if you need to get up and running quickly, but it's a solid foundation to build on long-term.
I was at KubeCon EU this year (representing my employer, FusionAuth) and there were lots of folks who were running Keycloak who came and chatted with us.
It's a different set of tradeoffs than Auth0 or other SaaS services. More control, but more responsibility too.
0: https://events.linuxfoundation.org/kubecon-cloudnativecon-eu...
Would think twice before using it in the future.
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.
In both cases you are buying into somebody else's solution. That complex framework is complex because the company behind it threw everything and the kitchen sink at it. You don't actually need most of what it needs. And that company makes money by adding more crap to it, via certification, training and consulting. It's complex by design. You can't just sit down and use it. You have to study it first. Become an expert in using it. If you've ever used Keycloak, Spring Security, or similarly convoluted solutions, you know what I'm talking about.
And then that walled garden thing (auth0 or whatever is in fashion these days) is super simple to use. Just do magic steps 1 2 and 3 and you are good to go. But don't deviate from the happy path! There is a happy path. Either you are a perfect match for it or you aren't.
The middle ground is realizing that a users table with a bcrypt encrypted password column and a few other bits and bobs isn't all that hard. Building some sane flows around resetting passwords, 2FA, emailing login links, etc. Easy.
You can actually vibe code most of this stuff these days. And I've done all this manually in the past as well. I've implemented SSO, Oauth (1 & 2), OpenID Connect, etc. I've implemented API call counting, rate limiting, 2FA, etc. I use some frameworks for most of the heavy lifting and dealing with hashing, JWTs, and all the rest. Most of the rest is just simple API plumbing. Most of these flows aren't all that complex. You need good tests and a good understanding of what the system is supposed to do. But that's a constant in this space. Trying to use somebody else's really complicated solution without that is not going to be easier, better, or faster.
Using a passwordless login from scratch (magic link + Google OAuth2, sessions stored in Postgres without an external auth vendor) gets us around that altogether. The fears about why one would avoid it are generally not justified. Deliverability is the only true problem. Address that, with a proper provider for transactions, and we’re in boring territory – which is the most delightful kind.
To move from Clerk to Better Auth is logical if the choice is between sovereignty and convenience. It’s the core problem that any group doesn’t want to confront right away: “How much of this am I truly willing to own?”
- 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.
just beautiful. nothing to add, clap clap
The reason why it work for me is that it's finally a open-source solution that is on par or better with commercial. When I've selected Clerk originally the reason was that there wasn't open-source alternative, and I won't roll my own auth, I'm not suicidal. But now? I really don't see a single reason why I would pick Clerk, Auth0, Kinde, ...
Even if done for fun/learning, it can teach how the details of auth work to better appreciate and understand how other systems work and what to look out for.
I prefer to use existing things if possible, but if it was getting unreasonable to get it how it was needed, it wouldn't be off the table.
It is hard for serious use-cases. That does not mean you should not do it, but know what tradeoff you are doing in the build-vs-buy equation. Know that this part of your system probably requires more testing, review and expertise than your core product.
And the cookies are not difficult on a technical level, you just have to spend time understanding the threat models and mapping those models correctly onto your own app.
I am with you on this.
Uhm, companies like Replit and several other large startups are actually adopting Clerk. I guess if your world mainly revolves around X (formerly Twitter), it can seem like everyone is moving away from Clerk.
Also, Better Auth’s X presence is pretty much centered around criticizing every auth provider out there, so the discourse there tends to skew heavily negative.
This from an account created 2 hours ago, with a username that’s a negation of the BetterAuth founder…
If you’re Clerk stakeholder why not just come out as yourself and engage openly!
It's only when you start getting into the details that you begin to suffer. For example, there's _still_ no way to do offline auth on mobile. So that your application could be opened if there's no connectivity at the moment. But hey, you can do the Metamask Web3 blockchain thingie!
I have never used Twitter/X, and I don't even have an account there. I'm purely talking about my personal experience and the experience of other companies that I know personally.
> Also, Better Auth’s X presence is pretty much centered around criticizing every auth provider out there, so the discourse there tends to skew heavily negative.
They are actually not wrong. Auth is not such a hard task, it's just a lot of drudgery that detracts you from the actual goal of your company. But it's critical functionality that MUST ALWAYS WORK, before all else. And Clerk just fails this test.
I'm switching my company to Logto (it's lightweight and when something breaks, I know how to pick up the pieces), so I don't even have an opinion on Better Auth.
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
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?
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.
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
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.
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?
Also design wise, the main logo item (vortex looking thingy) is a tad bit complex, maybe think about a redesign focused on making it more simple/recognizable. The rotating dashes on the landing page hero are a good motif though, so I'd lean into that.
Also noticed that on this page: https://fusionauth.io/tech-papers/winter-2026-g2-fusionauth-... the form under "To get this tech paper complete the form below." doesn't load on Firefox with Enhanced Tracking Protection enabled. Disabling it causes the form to load though.
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
If you're willing to make a third party SaaS's uptime the ceiling for your own org, you can delegate auth. Github might not be a good choice for SSO.
If you're not threatened by per-user-per-month fees, you can delegate auth.
If your threat model is compatible with a third party having visibility into your user's network location and the frequency and duration of their activities across your org, you can delegate auth. (Okta will probably not inform your competitor that your main sales guy is in North Carolina this week and has logged in from the conference room wifi of your competitor's main client.)
If you can trust the third party to not allow an interloper to bypass your requirements, you can delegate auth.
You're not a house builder, you're a widget maker who needs a house to live in. Auth is almost never your startup's core competency or offering. Spending one of your very valuable five engineers on the auth tarpit while you lose deals because SSO is hard could be life and death for you.
It’s humorous that these conclusions are that the only option is SaaS or write it yourself, while my comments were about not doing things yourself, not that a SaaS is the only answer. Interesting that is how you felt the need to take it.
People are rarely as clever as they think they are at preventing others from doing something, while others only need to find one thing wrong. “Write it myself” is about the dumbest answer to that problem if you do not have the same level of resources to commit to that specific problem as can be solved by someone else.
Not really a hot take to state something so…basic..but you’re welcome to conclude what you like.
1. store everything user related in there, rely on APIs or syncing if the application needs user attributes
2. store nearly nothing in there, just credentials, MFA, account recovery info and anything else related to authentication. All profile data is stored in each app
Both can work, they just have tradeoffs.
Then customers come and ask for SSO, SAML, OIDC, their niche auth protocol, 2FA, Pass phrases, etc...
And now your auth is a mess and a dedicated job to maintain and evolve.
At least to me it sounded very much like they were talking about mobile.
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
Oh you still have to build the auth system yourself? Well maybe a realtor does sound good now.
What happened there?
The only solution in such a case would be to manually remove the lockout flags in the db.
Does Better Auth offer this? Or any other auth libraries or solutions? I haven't heard of any, but haven't done an intensive look either.
I suppose you could do something with a cached JWT or cached password hash (though sending a password hash to a mobile client spooks me).
I'm in the space and interested in learning more.
This is supported by Better Auth out-of-the box. It doesn't hide these kinds of stuff from you.
I wasn't able to find the Better Auth docs about this use case, can you share them here please?
> There must be a behavioral pattern there...
The pattern is that your comment is very far from reality.
If we deal with the intricacies of rbac, abac, acl mixed with scopes ,sso, saml, oidc, mfa, etc... I don't find these too conceptually, complex.
I mean, it should be avoidable complexity. Most of the complexity is technical debt, bad implementations etc. But by itself it is not THAT complex.
And this someone's name begins with "Cla" and ends with "ude".
So we're going to have a lot more vulnerabilities in the auth code going forward.
We will see I guess... It could also be an opportunity to audit systems in automated ways.
Whether it's painful to put in later or not is sadly nothing that the managers and executives concern themselves with.
Having had the chance to try and implement libraries to interface with those systems a couple times, most people agree that implementations are far from perfect or streamlined. We call this incidental/accidental complexity.
Sometimes that's just an opportunity
Technically true, because Google's core product is ads. Also fundamentally wrong, because Gmail serves as a massive source of ad targeting information, in addition to being a high-engagement canvas to display those ads.
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. Does it feel bad knowing I am in control and wont have to offload to 3rd party vendors? Hell no.
You don't have to use a 3rd party service for OAuth. You can do it in house.
I want intentional users not the ones that click "sign up with google", try out the app once and never come back. Also I don't have the time to learn how to properly integrate more auth methods into my app. I want my own user table, I want predictability on how a user model looks and I want to be in control of everything.
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.
https://workos.com/docs/directory-sync/attributes
Also certificate renewal flows:
https://workos.com/changelog/certificate-renewal-flow
(I'm the founder.)
Auth isn’t something I want to think about. There are a lot of hidden traps.
Ad display I'll still grant you of course.
It was an unproven long shot when they built it.