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
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?
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. Does it feel bad knowing I am in control and wont have to offload to 3rd party vendors? Hell no.
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.
Great for you but that's not the case for a lot of B2B contracts we have. A lot of them require integrating with their SSO, not just for login but for permissions too
> 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
There is a trust component for sure, but a business requires assessing the value of time against revenue. I can say for our org that using an off the shelf solution like Clerk saves us time and money and we believe the risk is very small relative to the savings. Maybe the cost for you is not large right now, but when you've got 20 enterprise customers all asking for specific OIDC integrations configured with Private Link, custom domains, and private clusters, an auth solution starts looking mighty fine.
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.
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.
If you’re implying that people should __always__ roll their own services and never vendor out non-core parts, the security industry would love to learn where you work.
> Okay, so… what are those cases? I’m also curious.
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.
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.
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.
I wonder if it is not people being notoriously lazy or clueless at an astonishing degree. How often do you hear that password were saved in plaintext? Surprisingly high in this day and age.
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...
Don't you wanna level up your career to become an architect? You can draw a box, call it "User Management" and slap "Clerk" or some other SaaS on it, and assume it's managed for you. This allows you to shove whatever requirements you want in that magic blackbox as you feel "it doesn't bring value" for you to implement.
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.
Do you say the same about AWS RDS. Are you saying VMs is all you need and it is a doddle for anyone with FE only experience to set up, maintain and scale.
Yeah you’re a bit confused. Supabase has nothing to do with frontend other than providing SDKs and some frontend components to integrate with their backend.
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.
Unfortunately this is a common premise and on surface its a good idea too to let a expert in particular domain handle it. Where it gets muddy is when this third party are themselves learners and just see this as a good business opportunity
I would disagree here. You probably need OAuth with popular social services and implement username, password or OTP-based auth overall. For an MVP, you don't need to care about more details beyond this; it is hardly 10% of the entire effort, if not 5%.
Social logins, email logins, password resets, multi-tenant, organizations, many to many users to organizations, etc etc. Not necessary for MVP, but can definitely be painful hacking in later if the MVP hits.
What you are talking about is in a large part authentication. You can do authentication using an external service and still have your user table locally. You can also do authorization locally with a local session table while leaving authentication to a SaaS.
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.
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.
That's what they did. They migrated to Better Auth, which stores everything in your DB. It's the equivalent of Django auth for the Typescript ecosystem.
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.
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
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.
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.
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.
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
I think auth is complicated outside of browsers too. But browsers do make some things uniquely confusing, especially cookies and general security primitives are full of footguns
So let me be the one to invite ridicule and scorn by admitting I wrote my own auth code. It was fiddly and boring at the same time. It also wasn’t rocket science, and it works well. I’ll be the first to admit that there are cases where this is a bad idea, I’m just responding to the chants of never roll your own auth.
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.
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 harder to do.)
Username and password as the only option to authenticate is really getting obsolete. You need to support social login, passkey, email links, maybe SMS or some other less secure methods depending on your target market… and more often also new standards like verifiable credentials with wallets managing credentials, including logins. Good luck writing your own implementations.
I recently worked at a stupid startup where the entire logic of the app was basically delegated to several third-party services out there. It felt like an absolute piece of shit overall. Following the flow of things end-to-end was a nightmare. It was so stupid because the so-called co-founder PM at that company thought it would be cool to keep doing that.
It's not that crazy. It can take time to do and get right, and is time away from other things.
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.
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. That's even before you need to integrate with a third party via something like OIDC or SAML or SCIM which are probably needed for a product used by businesses these days.
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.
Cookie management and CSRF stuff harder to get right, hashing passwords is completely trivial with and library.
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 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!
> 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!
Notable that in each step, there’s an added abstraction; specifically, an authentication abstraction is the hardest one to reverse.
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?”
The auth migration cycle is the startup version of moving apartments. You swear each time will be the last, you lose stuff in the transition, and somehow the new place has the exact same problems as the old one but in different rooms.
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.
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 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.
I think it's a correction, There's multiple levels of interpretation:
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.
It’s likely because the quick thought is that auth is just user table with hashed password.
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.
This sounds like moving the problem, not solving it. I've been doing server based systems since forever and sso is this big complicated topic where people seem to bias to using either really complicated and convoluted enterprise solutions or some walled garden with lots of limitations.
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.
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.
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.
> 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 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
I've recently switched from Clerk to BetterAuth as well and it's really good and definitely would recommend to anyone. It supports more things I need, it's more reliable, and much cheaper.
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, ...
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.
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
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.
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?
Nice website! I like your docs too. Small tip though, the couple obviously AI-written articles (ostensibly for SEO purposes) in your footer are a little of a code smell.
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.
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
Super validating, as someone who was recently tempted to use Supabase for a project and decided to give Better Auth a shot instead. It's really made things super simple so far to the point I was semi-worried I'd missed a crucial step. But nope, they just thought of everything.
> A hard lesson you learn building a complex system is that its reliability is the minimum of the combined reliability of its critical parts.
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.
Lol wut? you get all of your auth data in your own db in 1 cli command. You are not tied to any on db provider. On top of that you get hundreds of auth features like oauth providers (I use it to allow users to log in via google, apple, github) and the best part it's free. Not saying Supabase and Clerk are bad, but they cost money. With better auth you pay exactly $0 for all of this.
I’ve looked at these auth providers many times over the years and I just don’t get the value. It takes me a couple of minutes to set up auth. Why would I want a dependency? It doesn’t help me with the hardest part which is configuring Google and Apple sign in stuff on Google and Apple. I just don’t get it.
I use better auth for a side project i'm working on. It's open source, you can pay them to manage your user/auth tables if you want or you can run it all on your own db.
Sure, I guess if I'm using a web framework that is not quite batteries included, that makes sense, but Django, ASP .NET Core, Ruby on Rails, and so many others are open source and have authentication / users / roles baked in out of the box.
I remember Laravel with Socialite [0]. Laravel is what I usually reach for Web SaaS MVP. You only need a VPS and a managed database for testing out the market and can scale a lot without increasing expenses that much..
Lol, I developed for entrepreneurs who mostly wanted a working proof of concept of their ideas. I guess now you can vibecode them with SaaS for core technical needs.
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.
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.
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
My biggest question, that I didn’t see answered, is how the transition comes to an end. If creds aren’t in your system, how well do they transfer? Does it require user involvement? What if they don’t fast enough? What about complex integrations like SSO, SCIM, and passkeys (which are domain scoped)?
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.
Recently went with a vendor of an agentic observability and evaluation product built on Supabase and Clerk. The number of vulnerabilities and CVE’s and outright… I don’t even know the words, coming from this stack is staggering.
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.
> 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.
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.
> 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!
Clerk cofounder here: I hope this isn’t a Clerk stakeholder! It’s definitely misaligned with our culture around not speaking about competitors and instead playing our own game.
Clerk looks _really_ good initially. It's perfect if you want to prototype something and not care about auth.
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 ended up caching the credentials and the JWT refresh token from Clerk, and then manually requesting the access token using the Clerk's sparsely documented frontend API. Except that to do this with Clerk, we needed to fake the cache API and then pluck the token out of the undocumented "__clerk_client_jwt" key.
This is supported by Better Auth out-of-the box. It doesn't hide these kinds of stuff from you.
Is that the new library that came out in rails 8? Saw someone present on that at RailsConf 2025 and it seemed like a great solution for all rails apps. Hope it leads that ecosystem to get rid of devise (which I always found confusing).
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?
You might be interested in some of the presentations at KeyConf[0]. You can also get some real world stories from the Reddit[1].
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.
I've seen it used in production by larger orgs. The scale where you plan for around 6 months of migration, customization and integration of your legacy zoo with 7 different user account DBs. On one hand, all of these projects were successful and now run it in production. On the other, they all really needed the 6 months to whip it into shape.
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.
Yes! I used keycloak for multitenant auth and it worked fine - a little dated but functional. Nowadays I'd probably stick to something like Clerk/BetterAuth/Supertokens.
Hey, I work at Val Town, and we definitely struggle to describe what it is because the platform is so broad, but I'll try: a javascript code editor in the browser that auto-deploys that code to our servers whenever you edit a file. You can run code by clicking a button, on a cron, via HTTP. And there's other stuff like SQLite and blob storage
So yes, like Cloudflare Workers in some ways. Or like CodePen but fullstack. Or Replit. The val town "founding poem" was:
This comment thread was a nudge to push out a quick experimental change to the val.town landing page, so thank you. Very open to feedback on that messaging if anyone has any. Most customers these days ask about using val town with claude code, so you could also think of us as a deployment platform for vibe coded apps
That's a good question, I was having a hard time figuring that out myself. They call themselves the "zapier" for developers. In reality it seems kinda like a FaaS but idk. They have a code intelligence product that seems like a FIM autocomplete. Very confusing product suite.
Never outsource your auth no matter what unless you're vibe coding and it doesn't matter. If that's the case, don't put auth in at all because it's just you anyway or just use vibe coded password lookups from database at that point.
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.
You can literally plug the Better Auth libraries into a little Node server and run it as a separate auth server for free, forever, same as if you used a Django or Rails deployment for that purpose.
That’s all it takes to not use their cloud at all.
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
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?
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. Does it feel bad knowing I am in control and wont have to offload to 3rd party vendors? Hell no.
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.
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.
Great for you but that's not the case for a lot of B2B contracts we have. A lot of them require integrating with their SSO, not just for login but for permissions too
Well the disadvantage is that you're responsible for your companies keycloak.
Exactly. Do you want to become ops? Because that's how you become an ops team.
> 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
There is a trust component for sure, but a business requires assessing the value of time against revenue. I can say for our org that using an off the shelf solution like Clerk saves us time and money and we believe the risk is very small relative to the savings. Maybe the cost for you is not large right now, but when you've got 20 enterprise customers all asking for specific OIDC integrations configured with Private Link, custom domains, and private clusters, an auth solution starts looking mighty fine.
"home built auth system" is bound to have "random SSO issues". You fix them, that's how things mature.
Supabase's auth is MIT licensed and OSS, is it not?
https://github.com/supabase/auth/blob/master/LICENSE
Supabase is OSS but it's a real pain to actually self host it
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.
This is not funny because people are doing that for real.
Exhibit A, mi.
And don’t hallucinate.
Yep, it’s just a drag. It’s not our core product value so any effort we put into it is a drag.
Rather than just use an email solution Google built GMail into a massive email solution despite it not being a core product
Sometimes that's just an opportunity
> ... not being a core product
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.
Google has not been scanning gmail mails for ad targeting since 2017. I think after 9 years we can finally let that one go.
Ad display I'll still grant you of course.
I'm guessing they simply didnt want to spend the time and money doing that
Possibly didn’t want to accept the additional risk that comes with rolling your own auth as well.
Is this perhaps a reason to have a Users table that is separate from the table of data on how you authenticate that user?
That’s when you install Keycloak.
Just use Ory Kratos and self host it.
is it just me? who just uses magic links delivered via email or telegram as backup?
Majority of apps are B2C apps, they don't need any of this.
All you need is Apple and Google Oauth.
If you are just starting out its probably a good idea. Think about the use case when google bans either your app or bans your app user?
Then your business is entirely screwed anyway because you've just lost half the market
At least to me it sounded very much like they were talking about mobile.
It depends on your use case.
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
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.
That’s the SaaS value proposition.
I see Postgres etc as the builder. Supabase is more like the realtor; a middle man extracting profits and complicating the situation.
Does Postgres talk OpenID connect directly? Does it integrate SAML easily?
Oh you still have to build the auth system yourself? Well maybe a realtor does sound good now.
This comment is more ridiculous than ever in 2026.
If you’re implying that people should __always__ roll their own services and never vendor out non-core parts, the security industry would love to learn where you work.
Yes the analogy doesn't work here because that is much more cost prohibitive and labor intensive.
Because of AI or because hackers are hyper targeting infra clusters?
Emperor, meet clothes.
>that doesn’t mean it’s the best use of your time in all cases
Okay, so… what are those cases? I’m also curious.
> Okay, so… what are those cases? I’m also curious.
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.
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.
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.
I wonder if it is not people being notoriously lazy or clueless at an astonishing degree. How often do you hear that password were saved in plaintext? Surprisingly high in this day and age.
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...
Your comment has a bit of an inexperienced smell. Business auth infinitely more complex than saving a user and salting/hashing his password.
> There must be a behavioral pattern there...
The pattern is that your comment is very far from reality.
> want to delegate those tasks to someone else perhaps
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.
Don't you wanna level up your career to become an architect? You can draw a box, call it "User Management" and slap "Clerk" or some other SaaS on it, and assume it's managed for you. This allows you to shove whatever requirements you want in that magic blackbox as you feel "it doesn't bring value" for you to implement.
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.
Do you say the same about AWS RDS. Are you saying VMs is all you need and it is a doddle for anyone with FE only experience to set up, maintain and scale.
Yes many people do say the same about AWS RDS.
Yeah you’re a bit confused. Supabase has nothing to do with frontend other than providing SDKs and some frontend components to integrate with their backend.
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.
Unfortunately this is a common premise and on surface its a good idea too to let a expert in particular domain handle it. Where it gets muddy is when this third party are themselves learners and just see this as a good business opportunity
BetterAuth is users in your own database. So you don’t have to!
Start any greenfield project, hand-coded auth takes up 50% of the development time of the entire MVP
I would disagree here. You probably need OAuth with popular social services and implement username, password or OTP-based auth overall. For an MVP, you don't need to care about more details beyond this; it is hardly 10% of the entire effort, if not 5%.
I feel seen. It's compounded if you also need to add HIPAA row-level security compliance that spans to every form of resource.
…use Django, install auth modules
It takes like an hour. So that's a quick mvp then
Social logins, email logins, password resets, multi-tenant, organizations, many to many users to organizations, etc etc. Not necessary for MVP, but can definitely be painful hacking in later if the MVP hits.
What you are talking about is in a large part authentication. You can do authentication using an external service and still have your user table locally. You can also do authorization locally with a local session table while leaving authentication to a SaaS.
By the time you're so big you need all of that, there will be other people at the table to "hack that in".
I strongly disagree. If you’re selling to other businesses, much of that is an expectation.
Social logins, multi-tenant and organizations are very far from table-stakes for an MVP.
Whether it's painful to put in later or not is sadly nothing that the managers and executives concern themselves with.
Depends on the company and product. The SSO/Social login, multi tenant and multi platform are indeed needed for my MVP.
All I am seeing here is Django modules
Django, Rails etc handles this.
So... you just have to not build your web app in the most popular web app language? Somehow i think there will be big time debt from that decision
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.
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.
That's what they did. They migrated to Better Auth, which stores everything in your DB. It's the equivalent of Django auth for the Typescript ecosystem.
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.
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
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.
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.
AuthN is hard and generic, authZ is easy and specific. Offload authN, and keep your users table in your Hetzner.
You are not supposed to offload your users table, you are supposed to offload your password field.
I wrote an article about this: https://ciamweekly.substack.com/p/ciam-for-the-single-applic...
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.
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
Do you think the complexity of auth in the browser, is because browsers don't do enough?
I think auth is complicated outside of browsers too. But browsers do make some things uniquely confusing, especially cookies and general security primitives are full of footguns
Not who you're replying to but browsers do way too much. Load the code you're given and don't do anything else.
FedCM might be of interest to you. It's one effort to make browsers do more around authentication.
Wrote an article about that here: https://fusionauth.io/articles/authentication/fedcm (hosted at my employer's website)
Hey hey! Qq: you guys plan to support Python backends or is there a way for us to do this?
Works fine with my fastapi backend using the JWT plugin. I run better-auth as a standalone service.
https://better-auth.com/docs/plugins/jwt
Aha very cool thanks
So let me be the one to invite ridicule and scorn by admitting I wrote my own auth code. It was fiddly and boring at the same time. It also wasn’t rocket science, and it works well. I’ll be the first to admit that there are cases where this is a bad idea, I’m just responding to the chants of never roll your own auth.
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.
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 harder to do.)
Username and password as the only option to authenticate is really getting obsolete. You need to support social login, passkey, email links, maybe SMS or some other less secure methods depending on your target market… and more often also new standards like verifiable credentials with wallets managing credentials, including logins. Good luck writing your own implementations.
And now the libraries have been outsourced to saas companies because ???
Because we need to move faster and cheaper, that's the future
I recently worked at a stupid startup where the entire logic of the app was basically delegated to several third-party services out there. It felt like an absolute piece of shit overall. Following the flow of things end-to-end was a nightmare. It was so stupid because the so-called co-founder PM at that company thought it would be cool to keep doing that.
I am with you on this.
It's not that crazy. It can take time to do and get right, and is time away from other things.
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’s not that crazy! Or hard. If you can store a hashed password in your users table, and keep the salt secret, you have working auth.
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. That's even before you need to integrate with a third party via something like OIDC or SAML or SCIM which are probably needed for a product used by businesses these days.
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.
Cookie management and CSRF stuff harder to get right, hashing passwords is completely trivial with and library.
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.
And then the client asks for SAML & OIDC support, and codes via SMS, and god knows what else.
Indeed. Password auth was always easy to do, and it seems half the commenters here think that's all you need in modern times.
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.
I'm actually surprised val.town outsources it. So what you're doing makes sense to me.
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!
> 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!
Notable that in each step, there’s an added abstraction; specifically, an authentication abstraction is the hardest one to reverse.
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?”
The auth migration cycle is the startup version of moving apartments. You swear each time will be the last, you lose stuff in the transition, and somehow the new place has the exact same problems as the old one but in different rooms.
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.
https://lucia-auth.com/
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.
Feels like auth is either “this took 2 hours” or “this consumed half the company for 3 years”, with basically no middle ground.
> 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
I'm surprised to see so many top comments here promoting building your own auth. For years I've only heard "never roll your own auth."
I think it's a correction, There's multiple levels of interpretation:
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.
It’s likely because the quick thought is that auth is just user table with hashed password.
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.
There are few hard and fast rules, but "never use something that could change as a primary key" and "never roll your own Auth" will always be true
Better Auth has been a huge time saver for me. Clerk's pricing got a bit out of hand for side projects.
This sounds like moving the problem, not solving it. I've been doing server based systems since forever and sso is this big complicated topic where people seem to bias to using either really complicated and convoluted enterprise solutions or some walled garden with lots of limitations.
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.
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.
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.
> 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 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?
0: https://boringtechnology.club/
I've recently switched from Clerk to BetterAuth as well and it's really good and definitely would recommend to anyone. It supports more things I need, it's more reliable, and much cheaper.
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, ...
> There is no val associated with this domain
back online!
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 help you get your own started here: https://clerk.com/docs/guides/secure/basic-rbac
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.
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?
Nice website! I like your docs too. Small tip though, the couple obviously AI-written articles (ostensibly for SEO purposes) in your footer are a little of a code smell.
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.
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
Tom's articles are always a good read.
Anyone remember Auth0 and passportjs?
The churn of auth services is never ending, but I suppose so are the standards.
Disclaimer: I work for an Auth0 competitor, FusionAuth.
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.
OAuth 2.x and OIDC haven’t changed much. I still use Passport.js with Firebase.
Super validating, as someone who was recently tempted to use Supabase for a project and decided to give Better Auth a shot instead. It's really made things super simple so far to the point I was semi-worried I'd missed a crucial step. But nope, they just thought of everything.
> A hard lesson you learn building a complex system is that its reliability is the minimum of the combined reliability of its critical parts.
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.
what do you get from Better Auth btw? When I used it last year, I still found it lacking and it seemed to be run by one guy.
Lol wut? you get all of your auth data in your own db in 1 cli command. You are not tied to any on db provider. On top of that you get hundreds of auth features like oauth providers (I use it to allow users to log in via google, apple, github) and the best part it's free. Not saying Supabase and Clerk are bad, but they cost money. With better auth you pay exactly $0 for all of this.
Or I could use a web framework that offers that out of the box, and its free and lives in my database, wherever I want.
I’ve looked at these auth providers many times over the years and I just don’t get the value. It takes me a couple of minutes to set up auth. Why would I want a dependency? It doesn’t help me with the hardest part which is configuring Google and Apple sign in stuff on Google and Apple. I just don’t get it.
this is sorta the obvious takeaway here. as a postgres/phoenix/elixir enjoyer i am blissfully unaware of all this sort of SaaS churn.
I use better auth for a side project i'm working on. It's open source, you can pay them to manage your user/auth tables if you want or you can run it all on your own db.
Sure, I guess if I'm using a web framework that is not quite batteries included, that makes sense, but Django, ASP .NET Core, Ruby on Rails, and so many others are open source and have authentication / users / roles baked in out of the box.
What framework offers all those auth features OOTB?
Laravel
https://laravel.com/docs/13.x/authentication
https://laravel.com/docs/13.x/socialite
https://laravel.com/docs/13.x/sanctum
ASP .NET Core, Ruby on Rails, Django, .... the list goes on and on... The ones that don't usually someone built a package that lets it happen.
I remember Laravel with Socialite [0]. Laravel is what I usually reach for Web SaaS MVP. You only need a VPS and a managed database for testing out the market and can scale a lot without increasing expenses that much..
[0]: https://laravel.com/docs/13.x/socialite
Take this post down immediately ! /jk
Lol, I developed for entrepreneurs who mostly wanted a working proof of concept of their ideas. I guess now you can vibecode them with SaaS for core technical needs.
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.
It must have come a long way then -- I'm integrating it into a new product and it is absolutely fantastic. It just works.
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.
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
My biggest question, that I didn’t see answered, is how the transition comes to an end. If creds aren’t in your system, how well do they transfer? Does it require user involvement? What if they don’t fast enough? What about complex integrations like SSO, SCIM, and passkeys (which are domain scoped)?
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.
Claude, etc. enthusiastically recommend it
I've been through the exact same migration path and I'm so incredibly happy with Better Auth. Good reminder that I should contribute: https://better-auth.com/docs/reference/contributing
I've had good experience with authelia. Simple and light to self host.
I can never imagine putting my user table on a vendor locked cloud provider. And we use Open Iddict.
Recently went with a vendor of an agentic observability and evaluation product built on Supabase and Clerk. The number of vulnerabilities and CVE’s and outright… I don’t even know the words, coming from this stack is staggering.
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.
> 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.
Man, glad I chose WorkOS instead. I’ve been a happy camper there but have wondered about Clerk bc it felt hotter. Turns out hot isn’t always good.
> And even more users who are looking to escape.
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.
> 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!
Clerk cofounder here: I hope this isn’t a Clerk stakeholder! It’s definitely misaligned with our culture around not speaking about competitors and instead playing our own game.
Replit is using Clerk to power their login?
Clerk looks _really_ good initially. It's perfect if you want to prototype something and not care about auth.
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.
Clerk cofounder here - appreciate the feedback and forwarding to the mobile team!
> offline auth on mobile
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.
We ended up caching the credentials and the JWT refresh token from Clerk, and then manually requesting the access token using the Clerk's sparsely documented frontend API. Except that to do this with Clerk, we needed to fake the cache API and then pluck the token out of the undocumented "__clerk_client_jwt" key.
This is supported by Better Auth out-of-the box. It doesn't hide these kinds of stuff from you.
Sounds tough. I'd love to learn more.
I wasn't able to find the Better Auth docs about this use case, can you share them here please?
Hello! I'm a mobile eng @ Clerk. Would you be open to chatting? I'd love to make this experience better for you
Sure. I added my email into the profile.
When is the Better Auth to WorkOS to Vanilla Auth post coming
in rails I just authentication-zero.
no need for 3rd party provider.
Is that the new library that came out in rails 8? Saw someone present on that at RailsConf 2025 and it seemed like a great solution for all rails apps. Hope it leads that ecosystem to get rid of devise (which I always found confusing).
This is what I use, great little library and haven’t touched nor thought about my auth since I set it up.
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?
You might be interested in some of the presentations at KeyConf[0]. You can also get some real world stories from the Reddit[1].
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...
1: https://www.reddit.com/r/KeyCloak/
I've seen it used in production by larger orgs. The scale where you plan for around 6 months of migration, customization and integration of your legacy zoo with 7 different user account DBs. On one hand, all of these projects were successful and now run it in production. On the other, they all really needed the 6 months to whip it into shape.
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.
For what it's worth Authentik has been listing Cloudflare as a customer for a while. Worth a look. There might be something in their blog.
Yes! I used keycloak for multitenant auth and it worked fine - a little dated but functional. Nowadays I'd probably stick to something like Clerk/BetterAuth/Supertokens.
If you're in Elixir-land, I've put together a few packages to help migrating from Supabase (or other stacks):
- 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.
Oh, and http://github.com/agoodway/walex if you need the realtime database change stuff.
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.
The homepage of val.town says "Zapier for know-code engineers".. Is KNOW-code engineer a term?
It's just a play on the phrase "no code".
Maybe you can help me out: I still have no idea what val.town is. I guess it's an alternative to Cloudflare Workers?
Hey, I work at Val Town, and we definitely struggle to describe what it is because the platform is so broad, but I'll try: a javascript code editor in the browser that auto-deploys that code to our servers whenever you edit a file. You can run code by clicking a button, on a cron, via HTTP. And there's other stuff like SQLite and blob storage
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
This comment thread was a nudge to push out a quick experimental change to the val.town landing page, so thank you. Very open to feedback on that messaging if anyone has any. Most customers these days ask about using val town with claude code, so you could also think of us as a deployment platform for vibe coded apps
That's a good question, I was having a hard time figuring that out myself. They call themselves the "zapier" for developers. In reality it seems kinda like a FaaS but idk. They have a code intelligence product that seems like a FIM autocomplete. Very confusing product suite.
Never outsource your auth no matter what unless you're vibe coding and it doesn't matter. If that's the case, don't put auth in at all because it's just you anyway or just use vibe coded password lookups from database at that point.
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.
You can literally plug the Better Auth libraries into a little Node server and run it as a separate auth server for free, forever, same as if you used a Django or Rails deployment for that purpose.
That’s all it takes to not use their cloud at all.
I'm not talking about open source libraries.