Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



Is SuperTokens multitenant capable? My understanding is that keycloak suffers in a multitenant enviroment with a sufficiently high number of tenants.


I had the same question - apparently the answer is yes: https://supertokens.io/docs/emailpassword/common-customizati...


To an extent, yes: https://supertokens.io/docs/emailpassword/common-customizati...

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'm also curious about multi-tenancy.

Can I store users in per-tenant databases? Maybe if I forked the stroage plugin and modified it to do that?


How about keycloak-gatekeeper? Do you offer something similar?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: