Pourquoi et comment implémenter Keycloak pour sécuriser une architecture SaaS multi-tenant ?

Introduction : Le piège de la gestion d’identité dans le SaaS

Quand on lance un SaaS B2B, l’authentification est souvent reléguée au second plan. On commence par coder une table users classique avec un hash de mot de passe, puis on ajoute un système de rôles basique.

Puis arrivent les premiers “vrais” clients B2B (grands comptes, banques, institutions publiques). Leurs exigences tombent :

“Nous voulons nous connecter avec notre propre SSO (Azure AD / Okta).”
“Vos données doivent être totalement isolées, nous exigeons un cloisonnement strict.”
“Comment gérez-vous l’isolation des identités et la conformité RGPD ?”

C’est là que le château de cartes s’effondre. Réécrire un moteur d’identité à ce stade coûte des mois de développement et expose à des failles de sécurité majeures.

En tant qu’ex-CTO ayant piloté des architectures critiques (IDPosition, Haute Autorité de Santé), ma philosophie est claire : “Penser juste, structurer bien, délivrer mieux”. Pour résoudre définitivement ce problème, le choix d’un Identity Provider (IdP) robuste, open-source et standardisé s’impose. Keycloak est ce standard.

Voici le guide d’architecture pour concevoir un socle d’identité “Enterprise-grade”.

1. Choix d’Architecture : Single Realm vs Multi-Realms

La première décision structurante dans Keycloak concerne la gestion du multi-tenant. Deux approches s’affrontent, avec des compromis majeurs en termes de sécurité, de maintenance et de scalabilité.

Option A : Le modèle “Multi-Realms” (Le choix de la sécurité maximale)

Chaque client (tenant) possède son propre Realm Keycloak dédié.

Avantages :
- Isolation absolue au niveau de la base de données Keycloak.
- Chaque client peut configurer ses propres fournisseurs d’identité (IdP tiers), ses propres règles de mot de passe (MFA obligatoire ou non), et ses propres chartes graphiques de login.
- RGPD-compliant by design : la suppression d’un client équivaut à la suppression de son realm.
Inconvénients :
- Complexité opérationnelle à grande échelle (gérer 500 realms nécessite une automatisation stricte via API ou Terraform/GitOps).
- Consommation de ressources Keycloak plus élevée (mémoire).

Option B : Le modèle “Single Realm avec Groupes/Attributs”

Tous les utilisateurs de tous les clients partagent le même Realm, mais sont cloisonnés via des groupes Keycloak ou des attributs utilisateur.

Avantages :
- Très simple à administrer.
- Performance optimale au démarrage (faible empreinte mémoire).
Inconvénients :
- Risque de fuite de données (une erreur de configuration dans le code applicatif peut exposer les utilisateurs d’un autre tenant).
- Personnalisation très limitée pour les clients exigeants (SAML/OIDC sur mesure difficiles à isoler).

Le Rex de l’ex-CTO : Voici une règle d’or simple, résumée en une seule question clé : « Un utilisateur doit-il pouvoir naviguer entre vos applications avec la même session (SSO), ou chaque client est-il un monde 100 % étanche qui exige ses propres utilisateurs, ses propres règles et ses propres administrateurs ? »

Comment trancher immédiatement grâce à cette question :

Choisissez le Single Realm (avec Clients ou la fonction Organizations) si vous voulez que vos utilisateurs se connectent une seule fois (SSO), ou si vous souhaitez centraliser la configuration (LDAP, MFA, thèmes).

Choisissez le Multi-Realm si vous vendez votre SaaS à des entreprises clientes qui exigent une isolation absolue (aucun partage d’utilisateurs, politiques de mots de passe personnalisées par client, ou administration déléguée totalement indépendante), quitte à renoncer au SSO entre elles.

2. Déploiement Industriel : Kubernetes, Helm & GitOps

Déployer Keycloak en mode “clic-bouton” sur une machine virtuelle est une hérésie pour un projet de production. Keycloak doit être traité comme un composant d’infrastructure as Code (IaC).

La stack recommandée :

Orchestration : Kubernetes (GKE sur Google Cloud ou Scaleway pour la souveraineté européenne).
Packaging : Charts Helm pour standardiser le provisionnement.
CI/CD : ArgoCD (GitOps) pour synchroniser l’état de l’infrastructure avec votre dépôt Git privé.

# Exemple de configuration Helm unifiée pour ArgoCD (values.yaml simplifié)
keycloak:
  replicaCount: 3 # Haute disponibilité
  database:
    vendor: postgres
    host: postgres-ha-pool
  ingress:
    enabled: true
    rules:
      - host: auth.votre-saas.com

Le pipeline de provisioning d’un nouveau client (Tenant) :

L’application SaaS déclenche une commande via l’API Keycloak.
Un script Python automatise la création du Realm spécifique.
Importation du template de configuration standard (rôles par défaut, thèmes, clients OIDC).
Génération des DNS et intégration Cloudflare pour protéger des attaques DDoS.

3. Sécurité : Flux sur mesure et protection d’infrastructure

Custom Authentication Flows (Magic Links & Passwordless)

Keycloak permet de surcharger les flux d’authentification par défaut. Pour optimiser l’UX de vos clients tout en maintenant un niveau de sécurité optimal :

Bannissez les mots de passe simples pour les administrateurs et forcez l’authentification WebAuthn (Passkeys / Biométrie) ou des Magic Links temporaires envoyés par email.
Configurez des flux conditionnels : si l’adresse IP de connexion sort du réseau VPN de l’entreprise cliente, Keycloak exige instantanément une double authentification (MFA).

La barrière Cloudflare

Ne laissez jamais vos endpoints Keycloak (/auth) exposés directement sur le web sans protection. Cloudflare doit être configuré en amont pour :

Filtrer les requêtes malveillantes (WAF).
Bloquer les attaques par force brute sur les formulaires de login.
Limiter le trafic (Rate Limiting) sur les endpoints sensibles d’authentification.

4. Le piège du Scale : Keycloak + OpenFGA (Double couche RBAC/ReBAC)

C’est ici que se joue la différence entre une architecture d’amateur et une conception professionnelle.

Le problème : L’explosion du token JWT (RPT)

Keycloak excelle pour l’authentification (qui est l’utilisateur) et l’autorisation macro (RBAC : est-il “Admin” ou “User”). Cependant, si vous essayez de gérer des droits ultra-fins (ReBAC : “Nicolas peut modifier le document X uniquement si le document X appartient au dossier Y pour lequel il a un droit d’accès”), vous allez stocker trop de données dans le jeton d’accès (JWT).

Le jeton (RPT - Requesting Party Token) devient gigantesque, dépasse la taille limite des en-têtes HTTP de vos serveurs web (souvent 8 KB) et provoque des erreurs de connexion inexplicables pour vos utilisateurs les plus actifs.

La solution : L’architecture double couche

[Utilisateur] -> Authentification -> [ KEYCLOAK ] (Génère le JWT macro)
                                          |
                                          v (Vérification fine à la volée)
[ API SaaS ] <---------------------> [ OpenFGA ] (Moteur de relations / ReBAC)

Keycloak gère l’authentification globale et fournit un token JWT épuré contenant uniquement l’ID du client, l’ID de l’utilisateur et son rôle macro.
OpenFGA (Fine-Grained Authorization, basé sur le modèle Zanzibar de Google) gère à la volée les droits d’accès fins sur les ressources.
Pour lier les deux sans friction, implémentez un plugin comme keycloak-openfga-event-publisher afin de propager en temps réel les événements de création d’utilisateurs ou de rôles de Keycloak vers OpenFGA.

Conclusion : Les 3 règles d’or pour réussir votre migration IAM

Pensez isolation dès le premier jour : Le multi-realm est exigeant mais c’est le seul garant de votre crédibilité face aux grands comptes.
Automatisez tout : Si vous devez configurer un realm à la main dans la console Keycloak en production, votre architecture n’est pas scalable.
Séparez l’authentification de l’autorisation fine : Laissez Keycloak gérer l’identité, et déléguez l’arborescence complexe de vos droits à un moteur dédié comme OpenFGA.