Keycloak is much heavier than Hydra. With Hydra, it is much easier to spin up thin OpenID clients. If one has a need to spin up dozens or hundreds of OpenID clients, Hydra will be definitely a better choice purely because one can have multiple Hydra servers running with only a handful of clients each. Think multi tenant environments. With Hydra, there is no reason not to have many Hydra instances with as low as a single OpenID client.
Hydra API is smaller and easier to use than the one from Keycloak. Because of how lightweight Hydra is, it is possible to spin it up in integration tests with docker using something like Ory dockertest.
What the Ory stack is missing is an implemetation of UMA2 and there is no out of the box support for LDAP auth and SAML federation. However, the way Hydra handles accepting an identity from an external authentication source via its admin API makes it fairly easy to add any auth mechanism, not limited to how it would be in Keycloak because of the Keycloak SPI design choices. Implementing the user federation SPI for Keycloak is actually pretty tricky.
What speaks for Keycloak is the completness: user and role management, permissions, resource servers and so on. However, if one wants just tokens and does not mind writing the glue code to Kratos and Keto, Ory stack is awesome. There is Oathkeeper serving as that glue layer and a sort of reverse proxy to all 3 of the components but it doesn’t always fulfil all requirements.
Keycloak supports multi-tenancy natively with realms. There is a fixed memory cost for each, but it’s not like you have to spin up an entirely new instance for each.
I will agree that the SPI interfaces for Keycloak could be better, but especially with the new Quarkus distribution it’s stupidly easy to setup and has 99% of what you need out of the box.
> Keycloak supports multi-tenancy natively with realms. There is a fixed memory cost for each, but it’s not like you have to spin up an entirely new instance for each.
Yes, I know. I use Keycloak in production. All realms sit on one instance. As do all clients. It can get really heavy and really slow really fast, especially with resource servers. I am aware of replication but that is basically replicating the whole instance.
The other not so nice thing about the SPI is that custom providers are loaded into the main Java process and that comes with all the pitfalls of class loading, shading, uber jars. It’s a mess. Try building a log adapter to push data to Kafka or over grpc. Dragons.
Keycloak is nice for out of the box stuff but integration can get pretty messy.
Hydra API is smaller and easier to use than the one from Keycloak. Because of how lightweight Hydra is, it is possible to spin it up in integration tests with docker using something like Ory dockertest.
What the Ory stack is missing is an implemetation of UMA2 and there is no out of the box support for LDAP auth and SAML federation. However, the way Hydra handles accepting an identity from an external authentication source via its admin API makes it fairly easy to add any auth mechanism, not limited to how it would be in Keycloak because of the Keycloak SPI design choices. Implementing the user federation SPI for Keycloak is actually pretty tricky.
What speaks for Keycloak is the completness: user and role management, permissions, resource servers and so on. However, if one wants just tokens and does not mind writing the glue code to Kratos and Keto, Ory stack is awesome. There is Oathkeeper serving as that glue layer and a sort of reverse proxy to all 3 of the components but it doesn’t always fulfil all requirements.