We’re using Keycloak.org which is a great product, easy to use, a lot of functionality (if you want to), deplorable “on-premise” and does offer everything what you expect from modern user authentication and management system. You should check that out, user auth is indeed a solved problem.
Keycloak is a worthy alternative, no doubt. There are a few reasons we built SuperTokens - despite knowing about Keycloak:
We've taken a modular approach which is different from most. This enables you to only pick the features you want for your use case and not worry about unnecessarily complexity.
We provide far more flexibility and options on the frontend as well
KeyCloak is a small part of the Redhat (and even less significant for IBM, the owner of Redhat). For us, our team and company is 100% dedicated to building auth. Its do or die for us. While this may not sound tangible, we'll constantly be innovating (and hopefully out executing keycloak).
Keycloak does not offer a hosted version of the offering. In our opinion, a hosted open source product is still quite distinct from a proprietary SaaS product.
We provide the most robust solution for managing session tokens. We mitigate against all types of attacks and detect token theft using rotating refresh tokens. One of our libraries to solve for edge cases (browser tabs lock) is actually used by Auth0 as well and has 250K weekly downloads on npm.
Finally - in general, we've had feedback from Keycloak users that they've had a poor experience deploying and managing Keycloak and would switch to a good alternative, if there was one. I understand that this was not true for you.
If you do get the opportunity and decide to try out supertokens, we'd love to hear about how your experience compares between the two.
Typical multi tenancy implies that the auth experience and data is isolated per tenant. However, often b2b companies simply want to provide an auth experience to their client within a specific subdomain. They do not mind the auth data be stored in the same db tables as other clients. If this is the use case, then we do support it. If you want strict isolation of auth per tenant, then you will have to deploy multiple instances of the SuperTokens core (as of today).
I cannot imagine building auth into a system now without using Keycloak.
It's a comprehensive platform for sure, which makes for some pretty intense concepts and documentation.
But once you lay your hands on a suitable tutorial it's dead easy to get running, and you'll never find yourself stuck when some PHB asks you about your password rotation policies, 2 factor auth, SAML, SSO etc. etc. Keycloak does everything you could ever want for auth.
Keycloak is great software, and I am thankful to Redhat for keeping it open source and maintaining it. But I do not believe that a production deployment of keycloak with HA, backups, customization, integrations, upgrades etc. is easy at all. It takes time and planning to get it right. Depending on the constraints, it isn't obvious to me why it would win by default over SaaS alternatives, or simpler on-premises alternatives like OP's.
> HA, backups, customization, integrations, upgrades etc
I confirm that, we had a bunch of problems with upgrades in one product. In long term keycloak introduced more headaches for ops than we devs had implementing integrations with auth0 or okta. That was before KC10.
Curious what sorts of headaches there were in this. We're currently in the process of implementing KC12 using the docker image, a User Storage SPI (our users exist in our legacy master database which is synced from an external billing system), and it's looking so far like it'll be a fairly simple setup. This is basically just acting as a OAuth shim between our primary database and an external service provider in our case, which I imagine keeps the complexity down. But I'm wondering what you might have run into that we haven't yet. Thanks!
I hope IBM/Red Hat have more sense than this, but time will tell. It may not make sense for them to maintain Keycloak with all of IBMs identity solutions.
