Auth0 has done a lot of great work educating devs on the value of a standalone auth server, but the Okta acquisition has caused some sales tactics that ... aren't great.
In my mind, you have four options for auth, whether it is for customers or employees[0]:
* no auth (brochure website)
* roll your own (please don't)
* use a library or framework (if you have one app)
* standalone auth server (if you have more than one application or more complex needs)
If you are looking at a standalone auth server option, there are a few dimensions to consider:
* license
* self-host vs saas
* pricing
* features
* support
* funding taken
Lots of options out there and more every day (hence this tweet[1] which is haha only serious)
Our VP of sales wrote an overview of the customer auth market as he sees it[2].
I have opinions, but of course where I stand is affected by where I sit[3]. But I think that devs should definitely evaluate options.
Every day it seems like the vendor-lockin-plus-$$$ vs developer-experience tradeoff that comes with Auth0 gets less and less worth it, unless you're a massive B2C app like OpenAI (which uses Auth0).
- the economics for the middle (aka most risky) scaleup stage, as talked about in this post, are not great.
- Yes, Oauth is complicated, but so is Auth0. OSS stuff like Passport (for the JS ecosystem), authlib for python, and omniauth for the ruby is basically just as easy, and the vendor lock in on storing users in Auth0 is quite massive.
- WorkOS and a slew of new products exist to cover B2B SAML enterprise-SSO-connections at a smidgen of the cost of Auth0 (which charges multi-thousands-per-connection).
This is one of the most common reasons Auth0 customers will reach out to us (https://stytch.com/).
We just refreshed our pricing [1] recently and a big focus was creating pricing that scales with you, not a timebomb waiting for you to tip into "enterprise".
If you ever find yourself stuck with Auth0, get in touch!
As far as I can tell you have a billion dollar valuation series B round (congrats) but that also means you need to grow into that valuation. In the end, it will be be the same predatory pricing strategies that you’re forced into to justify to your investors the valuation. I wouldn’t bet my horse on it - it’s just the same auth0 but subsidized by VC money right now.
For auth, DIY with open source is the cheapest and best option
> ...but that also means you need to grow into that valuation
Definitely true, but our leadership believes the best strategy to grow as a company is by aligning our customer's growth and success with ours.
As a consumer of SaaS, I'm very comfortable paying for a good product and paying more as my usage/realized value goes up. What I'm not happy with personally is a product that is working well for me and then all of a sudden jumps in cost far above where it was previously.
We don't think the Auth0 bait and switch is the path towards winning and _keeping_ customers long term.
Great website! Small feedback that may or may not be relevant to you: on mobile (chrome, android) I can't see the horizontal slider for monthly active users and the calculated monthly price on the same screen (on the pricint page), that is without scrolling. I was confused for a bit as I was wondering if it was free whatever the number of users was.
We originally displayed the calculated price, based on the sliders, in the top line number above the scroll, but some folks got confused about whether that was just usage and the base fee or vice versa.
Migrated from Auth0 to Firebase because it was 2 orders of magnitude cheaper.
After explaining that we didn't need any fancy features, just OIDC+SAML sign-in they proposed a number that was a little over $1/user/month ($30,000 a year for 2500 seats). This was after multiple rounds of back-and-forth, sitting through custom decks and sales pitches around "you aren't paying for SSO, you are paying for an increase in conversion and revenue".
Firebase is self serve for ... $0.015/user/month (or $450/year for the same 2500 seats)
I thought it would be about the data breaches and them being a security weak-spot instead of a stronghold.
I had no idea that they also rob you in the process, employing the good old vendor lock-in move even my grandma knows about.
P.S. Keycloak is a pain in the ass to figure out and set up properly, also it runs on some ridiculous app server, giving it a recognisable turn of the century stench, but it is well worth it.
OR, you can just run your own SAML and OAuth SSO (Shibboleth is one example) instead of delegating one of the most critical aspects of A3E over to an external vendor.
A3E? Nothing on the first page of Google results for the term seems to have any connection with the context, not even if keywords meaning/web development/web security are added to the search. Would you care to expand the abbreviation for those unfamiliar with it?
It's a tradeoff, right? FusionAuth (my employer) has a self-hosted and a SaaS option; we let customers choose what works best for them, and have a roughly even split of paying customers between the two options. (Far more non-paying users self-host because that is free with our community edition.)
However, running a high availability auth service isn't in the core skills of every software team, and therefore folks want to outsource it. That way the teams can focus on building and running the software that is core to their business.
On the other hand, some folks have teams and processes to run a service like auth at a high level of reliability. In this case, using OSS options like Shibboleth and Keycloak makes a lot of sense. At FusionAuth, we see customers migrate from those systems because they want something more modern with a team releasing new features (with their feedback). OSS has some fiddly parts, and knowing who to ask for support can be tough (though there are contractors out there who can help).
It's not a trivial choice. As mentioned in the article there's a fair amount of lock-in. The lock-in is both technical (if you build features on top of non-standard parts of an auth server) and organizational (once you have a working auth system, you aren't going to get a ton of new features if you move), which is why Okta has negative churn (as reported in their earnings).
But if you build to OIDC and put facades around the provider, you should be able to migrate (make sure you can get your password hashes as well as other data).
> Okta has negative churn (as reported in their earnings)
Churn means they lost customers. So negative churn means that they gained customers? I looked in the last four quarters and it said they gained customers each quarter.
Do you have a source for your claim?
Disclosure: I used to work for Okta, but I don't anymore.
Price gouging once you are vendor locked seems to be the problem will any hosted SaaS platforms. This of course should be something you consider when building things. Maybe at the time when the author was building their app Auth0 was the easiest solution and now that they have revenue migrating authentication providers will be worthwhile.
Stuff like this though is sometimes a good problem to have in a way because it means you actually are growing your business.
Personally I tend to avoid most hosted SaaS for this exact fear, but maybe I shouldn’t so I can have greater velocity (and fail fast…)
author complains how much higher their bill is without realizing that it was initially subsidized to promote vendor-lock in. Sorry, but this isn't auth0 fault, it's yours for being greedy and worst case clueless. A penny saved is a penny earned; now that you're successful your bill is due.
Auth0 has done a lot of great work educating devs on the value of a standalone auth server, but the Okta acquisition has caused some sales tactics that ... aren't great.
In my mind, you have four options for auth, whether it is for customers or employees[0]:
* no auth (brochure website)
* roll your own (please don't)
* use a library or framework (if you have one app)
* standalone auth server (if you have more than one application or more complex needs)
If you are looking at a standalone auth server option, there are a few dimensions to consider:
* license
* self-host vs saas
* pricing
* features
* support
* funding taken
Lots of options out there and more every day (hence this tweet[1] which is haha only serious)
Our VP of sales wrote an overview of the customer auth market as he sees it[2].
I have opinions, but of course where I stand is affected by where I sit[3]. But I think that devs should definitely evaluate options.
0: https://fusionauth.io/learn/expert-advice/ciam/ciam-vs-iam has more
1: https://twitter.com/thdxr/status/1651369228371361792
2: https://fusionauth.io/blog/2023/03/15/winning-customer-auth-...
3: Miles' Law: https://www.jstor.org/stable/975497?seq=1#page_scan_tab_cont...
Edit, fixed url reference.