Category: Identity and access
Keycloak: single sign-on (SSO) for your company
A single sign-on for every application in your company, with two-factor authentication, leavers whose access is cut off instantly and an identity server that is yours.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
In short
Keycloak is an open source identity server, licensed under Apache 2.0, that provides single sign-on (SSO) through OpenID Connect and SAML. We install it in your account, organise the realms and applications, enable two-factor authentication, federate it with your LDAP, Active Directory, Google or Microsoft, set it up for high availability and take care of upgrades and backups.
What do we look after?
Keycloak becomes the front door to everything else: if it is slow, everything is slow; if it goes down, nobody gets in. That is why we treat it as the most critical piece of the platform.
Realms and clients
Each application connected with its protocol, its roles and its allowed redirect URIs.
Two-factor authentication
One-time codes, security keys and passkeys, mandatory where needed.
Federation
LDAP or Active Directory as the source of users, or Google and Microsoft as identity providers.
Database
Replicated PostgreSQL: it stores the configuration and, in current versions, the sessions too.
Cluster
Several nodes with their distributed cache, behind a load balancer.
Monitoring
Metrics and logs of sign-ins, errors and brute-force attacks.
Which architecture do we recommend?
For a company, a single Keycloak cluster with at least two nodes, spread across different availability zones if the provider has them, and a database with synchronous replication. The nodes share a distributed cache with Infinispan, built into Keycloak, for authentication sessions. The official documentation also describes architectures with several clusters in different sites; we only propose them when losing an entire data centre is not acceptable, because they double the load on the database.
| Realm | For whom | Sign-in |
|---|---|---|
| Employees | Staff and collaborators | Federated with Active Directory, Google or Microsoft, with mandatory two-factor authentication |
| Customers | Users of your product or portal | Self-registration, optional social sign-in and a password policy |
| Administration | Whoever manages Keycloak | Very few accounts, two-factor authentication with a security key |
Which problems do we find when Keycloak is self-hosted?
- Admin console open to the internet: the master realm reachable from anywhere.
- A single node: every restart for an upgrade leaves the whole company unable to sign in.
- Configuration done by hand: nobody knows which client was created for what, or can recreate it.
- Wildcard redirect URIs: a client accepts redirects to any domain.
- Very old versions: installations from before the move to Quarkus that no longer receive patches.
- Database with no backup: the configuration of every realm lives on a single machine.
How do we protect, back up and upgrade Keycloak?
We back up the Keycloak database outside the provider and export the realm configuration to your repository, so that the realms can be recreated even without the database. We regularly restore into a test environment and check that it is possible to sign in to a test application.
Keycloak releases frequently and, since it has been based on Quarkus, every upgrade migrates the database schema on start-up. Before upgrading we read the upgrade guide for the version, take a backup, test in a separate environment with the real configuration and then upgrade node by node when the version allows it; if not, with a short outage in an announced window. We restrict the admin console to specific networks, enable brute-force protection and monitor failed sign-ins from monitoring with Grafana and Prometheus.
Which applications can be connected?
Keycloak or Authentik?
Both provide single sign-on with OpenID Connect and SAML and two-factor authentication, and both are set up in your account. The real differences are these:
- Keycloak (Apache 2.0, a CNCF project): more mature with many users and for customer identity, with well-documented high availability and commercial support available if you need it. Its console is drier and the configuration more extensive.
- Authentik (core under the MIT licence and a paid Enterprise part): a friendlier console, sign-in flows you can draw and a built-in proxy to protect internal applications that know nothing about SSO, as well as serving LDAP to those that only speak that.
Our recommendation: for a company with many internal tools and a small team that will administer it, Authentik is usually the better fit. If identity is critical, or there are thousands of users or customers signing in to your product, Keycloak. We manage either with the same care: database backups, tested upgrades and the admin console locked down.
Where do we set it up?
In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.
Providers we set it up on
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Own server
| Provider | How we set it up | Things to bear in mind |
|---|---|---|
| Hetzner | Several Keycloak nodes on cloud servers or on Kubernetes, with replicated PostgreSQL managed by us, because Hetzner has no managed database. | The Hetzner load balancer spreads traffic across nodes; the database is the piece we look after most carefully. |
| AWS | Keycloak on ECS or EKS, with RDS or Aurora PostgreSQL behind an Application Load Balancer. | Database across several availability zones. |
| Google Cloud | Keycloak on GKE or Compute Engine, with Cloud SQL for PostgreSQL in high availability. | A good fit if employees already sign in with Google. |
| Azure | Keycloak on AKS or virtual machines, with Azure Database for PostgreSQL. | It is federated with Microsoft Entra ID so that employees sign in with their own account. |
| DigitalOcean | Keycloak on Droplets or DOKS, with DigitalOcean managed PostgreSQL. | |
| OVH | Keycloak on Public Cloud or Managed Kubernetes, with an OVHcloud managed database. | |
| Own server | Keycloak and PostgreSQL on your servers, alongside your Active Directory. | If Keycloak goes down, nobody can get into anything: here high availability matters more than in any other application. |
What is included
- Keycloak in your cloud account or on your server, with the realm and client configuration as code.
- Realms separated by use, for example employees and customers, each with its own policies.
- Two-factor authentication with an authenticator app or security keys and passkeys (WebAuthn).
- Federation with LDAP or Active Directory, or sign-in with Google or Microsoft.
- Your applications connected through OpenID Connect or SAML, with roles and groups.
- High availability with several nodes and a replicated database.
- Database backups and export of the realm configuration, with a test restore.
- Upgrades following the official guide, tested first in a separate environment.
Frequently asked questions
Is Keycloak a good open source alternative to Auth0 or Okta?
For most business uses, yes: SSO, two-factor authentication, federation and role management. The difference is that you have to run it yourselves, or have someone do it for you. In return, you do not pay per active user and the identity data stays in your account.
How do you migrate from Auth0 to Keycloak without people having to change their password?
There are two ways. If Auth0 gives you the password hashes, they are imported into Keycloak with the corresponding algorithm. If not, a gradual migration is done: each person is validated against the old system the first time they sign in and is then created in Keycloak. Whatever is not migrated is solved with a password reset.
Does Keycloak help us with NIS2 or the ENS?
It helps with part of it: two-factor authentication, role-based access control, centralised removal of leavers and a log of sign-ins are measures that both require. But no tool achieves compliance on its own; procedures, an inventory and incident management are also needed.
Who creates the users?
If Keycloak is federated with your directory, joiners and leavers are handled there and Keycloak applies the changes. If not, your company's administrator manages them from the console. We maintain the server and the configuration.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Official documentation consulted
The technical details on this page are based on:
Reviewed on