Our architecture is fundamentally different than that of keycloack's: - For SuperTokens, the frontend doesn't talk to the Supertokens' Java core directly. It's always through the user's API layer. This means the public APIs that keycloak exposes need to be exposed via the user's API layer. So for SuperTokens, this is done via a backend SDK which the user needs to integrate with. The motivation for this is that API customisations can be done way more easily in comparison to Keycloak + we can provide end-to-end httpOnly session management out of the box. - We are modular in nature. For example, you can use SuperTokens just for session management and use another auth provider for login, or vice versa. Due to the modularity, we also don't force users to use protocols like OAuth when they don't need to. The motivation for this is simpler configs and docs. Again, extending Keycloak to do this would not be "natural".