§obligatory Keycloak mention
Keycloak is awesome because it provides almost everything an organization of almost any size might ever need when it comes to topics like OpenID, SSO, federation or authorization services.
But Keycloak is a monolith, it doesn’t do things the cloud native way[1]. There’s quite a few running modes one needs to fully understand how to operate: standalone, standalone clustered, domain clustered mode, cross data center replication. All very powerful but to many, pretty unapproachable. XML files, JBoss, WildFly, Java - heavyweight technologies associated with slow startup times and difficulty in scaling.
Keycloak doesn’t provide OpenAPI specification. There are many client libraries but a lot of them are incomplete and do not cover every aspect.
Integration can be frustrating, especially when using more obscure Keycloak features. Upgrades can be a pain.
It’s not surprising that alternatives appear left and right.
§ory
One of them is ORY[2]. Unlike Keycloak, ORY is a bunch of building blocks. In contrast to Keycloak, ORY is written in golang and the pieces are relatively small footprint, zero dependency binaries.
They are designed to run in containers and start very fast. This makes them a perfect fit for cloud native applications. There are four major components, each providing and OpenAPI 2.0 specification allowing for relatively easy post deployment operations:
- Hydra: OpenID Certified OAuth 2.0 Server and OpenID Connect Provider
- Keto: is the open source implementation of Zanzibar: Google’s Consistent, Global Authorization System[3]; basically an access management system
- Kratos: Identity and User Management System
- Oathkeeper: an Identity & Access Proxy (IAP) and Access Control Decision API
ORY is not a one to one alternative to Keycloak. A number of examples:
- Kratos does not provide any account searching functionality
- there is no way to attach user account metadata in Kratos
- there are no groups and roles in Kratos
- in theory this can be built out on Keto but there is no standard method
- Keto does not provide user managed access
- Oathkeeper is okay for simple authentication but complex authentication flows get hairy pretty fast
- a lot of JSON rule files to manage
- multi-tenant deployment with ad-hoc OpenID clients would be much better served using Traefik with ForwardAuth plugins
- Oathkeeper appears to have some aspirations to be a reverse proxy too but it’s not exactly Traefik
- gluing Kratos, Hydra and Keto together is a lot of one-off work
- there are no plugins in ORY
- adding 2FA is a custom job
- creating custom authentication flows is a one-off job
- using Keycloak mappers? there’s is nothing like this in ORY
- custom claims? only by using Hydra administrative Login Accept API
- no SAML, no LDAP support
- scalability through the database
The individual components are pretty easy to get going. Using all four is actually a lot of work. Integration will require writing a lot of code.
Like with Keycloak, starting with ORY is overwhelming. Individual components are documented rather okay but diving deep in Dockerfiles and examples on GitHub will be necessary.
§the Docker Compose ORY reference setup
I’ve been maintaining my own reference setup for more than a year.
It is available on GitHub today[4]. The reference integrates all four components and provides a couple of simple scenarios visualizing the interactions. It starts with building Docker images from sources and goes through the configuration of individual components, sometimes on purpose the hard way. The reference uses the most recent components at the time of writing:
- Hydra v1.10.1
- Keto v0.6.0-alpha.1
- Kratos v0.5.5-alpha.1
- Oathkeeper v0.38.9-beta.1; v0.38.10-beta.1 does not build from sources
The reference is kept up to date on a best effort basis.