Connexion confiée à un serveur Java incubé à la CNCF
Keycloak est un serveur de gestion d'identité et d'accès écrit en Java, sous licence Apache 2.0. Les applications lui confient la connexion : elles renvoient l'utilisateur vers Keycloak, qui l'authentifie et leur rend un jeton signé en OpenID Connect, OAuth 2.0 ou SAML 2.0, sans qu'elles voient jamais un mot de passe. Les comptes vivent dans la base de Keycloak ou dans un annuaire LDAP ou Active Directory qu'il fédère, rangés par realms isolés les uns des autres. Le projet est en incubation à la CNCF depuis le 10 avril 2023.
Le comparatif des outils de SSO auto-hébergés met en regard ce que demande Keycloak et ce que demandent les autres outils.
Annuaires existants conservés, autorisations au-delà des rôles
- OpenID Connect, OAuth 2.0 et SAML 2.0 côté applications, avec une déconnexion unique qui ferme la session sur toutes les applications reliées.
- Les annuaires existants restent en place : LDAP et Active Directory, pont Kerberos, SSSD et FreeIPA, ou une SPI pour tout autre stockage d'utilisateurs. Un fournisseur OpenID Connect ou SAML externe, ou un réseau social comme Google ou GitHub, se déclare dans la console sans toucher au code des applications.
- MFA et authentification forte intégrés : TOTP et HOTP, passkeys et WebAuthn, codes de récupération, plus les certificats X.509 et l'authentification renforcée par étape.
- Des flux d'authentification que l'on recompose dans la console. Quand les passkeys sont activées, le flux par défaut saute le second facteur pour l'utilisateur qui s'est connecté avec l'une d'elles.
- Des autorisations au-delà des rôles : les services d'autorisation gèrent des politiques fines depuis la même console, et l'API SCIM de gestion des utilisateurs et des groupes est prise en charge depuis la 26.8.0.
Prévoir JVM, base relationnelle et 1,25 Go par instance
Une JVM et une base relationnelle, obligatoirement. Keycloak tourne sur OpenJDK 17, 21 ou 25 ; l'image officielle embarque OpenJDK 21. La base dev-file utilisée par défaut est réservée au développement : la production demande PostgreSQL (14 à 18), MariaDB, MySQL, SQL Server ou Oracle, seul moteur dont le pilote JDBC n'est pas livré.
Environ 1,25 Go de mémoire par instance. Le guide de dimensionnement compte 1 250 Mo par instance, caches et 10 000 sessions compris, et le guide des conteneurs recommande une limite de 2 Go pour les petits déploiements de production. Sans limite, le tas Java peut grimper jusqu'à 70 % de la mémoire du conteneur. À titre de repère, Zitadel annonce environ 512 Mo pour son propre processus, et authentik demande au moins 2 cœurs et 2 Go pour son installation Docker Compose.
Le processeur part dans le hachage des mots de passe. Le guide de dimensionnement prévoit 1 vCPU pour 15 connexions par mot de passe et par seconde, avec Argon2 par défaut, plus 150 % de marge pour les pics et les bascules.
Le mode production s'arrête sans nom d'hôte ni TLS. Sans configuration supplémentaire, kc.sh start désactive HTTP et s'arrête sur une erreur ; start-dev sert à l'essai. Les options de build, dont le choix de la base, se figent avec kc.sh build dans une image optimisée, que l'opérateur Kubernetes exige pour toute image sur mesure.
Une production typique compte deux instances ou plus. Elles forment une grappe Infinispan et JGroups pour que la connexion survive à la perte de l'une d'elles. La documentation de production couvre des déploiements de quelques milliers d'utilisateurs sur site jusqu'à plusieurs millions. Sur Kubernetes, la plateforme prise en charge est OpenShift 4.18 à 4.21 ; EKS, AKS et les autres distributions n'ont droit qu'à un support au mieux.
Quatre versions mineures par an. Le rythme, annoncé en octobre 2024 après la 26.0, prévoit aussi une majeure tous les deux à trois ans, et des changements cassants activés sur option jusqu'à la majeure suivante. Il tient en 2026 : 26.5 en janvier, 26.6 en avril, 26.7 en juillet, 26.8.0 le 1er octobre. La branche 26.7 a reçu son cinquième correctif la veille de la 26.8.0.