Hacker News Reader

Comment by robbie-c | Hacker News Reader

Tangentially, if you’re a B2C startup like an app, avoid using auth0. Their pricing starts out cheap but once you hit 10k MAU, it’ll go from $X00 a month to a 3 year contract for $X00000.

It’s not designed as a business for that use case, and you’ll be paying for a lot of premium features that you’ll never use.

If something like Firebase Auth suits your use case, use that instead.

View on HN

Can confirm, also very dissapointed with Auth0. We have been happily using Auth0 for years within their self-service license tier. Unfortunately we are now in the process of migrating away from Auth0 on short notice.

We never hit 10k MAU, but according to their sales people you can't have multiple tenants without an enterprise license, even though that is not mentioned anywhere in the docs. We have been using them in good faith, however they will not shy away from aggressive sales tactics and threatening to 'de-provision' you if you do not commit to a very expensive license.

I can also confirm that their sales org is very disappointing. The technical side is excellent.

Can confirm, it got downhill once they got acquired by Okta.

We had to roll our own auth solution because they couldn’t make the pricing even remotely viable.

I’d like to write „stay away from Auth0”, but is there any comparable alternative?

We did quite a bit of research into this.

If you need mostly B2C features I would have a look at Clerk [0] and Supertokens [1]

If you are more interested in B2B features we found Ory [2], FusionAuth [3], and good old Keycloak [4].

None of them are fully comparable yet however, which might be the reason why they might get away with their current behaviour.

[0] https://clerk.dev/ [1] https://supertokens.com/ [2] https://www.ory.sh/ [3] https://fusionauth.io/ [4] https://www.keycloak.org/

Thanks for the mention (I work for FusionAuth).

I'm curious what solution you ended up determining best fit your needs?

that landing page should point to docs instead of commands for me to run on my machine.

I'm someone looking for auth/security products. you won't reel me in like that.

Thanks for your feedback! Here are the docs: https://fusionauth.io/docs/v1/tech/

FusionAuth has a dual deployment model. You can either run it locally (or host it yourself) for free, or you can pay us to run it for you. Most devs want to kick tires and run it locally, which is why the downloads page has those commands.

There are features that do require a license, but we have plenty of people running with plenty of MAU on the free version (we call it the 'community' edition).

Sorry if it wasn't clear.

That’s been our experience as well. Auth0 seemed like a great deal and we were happy to have such a sensitive component handled by a dedicated third party, but their sales team aggressively pursues us as soon as we go over some MAU limit and it’s clear that the nickel-and-diming is only going to get worse as we grow. We need to migrate away sooner or later.

Or just use your favorite oauth / oidc library. AuthZero is for people that need SAML or AD integration or some other legacy tech.

That's a great path for many folks. I think building on a framework is far far better than rolling your own.

However, often there comes a time when you have multiple applications that all need a shared user data store. (Note, I work for FusionAuth, so I am, to some extent, talking my book here.)

You then have some choices:

* run everything off of one app (both features and user management) and have other apps oauth/oidc into that app. This means that other apps are now dependent on one main app. Within that app, user data and feature data may get entangled

* hive off the user manangement and login data from the main app to a separate one and have other apps oauth/oidc into that second app. This lets you deploy/manage them separately and still have one user data store. Congrats, you've just invented an auth server! This can be a good option, but that refactoring may be a bit painful, and you're on the hook for maintaining the auth server (dependencies, adding workflows and functionality).

* stand up a separate auth server (or use a SaaS offering) and have apps oauth/oidc into it. In this scenario the auth server vendor is responsible for updates (adding new forms of MFA such as WebAuthn, for example) and your apps get the benefits from it. The issue here is that this is a core part of your app, so any downtime or integration issues due to an upgrade can cause major headaches. (At FusionAuth, we work around this issue with a single tenant model and by allowing you to pin your version.)

It's engineering, so there's no perfect solution. The above are some of the tradeoffs I've seen.

Reply on news.ycombinator.com