I search 2 years ago a working server and not found ;(
And if you are especially unlucky might be so painful to use that you could say it doesn't work.
But for a lot of use cases it does work well.
In some context it might safe you not just developer month, but years (e.g. certain use cases with certification/policy enforcement aspects).
But it also can be a story from running from one rough edge into another where you project lead/manager starts doubling or tripping any time estimate of stories involving Keycloak.
E.g. the REST API of Keycloak (for programmatic management of it) is very usable but full of inconsistencies and terrible badly documented (I mean there is a OpenAPI spec but it's very rarely giving you satisfying answers for the meaning of a listed parameter beyond a non descriptive 3 word description). (It's also improving with each version.)
Similar multi tenancy can be a pain, depending on what exactly you need. UMA can be grate or a catastrophe, again depending on your specific use cases. SSO User management can just fine or very painful. There is a UI for customizing the auth flow, but it has a ton of subtle internal/impl. detail constraints/mechanics not well documented which you have to know to effectively use it so if you can't copy past someones else solution or only need trivial changes this can be a huge trap (looking like a easy change but being everything but that)...
The build in mail templates work, but can get your mail delivery (silently) dropped (not sure why, maybe some scammers used Keycloak before).
The default user facing UI works but you will have to customize it even if just for consistent branding and it uses it's own Java specific rendering system (and consistent branding here isn't just a fancy looks goal, one of the first things though on scam avoidance courses for non technical people is, that if it looks very different it's probably a scam and you shouldn't log in).
I think Keycloak is somewhat of a no brainer for large teams, but can be a dangerous traps for very small teams.
BUT there's also a lot of pain in using Keycloak, especially when you build on top of it. One of the great things about Keycloak is, that it can be seen as an extendible platform. Nearly everything is customizable. However, it takes a lot of time and effort to learn the programming model and especially the documentation is a PITA. It has been even worse 2 years ago, but it's still a lot of fiddeling around and usual I find myself in reading the Keycloak source (which has a very mixed quality btw.) as no documentation is available.
Multi tenancy is indeed also a hard topic. We heavily utilize multiple realms (I think we should have hit 100 already) for that, but newer developments in Keycloak now offer an additional model based around organizations [1].
One thing that bothers me personally is that the storage model of keycloak does not offer zero-downtime migrations and the work on refactoring it has been paused for now. Since we have a solution based on Keycloak, we deploy Keycloak regulary with every feature. However, the embedded infinispan cache makes this hard on scale as during redeployments Keycloak become unresponsive due to cache leader synchronization and eventually drops some caches, leading to user sessions being terminated. Fortunally Keycloak finally has support for an external Infinispan cache [2] and moved to protocol buffers for serialization [3], which should make upgrades smoother, and grounds the road to zero-downtime deployments.
After all this, let me emphasize that for most of it the Keycloak team is aware and is working hard in moving forward. I started using Keycloak with Version 11 and a lot has changed for the better.
> I think Keycloak is somewhat of a no brainer for large teams, but can be a dangerous traps for very small teams.
I would not agree on that. You don't necessarily need a large team for operating Keycloak and smaller teams are probably not that big of an issue. At least not for operating Keycloak. What I feel to be more a problem is, that many (at least of our) clients are not understanding OAuth 2.0 and OIDC well, and therefore puts a larger burdon on support work. Also there must be at least someone very knowledgable of Keycloak to give guidance to the rest of the team, but in general I would not say it's dangerous. We have even a team operating their own keycloak and using our keycloak to perform OIDC federation (don't ask me why tho, I never understood it).
[1] https://www.keycloak.org/2024/06/announcement-keycloak-organ... [2] https://github.com/keycloak/keycloak/issues/28745 [3] https://www.keycloak.org/docs/latest/release_notes/index.htm...
this is why I said large team, you need people with knowledge, but on small teams you likely can neither hire them (if the team already exist) or have resource to spare on giving someone a lot of time to get into it. And having just one specialist would be very risk to actually you need 1.5-2 people. Things become worse if you also need to have plugins and are not a Java workshop at all (as even if you don't write them you should review 3rd party plugins).
Through I guess that doesn't apply if you only do very straight forward thing, like no multi tenant no fancy anything, then a small team work well. too.
I mainly said it can be dangerous as small new startups are often on a very very tight time schedule so the delays yo can run into if you don't have a Keycloak expert can be quite hurtful for them.
KeyCloak is also very good, but I'd run is as a container due to the quick release/update cycle. If I had to do our infrastructure over, I'd probably go for KeyCloak, just because it's the most used.
Looks like it doesn't support multiple issuers: " CAS primarily supports a single issuer per deployment/host." Have you run into any issues with that?
It also looks like it supports a number of optional standards: DPoP, JARM, PAR. Have you seen use cases for these?
Yeah, we only have the one issuer, so it's not a concern. For pretty much every KeyCloak project I've done, we have also favored doing separate deployments for separate issuers, so I'd say it's not much of an issue, in most cases.
Regarding the optional standards, no. We've not run into an clients that would require or in many cases even support anything but the most basic OpenID Connect. I'm sure there's a point to supporting them, but I've never seen it being needed for your average use case.
closed source self hosted: adfs
hosted: okta (auth0) google microsoft github amazon
these are just the ones that were viable 2 years ago