Some additional things that someone might find useful:

Keycloak supports separating token endpoints (the OAUTH2/OIDC URLS used for tokens) and the built-in login challenge pages from Keycloak's admin console and the REST API. In other words, you can offer the token endpoints and login service to the public and isolate all the admin and backend stuff to a different hostname and/or URL scheme. Have a look at the KC_HOSTNAME_ADMIN[_URL] config option(s).

Keycloak has a capability called Authorization Services, an implementation of User Managed Access (UMA2). It's opt-in and probably 99% of Keycloak users don't know it exists. It can be used to implement fine-grained authorization schemes on top of OAUTH.

I've found that the realms in keycloak doesn't scale quite as well as we would have wanted.

There is some kind of slowdown, and after around 200 realms things start breaking and startup time starts growing uncontrollably.

There's a good chance it's an issue in our setup (which is fairly complex), but every time we look at it we trace the slowdown back into keycloak itself

Just letting you know it's not you - this is a well known long standing issue with keycloak. Typically users see a significant performance cliff at around 300-400 realms. While one realm is not necessarily the same as one tenant in keycloak, it does make it a significantly larger headache to support multi tenant with SSO integrations in a single realm.

I'm afraid I can't give you more details than that, we just moved on from keycloak at that point.

> 1 keycloak instance can have many realms.

For people not familiar with keycloak, keycloak realms are equivalent to what other auth providers call tenants (Auth0, FusionAuth [which I work for]) or user pools (Cognito). Basically a segmented set of users and configuration related to those users.