TIL: Auth provider updates
Today I learned: not yet a full post, just sharing what I learned
Yesterday I read from Simon Willison that if I have more than 10 tabs open for solving a problem, then I should post about it. So after about 100 tabs open, I'll start posting about my quest for auth providers.
Background 1: 1.5 years ago I wrote an article about it.
Background 2: Back then I invested quite some time into using Next.js and modern React, but soon after I wrote the article, this Next.js + modern React combo became the most disillusioning experience in my software developer career. I think I really don't get Vercel; it's supposed to be amazing DX for a lot of money, but I honestly found it the worst and most confusing overcomplicated DX for a lot of money. I think Vercel is single-handedly the reason for the renaissance of HTMX / FastHTML / Hotwire / LiveView frameworks. Which is actually quite good for the ecosystem!
Background 3: I'm trying to figure out how I can offer Enterprise SSO for $300 per month plans on a SaaS product, which is 10-20 times smaller than where it's usually offered.
What would I use today?
1. A separate backend API in any language the developer prefers. For example, for AI projects, writing the backend in Python makes a lot of sense.
2. Splitting the frontend into app subdomain and home page / "marketing" website. Marketing website can be a static site in a CloudFlare bucket. I really like Astro for this part. The tricky part is the pricing page, which can depend on local currency, IP address, etc.
3. The app lives on its subdomain, like app.myproject.com, which requires login. This one can be a classic SPA created with Vite. No need to overcomplicate anything, it's a breath of fresh air to see a classic SPA after battling Next.js's bizarre server/client magic.
One bonus advantage of this system is that Google only sees the marketing website, so we don't get penalized on SEO for any technical or UX choice we make on the app subdomain.
Now, what happened on the auth landscape in the last 1.5 years? First of all, there are so many auth providers now that it's impossible to count them all. Michael Grinich, the CEO of WorkOS listed 31 on the HN discussion of my article here, but even then he missed a few.
Almost all the providers I wrote about in my article changed pricing. I don't mean just a little bit, but they totally rethought their pricing structure/logic. It is probably my biggest worry about recommending closed-source vendors, that with auth you are at the ultimate vendor lock-in and the vendor can just decide to refactor their pricing model any time.
On the positive side, many limitations I wrote about in that article got fixed. For example, Supabase added 2FA and fixed some bugs, ZITADEL added nice examples and worked a bit on the UI.
Ory totally moved up-market and is now expensive and open-core. Price for 10k users is $1600 per month. Self-hosting is not an option anymore, as the open-source version doesn't support SAML orgs for example.
Also, they have some really weird hard-coded behavior, like when changing email address, you need to verify both the old and the new email address. In my life, I've experienced this behavior maybe once, and that was on a bank account. Literally no SaaS vendor asks you to verify your old email address. The reason you want to change it in the first place is probably because you no longer have access to your old email!
All in all, I no longer recommend Ory.
Clerk is super focused on the JS ecosystem, especially Next.js. It's lacking SDKs and examples for other languages.
Moreover, they ask $125 for MFA, which I find super baffling; it reminds me of those web hosts who asked for money to have HTTPS even many years after Let's Encrypt existed. MFA is one of the reasons people go with dedicated auth providers, don't sell it for $125!
I no longer recommend Clerk.
FusionAuth is closed-source and they offer a limited version for self-hosting. Their pricing is super confusing.
To get the full package, like SCIM, it costs $3300 per month for 10k users and you even need to self-host it!
BoxyHQ offers a really interesting open-core model, with the super geekily named SAML Jackson (it takes a while, try to say it out loud).
I found their product to be the most promising for adding SCIM or Enterprise SSO onto an existing auth setup. It's not yet clear how these combined products work. I mean they offer the SSO login while you are already using some kind of auth system, how do you handle sessions? Do you code two, independent session handling mechanisms into your app? That sounds super bug prone.
If not, then how do you combine your existing auth provider with BoxyHQ? I see that they offer some sample apps with Supertokens for example, but I don't yet understand the general logic here. If you know how these mix-of-two-provider auth systems work, can you explain it? It seems very bug prone to me.
WorkOS is super good! They are a serious company, which used to offer only Enterprise-related features, and recently started offering "normal" auth, like password or social login.
They have the easiest to use website and examples in many languages. It's still early stage for their product though; for example, changing emails is still a work-in-progress. I wouldn't worry about it too much, as if you start developing a product now, then by the time you ship and get traction this feature is probably shipped.
Also, the best part is that they offer 1 million monthly active users for free! Basically their pricing model is you get everything you need for B2C websites for free, and you pay premium money for enterprise SSO / SAML / SCIM.
With that said, I arrived at their biggest limitation: the enterprise SSO with directory sync / SCIM costs $250 per month per customer. At which point you have to ask the question how much "auth tax" can you afford per customer? If the answer is say 5%, then you need $5000+ per monthly plans. Which is a very realistic scenario for their bigger customers, but definitely not for all companies.
Having said that, if you don't need SSO / SCIM then I think there is almost no question, the best solution is to use WorkOS! I mean it's the perfect choice for 99% of B2C apps, and is totally free!
And what if you do need those features? For example, what can you do if your customers require enterprise SSO / SAML on a $300 plan? You look for cheaper offers or self-host.
Supabase is one of those cheaper offers, offering SAML on their $25 Pro plan! What's confusing is this page in their docs, which says that you need the $600 per month plan.
Also, it's not clear if any of these advanced features are available in the self-hosted version, or it's tied to their hosted offerings.
Right now I'm checking out self-hosting ZITADEL.
Previously I wrote that the configuration is very complicated, which is still true today, but luckily they added nice documentation, example projects and even videos about how to set up auth for the most common scenarios. For example React frontend + Python backend is one of their examples!
I'll write about ZITADEL as I work through it. They are one of the few truly open-source companies in the auth space, and one of the very few solutions offering open-source Enterprise SSO / SAML! Their whole product is open-source and is shipped in a Docker container, so it's relatively easy to self-host!
But first, a comment about their pricing for the hosted version. They give the pricing on Daily Active Users (DAU), which is calculated in the weirdest way. It's so weird that their first 2 FAQ items are trying to explain it! Basically it's saying that if a single user checks your site every day, then it counts as 30 daily active users. It sounds like the craziest thing to me. For me this seems like 1 user, definitely not 30. Is this normal to count daily users like this elsewhere?
Also, doesn't it just push developers to set a really long refresh timeout, as users are counted when a refresh token is issued? I mean, if they are pushing developers to use less secure environments, then what's the point of choosing a dedicated auth provider in the first place? Isn't the whole point of security is to have reasonable duration refresh tokens, which can be revoked if needed?
Anyway, they really have the best open-source offering and if you self-host then the pricing totally doesn't matter!
That's what I've learned in the last 2 days. If I wrote something that isn't correct, or if you can help me with some of my questions, or if you just feel like commenting, please leave a comment below.
What about keycloak?
Hi Zsolt, thanks for the write-up. I found your 1.5-year article after seeing some users recommend logto.io in the comments. I’m part of the team at Logto, focusing on pricing design, and your insights really resonated with me.
On the topic of pricing, I agree with your observations. It’s a challenge we’re working hard to solve. Many auth providers have pricing models that aren’t very developer-friendly, even with various SKUs. Developer tools are unique—they don’t offer the same instant appeal as AI or productivity apps. Developers need time to assess features, pricing, security, and control before making decisions, which often discourages auth providers from investing in developer-first approaches: Can I get money from them？
Most developers face a tough choice between open-source solutions or expensive professional CIAM platforms. We want to addressing this issue and close this kind of gap, and here’s where we currently stand:
Logto Free plan offers basic authentication features and supports up to 50k MAU.
For paid service, projects can start at just $16, with add-ons available: unlimited organizations for $48, MFA with all factors for $48, and enterprise SSO for $48 each.
For solo B2C developers, this brings costs to about $16–$100, if your project is a simple B2B project on the early stage, it's still less than $300, which we’ve found works well for building and sustaining projects.
Looking ahead, we’re exploring a token-based pricing model. MAU isn’t the best measure of resource usage because it doesn’t account for engagement levels. For example, a user who signs in daily and a user who signs in twice a month both count as one MAU, even though they consume different amounts of resources from the auth provider. While MAU is useful for business metrics, it doesn’t accurately reflect technical resource consumption.
Until we finalize this idea, we’ll keep unlimited MAU for our Pro plan.
Our core principle remains the same in the long run: we want to keep billing controllable and within a reasonable range, aligned with the developers' product’s stage and revenue outcomes, and avoid unexpected or excessive charges.
By the way, Logto offers both an OSS version and a cloud version!