Keycloak : c'est quoi et à quoi ça sert en 2026 ?

Keycloak est un Identity Provider (IdP) open source publié sous licence Apache 2.0, qui implémente les standards d'authentification et d'autorisation modernes (OpenID Connect 1.0, OAuth 2.0, SAML 2.0, SCIM 2.0, FAPI 2.0, FIDO2/WebAuthn). Il fournit single sign-on (SSO) entre applications, gestion centralisée des utilisateurs et rôles, fédération d'identités vers des providers externes (Google, GitHub, LDAP/AD, autres SAML/OIDC), authentification multi-facteurs (TOTP, WebAuthn, passkeys), et plus de 1 000 fonctionnalités IAM. Initialement créé par Red Hat en 2014, devenu projet CNCF Sandbox en 2023, distribué en versions communautaire (Keycloak) et commerciale supportée (Red Hat build of Keycloak, ex Red Hat SSO). En 2026, Keycloak est l'IdP open source le plus déployé en entreprise, alternative dominante à Auth0, Okta Workforce, Azure Entra ID dans les organisations qui veulent self-hoster pour des raisons de coût (gratuit), souveraineté (données restent on-premise), ou exigences réglementaires. Cet article détaille l'architecture conceptuelle (realms, clients, users, roles, authentication flows), les standards supportés, les cas d'usage workforce et customer IAM, les options de déploiement Kubernetes et bare metal, la comparaison avec les alternatives (Authentik, Auth0, Okta, Azure Entra ID, Ory Hydra, FusionAuth), le hardening sécurité et les pièges courants.

Origines et positionnement

Keycloak est né en 2014 chez Red Hat sous l'impulsion de Bill Burke, comme refonte du projet PicketLink. Premier release stable 1.0 en septembre 2014. Adoption rapide grâce à trois caractéristiques : open source intégral, support des standards modernes dès le départ (SAML 2.0 et OIDC), expérience admin web complète sans configuration XML.

Évolution majeure en avril 2022 avec Keycloak 17.0 : migration de l'application server WildFly (Java EE) vers Quarkus (framework Kubernetes-native). Démarrage 5 à 10 fois plus rapide, footprint mémoire réduit de 60 %, meilleure intégration native containers.

Mai 2023 : Keycloak rejoint la CNCF (Cloud Native Computing Foundation) comme Sandbox project. Cela renforce son indépendance vis-à-vis de Red Hat (acquis par IBM en 2019) et son adoption cloud-native.

En 2026, Keycloak est mature : version stable 26.x, plus de 25 000 stars GitHub, déployé par des dizaines de milliers d'organisations dans le monde dont plusieurs CAC 40 français, banques européennes, ministères français (services publics français Internet utilisent Keycloak comme IdP central pour FranceConnect-like internal).

Architecture conceptuelle

Keycloak organise les identités et accès via 7 concepts principaux à comprendre avant tout déploiement.

Realms

Un realm est un espace d'isolation logique dans Keycloak. Chaque realm a ses propres utilisateurs, clients, rôles, authentication flows, identity providers fédérés. Les realms ne se voient pas entre eux.

Pattern type :

• master realm : réservé exclusivement à l'administration de Keycloak lui-même. Les admins Keycloak vivent ici. Jamais d'application business dans le master.
• production realm (par exemple acme-prod) : utilisateurs et applications de production.
• staging realm (acme-staging) : environnement de test isolé.
• partners realm : si fédération B2B avec partenaires externes.

Une organisation moyenne maintient typiquement 2 à 5 realms.

Clients

Un client représente une application qui s'authentifie via Keycloak. Configuration par client :

• Client ID : identifiant unique (par exemple web-frontend, mobile-app, backend-api).
• Access Type : confidential (avec secret, pour backend), public (sans secret, pour SPA et mobile), bearer-only (resource server qui valide tokens uniquement).
• Authentication Flow : Authorization Code (web), Authorization Code + PKCE (SPA, mobile), Client Credentials (machine-to-machine), Implicit (déprécié), Direct Access Grants (déprécié).
• Redirect URIs : URLs autorisées pour callback OAuth (CRUCIAL pour sécurité).
• Web Origins : pour CORS.
• Roles : rôles spécifiques au client.

Users

Identités utilisateurs gérées dans le realm. Attributs : username, email, first/last name, attributs custom. Peuvent être créés manuellement, importés via SCIM, fédérés depuis LDAP/AD, ou importés depuis identity providers externes (Google, GitHub).

Roles et Groups

• Realm roles : rôles globaux au realm (par exemple admin, user).
• Client roles : rôles spécifiques à un client (par exemple frontend.viewer, frontend.editor).
• Groups : ensembles d'utilisateurs avec rôles attribués collectivement.
• Composite roles : rôles composés d'autres rôles (héritage).

Identity Providers

Keycloak peut fédérer l'authentification vers des providers externes : Google, GitHub, Microsoft, Apple ID (OIDC), partenaires externes via SAML, Active Directory et LDAP via federation. L'utilisateur s'authentifie chez le provider externe, Keycloak crée ou matche l'identité locale.

Authentication Flows

Les flows définissent les étapes de l'authentification : username/password, MFA, conditions, captcha, etc. Configurables visuellement dans l'admin console. Peuvent être customisés par client ou par realm.

Exemple flow type 2026 :

1. Cookie (vérifie session existante) — bypass si déjà loggé
2. Identity Provider Redirector (option SSO externe)
3. Username / Password / Passkey (alternatives possibles)
4. Conditional MFA (si profil utilisateur l'exige)
   ├── Conditional WebAuthn (si passkey enregistrée)
   └── OTP Form (TOTP fallback)
5. Required Actions (changement password, configuration MFA)

Sessions

Keycloak gère les sessions utilisateur côté serveur (caches Infinispan distribué) et émet des tokens (access token JWT, refresh token, ID token OIDC) pour les clients. Configuration des durées par realm.

Standards supportés

Keycloak implémente l'écosystème standard IAM en 2026.

Cas d'usage par standard

• OIDC : SSO moderne pour applications web (frontend → backend), mobile, SPA. Standard recommandé pour tout nouveau projet 2026.
• SAML 2.0 : intégration applications enterprise legacy (SAP, Salesforce, applications internes anciennes), fédération B2B traditionnelle.
• OAuth 2.0 Client Credentials : authentification machine-to-machine entre microservices.
• SCIM 2.0 : synchronisation utilisateurs entre Keycloak et applications (création, modification, suppression utilisateurs propagées automatiquement).
• FIDO2 : remplacement des mots de passe par passkeys, MFA fort résistant phishing.

Cas d'usage typiques 2026

Quatre catégories d'usage couvrent la majorité des déploiements.

Workforce SSO

Authentification des collaborateurs internes pour les applications de l'entreprise (intranet, outils SaaS, applications métier). Keycloak en frontage des applications, fédération vers Active Directory ou Entra ID pour ne pas dupliquer les comptes.

Avantages vs Okta Workforce : coût (gratuit), souveraineté (données on-prem ou cloud privé), customisation poussée.

Customer IAM (CIAM)

Authentification des clients finaux pour les services en ligne (web, mobile). Keycloak gère l'inscription, login, reset password, MFA, fédération réseaux sociaux.

Avantages vs Auth0 : pas de coût par utilisateur actif (Auth0 facture par MAU), contrôle complet de l'expérience UX via theming.

Limites : nécessite du tooling DevOps interne pour gérer l'infrastructure à grande échelle (millions d'utilisateurs).

Machine-to-machine et microservices

Authentification entre services internes via OAuth 2.0 Client Credentials grant. Chaque service a son client Keycloak, obtient des access tokens JWT que les autres services valident.

Pattern moderne : intégration avec service mesh (Istio, Linkerd) qui valide les JWT au niveau sidecar plutôt que dans le code applicatif.

Fédération B2B

Permettre à des partenaires externes (clients, fournisseurs) d'accéder à des applications avec leur propre identité (chez eux). Keycloak agit comme service provider qui fédère vers les IdPs externes des partenaires (SAML 2.0 ou OIDC).

Architecture de déploiement

Trois options selon contexte 2026.

Kubernetes via Keycloak Operator

Recommandé pour 80 % des nouveaux déploiements. L'Operator officiel (CNCF, depuis 2022) gère le cycle de vie complet.

# Déploiement Keycloak via Operator
apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: keycloak-prod
  namespace: keycloak
spec:
  instances: 3
  image: quay.io/keycloak/keycloak:26.0.7
  db:
    vendor: postgres
    host: postgres-keycloak
    database: keycloak
    usernameSecret:
      name: keycloak-db-credentials
      key: username
    passwordSecret:
      name: keycloak-db-credentials
      key: password
  hostname:
    hostname: auth.example.test
  http:
    tlsSecret: keycloak-tls
  proxy:
    headers: xforwarded
  resources:
    limits:
      memory: "2Gi"
      cpu: "2"
    requests:
      memory: "1Gi"
      cpu: "500m"

Configurations supplémentaires recommandées en production :

• Base PostgreSQL externe : jamais H2 embarqué (par défaut, dev uniquement). PostgreSQL 14+ recommandé.
• 3 replicas minimum pour haute disponibilité.
• Sessions partagées via Infinispan (par défaut dans le cluster Keycloak).
• Reverse proxy (Ingress NGINX, Traefik, Istio) avec TLS et headers X-Forwarded-* configurés.
• Backups automatiques de la base PostgreSQL (objet de l'opérationnel critique).

JAR standalone Quarkus

Pour VMs ou bare metal sans Kubernetes. Distribution depuis Keycloak 17.0.

# Téléchargement et démarrage
wget https://github.com/keycloak/keycloak/releases/download/26.0.7/keycloak-26.0.7.tar.gz
tar -xzf keycloak-26.0.7.tar.gz
cd keycloak-26.0.7
 
# Build initial avec configuration
bin/kc.sh build --db=postgres --features=passkeys
 
# Configuration via env vars
export KC_DB_URL=jdbc:postgresql://postgres:5432/keycloak
export KC_DB_USERNAME=keycloak
export KC_DB_PASSWORD=<secret>
export KC_HOSTNAME=auth.example.test
export KC_PROXY=edge
 
# Démarrage production
bin/kc.sh start

OpenShift

Pour les clients Red Hat OpenShift, Operator natif (Red Hat build of Keycloak Operator) avec intégration native OpenShift Routes, Secrets, monitoring Prometheus.

Hardening Keycloak en production

Sept contrôles cumulatifs à appliquer pour tout déploiement production.

1. Isoler le master realm

Créer un realm dédié (production, app-1, etc.) pour toute application business. Ne jamais utiliser le master realm pour autre chose que l'administration Keycloak elle-même.

2. Restreindre l'admin console

L'admin console (/admin/) ne doit jamais être exposée à Internet sans contrôles supplémentaires :

# nginx : restriction admin console par IP
location /admin/ {
    allow 10.0.0.0/8;       # IPs internes
    allow 203.0.113.0/24;   # bastion VPN
    deny all;
    proxy_pass http://keycloak;
}
 
# Le reste (login users, OIDC endpoints) accessible publiquement
location / {
    proxy_pass http://keycloak;
}

Alternative : déploiement de deux instances Keycloak séparées (frontend public, admin private).

3. Configurer Client redirect URIs strictement

Ne jamais utiliser de wildcard * ou de pattern trop large dans les Valid Redirect URIs.

# Mauvais (vulnérable à OAuth code interception)
Valid Redirect URIs:
- *
- https://*.example.test/*
 
# Bon
Valid Redirect URIs:
- https://app.example.test/auth/callback
- https://app.example.test/silent-renew

4. Activer PKCE pour clients publics

Pour SPA et mobile (clients publics sans secret), activer PKCE obligatoire (Authorization Code + PKCE flow uniquement). Évite l'attaque OAuth code interception.

5. Désactiver les flows dépréciés

Désactiver Implicit Flow et Direct Access Grants (Resource Owner Password Credentials) au niveau de chaque client. Ces flows sont dépréciés par OAuth 2.1 (draft) et OWASP API Security Top 10.

6. Hardening Authentication Flows

• MFA obligatoire pour les comptes admin du realm.
• MFA conditionnel pour les utilisateurs (basé sur risk score si plugin disponible).
• Brute force detection activé (par défaut depuis 17.0).
• CAPTCHA sur registration et reset password si exposé Internet.

7. Patch management trimestriel

Keycloak a eu plusieurs CVE notables 2023-2024 :

• CVE-2023-0264 (CVSS 6.5) : information disclosure via SAML.
• CVE-2023-6927 (CVSS 6.4) : path traversal.
• CVE-2024-1132 (CVSS 8.1) : path traversal critique.
• CVE-2024-1722 (CVSS 8.1) : DoS via authentication brute force.

Suivre les Keycloak security advisories (keycloak.org/security) et patcher dans les 30 jours pour CVE haute, sous 7 jours pour critique.

Comparaison avec alternatives

L'écosystème IAM en 2026 inclut plusieurs alternatives selon contexte.

Quand choisir Keycloak

• Volume utilisateurs significatif (5 000+ MAU) où Auth0/Okta deviennent coûteux.
• Compétence DevOps interne disponible pour opérer self-hosted.
• Souveraineté ou compliance exige données on-premise ou cloud privé.
• Besoin de standards complets (FAPI 2.0 pour banking).
• Besoin de customisation poussée (theming, plugins).

Quand préférer alternative

• Volume faible (moins de 5K MAU) + démarrage rapide : Auth0 ou FusionAuth Community.
• Écosystème Microsoft déjà déployé : Azure Entra ID natif.
• Architecture moderne API-first sans admin UI : Ory.
• Très grande scale enterprise (millions+) avec budget : ForgeRock ou Auth0 Enterprise.

Limites et pièges

Quatre limitations à connaître avant adoption.

Complexité opérationnelle

Keycloak en production nécessite :

• HA cluster (3+ replicas, base PostgreSQL HA, sessions Infinispan).
• Backups réguliers et testés.
• Patch management trimestriel.
• Monitoring (Prometheus, alerting sur availability).
• Expertise interne pour debugger configurations Authentication Flows complexes.

Coût opérationnel typique : 0,3 à 0,5 ETP DevOps pour un déploiement de moins de 100K utilisateurs, 1 ETP et plus pour plus de 1M utilisateurs.

Migrations majeures

Migrer entre versions majeures peut être complexe :

• Migration WildFly → Quarkus (16.x → 17.x) : changement complet de mécanisme de configuration. Beaucoup de scripts à réécrire.
• Migration JSON storage → DB schema : modifications de schema PostgreSQL requises.

Toujours tester en environnement non-prod avant migration prod.

Performance à très grande échelle

Au-delà de 10 millions d'utilisateurs, Keycloak peut nécessiter optimisations spécifiques (cache tuning, base sharding). Auth0 et Okta sont mieux outillés pour ce scale extrême par construction SaaS.

UX admin moins moderne que concurrents

L'admin console Keycloak, bien que fonctionnelle, est moins polished que celles d'Okta ou Auth0. Pour des organisations qui valorisent l'UX admin pour des non-techniques, c'est un frein.

Points clés à retenir

• Keycloak est l'Identity Provider open source de référence en 2026, sous Apache 2.0, projet CNCF Sandbox depuis 2023, distribué en versions communautaire et commerciale (Red Hat build of Keycloak).
• Architecture conceptuelle : realms (isolation), clients (applications), users, roles/groups, identity providers fédérés, authentication flows, sessions. Master realm dédié à l'admin Keycloak uniquement.
• Standards complets supportés : OIDC 1.0, OAuth 2.0 + PKCE, SAML 2.0, SCIM 2.0, FAPI 2.0, FIDO2/WebAuthn, TOTP. Permet workforce SSO, customer IAM, machine-to-machine, fédération B2B.
• Déploiement recommandé 2026 : Kubernetes via Keycloak Operator officiel, base PostgreSQL externe, 3+ replicas, reverse proxy avec TLS et headers X-Forwarded.
• Hardening obligatoire : isoler master realm, restreindre admin console, redirect URIs strictes, PKCE pour clients publics, désactiver flows dépréciés (Implicit, Direct Access Grants), patch management trimestriel.

Pour aller plus loin

• Qu'est-ce que l'IAM - définition et concepts fondamentaux IAM avant Keycloak.
• Pourquoi l'identité est centrale en cybersécurité - pillar page sur l'enjeu IAM moderne.
• IAM expliqué simplement - perspective cloud-native complémentaire.
• Gestion de session sécurisée - applicatif consommateur des sessions Keycloak.