Help us choose between Keycloak and Auth0

We’re looking for help to decide on a path for our project - Keycloak or Auth0. If someone would have time to help us work on the implementation, we can also offer some paid freelance work.

We are working on a project that will help grassroots organizations collaborate on running and maintaining building, creative communities and parks. It’s a mostly open source set of tools split up into three web apps.

We have two web apps (both with GraphQL APIs and React/Apollo frontends). Both of these apps are built to be multi-tenant, with each tenant having its own set of users and a separate domain. We now want to build a Single Sign-on solution that allows users to log in to both of these apps with the same account. We also want to build a dashboard that allows organization admins to administrate user roles and permissions for their organization.

We are currently comparing two possible solutions. One is to use Auth0, and the other is to run Keycloak. Furthermore, we are open to other options.

Some requirements:

  • In the first two years, we are expecting at most a couple of hundred organizations, with an average of 50 users each. However, the solutions should be able to scale to thousands of organizations.

  • It is important that the SSO server has ready-made connections to social identity providers like Google.

  • It is important that there are well-documented cases of using the SSO solution with Swedish BankID authentication (https://www.bankid.com/en/)

  • We want the ways of authentication (username and password, social, BankId) to be set by us individually for each tenant depending on the use case. Some will only want passwords as usernames while others will want social authentication with Google or official identity with BankID.

  • We need to be able to have our custom interface for the SSO page

  • Preferably, we want to be able to use different SSO page designs for each tenant.

  • These applications are open-source, so the ease of setup for community developers is a factor.

Factors to consider:

  • We do not want to be locked in by Auth0, but we also don’t want to become bogged down in early development by having to implement everything ourselves.

  • Users will be dormant for most of the year, logging in often for 3 months and logging in quite rarely for the rest of the year.

  • Price is a factor, and we want to compare the subscription cost of Auth0 to the estimated cost of setting up, configuring, and running Keycloak and developing any required integrations. Since Auth0 also needs some configuration, this should be taken into account.

  • Generally speaking, we would accept the 0.25 USD fee incurred per user for Auth0 if the work and effort saved by using Auth0 are considerable. This also means that if we can instead use the same amount to pay our team, that would be preferable.

Some illustrations on our architecture. Note that the dashboard has dashed lines and arrows. That’s because we might not need to build it ourselves if there is a way to give org admins restricted access to Keycloak to set roles.

Hi @aerugo, I’m in a very similar situation to you, and would love to hear if you made a decision and how. For me it’s important to move quickly and don’t care so much about the cost. Let me know if you want to connect and exchange ideas.

So far, I found keycloak easier to integrate with on the client side, but I’m concerned that setting it up to run securely (e.g. exposing the admin dashboard to the web) could be difficult.

Hi @savv! Basically, a lot has happened since, but in the end, we went with Keycloak. It has caused us a bit of pain though, but we are slowly working through it. We decided that the cost of Auth0 once we have thousands of users (which we expect will happen within the next 12 months) would be so high that we could basically just use the same money to pay a developer for the added overhead of running Keycloak - with the benefit of that solution scaling better after than point in terms of price. We also don’t like the lock-in of Auth0.

Basically, our key takeaway is this: Don’t worry so much about Keycloak. Instead, assume that you are implementing OpenID as a standard. That means that none of your code or choices will be specific to Keycloak. It also means that you should be looking for libraries that implement OpenID in general, which is a much richer ecosystem of implementations.

Since Keycloak can act as a bridge to any other OpenID or SAML compliant SSO server, that also allows us to connect our solution to existing third-party SSO solutions if they want to become our clients.

We did, however, decide against managing user permissions through Keycloak and dealing with this in our own software instead. This means that we don’t have to worry about implementations of user groups, realms or roles in Keycloak - which we found to be pretty clunky when connecting to our Javascript-based webapps and APIs.

1 Like

Maybe @gustav or @Powersource have more to add?

By the way, we have not solved for these things yet. Our thinking is that once we start getting interest from premium client that would want this, we will figure this part out - it probably means we will need to bite the bullet and work more with user groups, roles or realms in the future.

Yep basically what @aerugo said. We’re having a few issues with it but it looks like we’re slowly fixing those. And yes it’s looking like we’re going with keycloak for authentication and our own thing for authorization.