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).
Can I store users in per-tenant databases? Maybe if I forked the stroage plugin and modified it to do that?
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.
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.
Baseod on the rest of your comment, I think maybe deplorable was not the word you intended to use there?