Do you have experience with single sign-on implementations? We need some advice. We can also offer some freelance work to the right person with hands-on experience of SSO implementation to help development. We are working on a project that will help grassroots organizations collaborate on running and maintaining buildings, 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 (BankID)
- 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.
