Why you must not use Auth0/Okta for login/pass solution
medium.com
medium.com
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.
- 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).
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!
[1] https://stytch.com/blog/announcing-new-pricing-and-self-serv...
For auth, DIY with open source is the cheapest and best option
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.
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.
Let me chat with the team about it!
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 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.
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).
tl;dr: it depends :)
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.
See https://investor.okta.com/static-files/8a461359-83f8-4332-9f... , the "Dollar-based net retention rate for the trailing 12 months ended" numbers.
For the last 9 years:
2015: 129%
2016: 120%
2017: 123%
2018: 121%
2019: 120%
2020: 119%
2021: 121%
2022: 124%
2023: 120%
It is evidence that auth is sticky.
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…)