IAM en 2026 : pourquoi votre Keycloak est devenu la cible numéro un

Vous avez déployé Keycloak, Microsoft Entra ou Okta. Votre IAM est en production, votre SSO fonctionne, vos utilisateurs s'authentifient. Tout va bien. Sauf que vous venez peut-être de créer le point de défaillance le plus critique de toute votre infrastructure — et les attaquants le savent mieux que vous.

L'identité est le nouveau périmètre — et ce n'est plus une métaphore

Pendant des années, le périmètre de sécurité d'une organisation, c'était le réseau. Un pare-feu en entrée, un DMZ, des VLAN, et on dormait relativement bien. Ce modèle est mort. Pas en train de mourir — mort. Le rapport Verizon Data Breach Investigations Report 2025 confirme ce que les professionnels du terrain constatent depuis plusieurs années : plus de 80 % des compromissions impliquent des identifiants volés ou des abus de privilèges. Pas des exploits de vulnérabilités réseau sophistiqués — des identifiants. Des mots de passe. Des tokens. Des cookies de session.

La raison est structurelle. La migration massive vers le cloud, le travail hybride, la prolifération des applications SaaS, la multiplication des accès partenaires et prestataires ont fait éclater le périmètre réseau. Aujourd'hui, un employé accède à des ressources critiques depuis son domicile, via un téléphone personnel, sur un réseau inconnu, en passant par un VPN qui lui donne accès à Active Directory. Dans ce contexte, le seul périmètre de sécurité qui reste cohérent, c'est l'identité. Si vous contrôlez l'identité, vous contrôlez les accès. Si vous perdez le contrôle de l'identité, vous perdez tout.

C'est exactement ce qu'ont compris les attaquants. Les grandes compromissions des dernières années le confirment systématiquement : l'attaque contre Okta en 2022 puis 2023 via un sous-traitant, la compromission de Microsoft Entra en 2024 via une clé de signature MSA volée par Storm-0558, les multiples incidents documentés impliquant des tokens OAuth exfiltrés depuis des applications cloud mal configurées. Dans tous ces cas, la cible finale n'était pas le réseau — c'était le système d'identité, parce qu'une fois celui-ci compromis, tout le reste s'ouvre.

Le paradoxe du Zero Trust est ici brutal : en concentrant la confiance sur l'identité (« never trust, always verify »), vous avez créé un actif que les attaquants ont toutes les raisons de cibler en priorité. Si votre identité dit que l'accès est légitime, votre infrastructure entière s'exécute. L'attaquant n'a plus besoin de trouver une faille dans votre réseau ou vos applications : il lui suffit d'être vous.

Keycloak, Entra, Okta : trois architectures, trois surfaces d'attaque distinctes

Toutes les solutions IAM ne se ressemblent pas, et leurs surfaces d'attaque spécifiques méritent d'être analysées séparément plutôt que traitées comme un bloc homogène.

Keycloak, solution open source de la Fondation Red Hat, est devenu l'IAM de référence dans les architectures cloud-native et les organisations qui veulent maîtriser leurs données d'identité sans dépendre d'un éditeur propriétaire. Sa popularité est méritée — c'est un outil puissant, flexible, bien maintenu. Mais cette flexibilité est précisément son risque principal. Keycloak est déployé par des équipes de développement dont ce n'est pas le coeur de métier sécurité. Le résultat que j'observe régulièrement : console d'administration accessible sur internet sans restriction d'IP, realm par défaut (master) utilisé en production, client secrets faibles ou partagés entre plusieurs applications, configuration JWT sans restriction d'algorithmes, absence totale de monitoring des événements d'authentification dans le SIEM. Et pas de contrat de support pour pousser les patches. Les CVE de Keycloak s'accumulent tranquillement dans les NVD sans que personne ne les regarde.

Microsoft Entra (ex-Azure Active Directory) est la solution IAM de Microsoft, déployée en mode SaaS. La surface d'attaque est radicalement différente : vous ne gérez pas l'infrastructure, mais vous gérez une configuration d'une complexité redoutable. Conditional Access avec des exceptions qui s'accumulent. Comptes invités (guest) avec des permissions implicites sur les ressources SharePoint. Applications d'entreprise avec des permissions Microsoft Graph excessives. Hybrid Join qui ouvre des chemins d'attaque entre le domaine Active Directory on-premise et le tenant Azure. Clés de signature MSA mal protégées. En 2024, la compromission d'une clé de signing MSA par le groupe Storm-0558 a permis la génération de tokens valides pour n'importe quel compte Microsoft — un incident qui a mis des mois à être entièrement compris et remédié.

Okta est le leader du marché IAM SaaS pour les grandes organisations. Ses incidents de 2022 et 2023 ont exposé une surface d'attaque spécifique aux architectures SaaS : la dépendance aux sous-traitants. L'accès d'un technicien de support Okta à un système de gestion de tickets client a permis à des attaquants de voler des données d'authentification de centaines de clients d'Okta. Ce n'était pas une vulnérabilité dans le code d'Okta — c'était une compromission via la chaîne humaine d'un fournisseur SaaS. La leçon : quand vous déléguez votre IAM à un SaaS, vous héritez aussi de leur surface d'attaque supply chain.

Ces trois solutions illustrent un principe fondamental : la sécurité d'un IAM n'est pas binaire. Elle dépend de l'architecture choisie, des compétences de l'équipe qui l'opère, des politiques de configuration appliquées, et de la capacité à maintenir les patches et à détecter les incidents. Un Keycloak bien configuré et bien surveillé peut être plus sûr qu'un Entra mal administré — et inversement.

Anatomie des failles IAM récentes : ce que disent les CVE

Les vulnérabilités récemment publiées sur Keycloak illustrent concrètement les types de failles qui affectent les IAM modernes. Il ne s'agit pas de failles théoriques — elles reflètent des classes de problèmes observées régulièrement dans des audits réels.

CVE-2026-11800 est une vulnérabilité de JWT Algorithm Confusion dans le flux JWT Authorization Grant de Keycloak. Notée CVSS 8.1 (High), elle permet à un attaquant disposant de credentials client valides de contourner la vérification de signature JWT. Le mécanisme : si un serveur accepte à la fois l'algorithme asymétrique RS256 (RSA) et l'algorithme symétrique HS256 (HMAC), un attaquant peut signer un token JWT avec la clé publique RS256 (qui est — par définition — publique) en faisant croire au serveur que c'est une signature HMAC-SHA256. Le serveur vérifie la signature HS256 avec cette clé publique accessible à tous et valide le token. L'attaquant peut ainsi forger n'importe quel access token, impersonner n'importe quel utilisateur fédéré lié au provider affecté, et escalader ses privilèges sans avoir compromis aucun secret.

CVE-2026-9796 est une vulnérabilité de type TOCTOU (Time-of-Check to Time-of-Use) dans la validation des rôles admin de Keycloak, notée CVSS 6.5. Un administrateur authentifié avec le rôle manage-clients peut exploiter une condition de concurrence dans les vérifications de rôles basées sur le nom de client. Pendant la fenêtre entre la vérification de permission et son utilisation effective, l'attaquant modifie le nom de son client. Le système lie alors incorrectement le rôle composite realm-admin à l'attaquant, lui conférant des privilèges administrateur complets sur l'ensemble des utilisateurs du realm. Ce type de vulnérabilité de race condition dans du code d'autorisation est particulièrement insidieux car il est difficile à détecter via une revue de code statique.

Au-delà des CVE spécifiques à Keycloak, plusieurs classes de vulnérabilités affectent l'écosystème IAM dans son ensemble. L'OAuth implicit flow, aujourd'hui déprécié, expose les access tokens dans les redirections d'URL (et donc dans les logs de serveur, les référents HTTP, l'historique de navigation). Le token replay : des JWTs avec des durées de vie longues exfiltrés depuis des logs applicatifs, de la mémoire de processus ou du trafic réseau non chiffré peuvent être réutilisés sans limitation. Le client credentials flow avec client secrets faibles : des comptes de service avec des secrets prévisibles ou jamais rotés constituent des vecteurs d'entrée durables. Ces classes de problèmes sont transversales à toutes les implémentations IAM.

Ce que j'observe réellement sur le terrain

Sans nommer aucun client ni secteur qui permettrait une identification, voici ce que les audits IAM de ces derniers mois ont mis au jour de manière récurrente. Les patterns sont assez constants pour en tirer des conclusions générales.

La console d'administration Keycloak exposée sur internet est la première chose que je vérifie. Elle est accessible publiquement dans une proportion inquiétante des déploiements audités. Le port 8443, l'URL /auth/admin, parfois même sans HTTPS sur le port 8080 par paresse de configuration initiale jamais corrigée. La justification entendue : « c'est pour que les développeurs puissent y accéder en télétravail ». Solution correcte : un bastion SSH ou un VPN d'administration, pas une exposition directe.

Le realm master utilisé en production est la deuxième erreur classique. Le realm master dans Keycloak est conçu pour l'administration de Keycloak lui-même — pas pour héberger des utilisateurs et des applications. L'utiliser en production mélange les privilèges d'administration globale avec les accès applicatifs, créant des chemins d'escalade involontaires. Chaque application devrait avoir son propre realm avec des permissions strictement délimitées.

L'absence de rotation des client secrets est quasi-universelle dans les déploiements que j'audite. Des comptes de service applicatifs avec des secrets créés le jour du déploiement initial — parfois il y a trois ou quatre ans — et jamais changés depuis. Ces secrets ont souvent tourné dans des repositories Git (éventuellement publics ou avec accès étendu), des fichiers de configuration déployés sur des serveurs sans chiffrement au repos, des dashboards de monitoring. Un secret qui a « fuité » il y a deux ans dans un repository interne est potentiellement entre les mains d'un ancien développeur, d'un prestataire externe, ou d'un acteur ayant accès aux archives Git.

Le manque de visibilité sur les événements Keycloak est peut-être le problème le plus grave. Keycloak génère des événements de sécurité détaillés : connexions réussies et échouées, changements de configuration, accès admin, modifications de realm. Ces événements sont disponibles dans la base de données et via les event listeners. Dans la grande majorité des déploiements audités, ces événements ne sont collectés nulle part, n'arrivent dans aucun SIEM, ne déclenchent aucune alerte. Un attaquant peut effectuer mille tentatives d'authentification sur un compte sans que personne ne soit notifié.

L'absence de MFA sur les comptes admin Keycloak est la cerise sur le gâteau. Vous avez peut-être configuré le MFA pour vos utilisateurs finaux — bravo — mais l'accès à la console d'administration de Keycloak, qui donne un contrôle total sur l'ensemble du système d'identité, est protégé par un simple mot de passe. Parfois le mot de passe par défaut du déploiement initial n'a jamais été changé.

Les 10 contrôles IAM qui changent vraiment quelque chose

Il ne s'agit pas d'une liste exhaustive de toutes les bonnes pratiques IAM — il en existe des centaines. Il s'agit des contrôles qui, d'après mon expérience terrain, ont le meilleur rapport impact/effort et qui sont le plus souvent absents dans les déploiements réels.

1. Restreindre l'accès à la console d'administration. Jamais exposée directement sur internet. Accès uniquement depuis les réseaux d'administration, via un bastion ou un VPN dédié. ACL au niveau réseau en plus des contrôles applicatifs.

2. MFA obligatoire sur tous les comptes admin Keycloak/Entra/Okta. Sans exception. Y compris les comptes de break-glass (qui ont leurs propres procédures de gestion). L'authentificateur TOTP est suffisant si FIDO2 n'est pas encore déployé.

3. Interdire les algorithmes JWT faibles. Configurer explicitement Keycloak pour n'accepter que RS256 ou ES256 comme algorithmes de signature. Désactiver HS256 dans la configuration des realms et des clients. Vérifier la configuration des Identity Providers fédérés.

4. Rotation des client secrets sur un cycle régulier. Maximum 12 mois, idéalement 6. Automatiser la rotation via votre gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) plutôt que de la gérer manuellement. Auditer les secrets créés depuis plus d'un an.

5. Intégrer les événements Keycloak dans le SIEM. Configurer le Event Listener SPI de Keycloak pour exporter les événements vers votre SIEM (Splunk, Elastic, Wazuh). Créer des alertes sur les connexions admin, les changements de realm, les tentatives d'authentification répétées, les connexions hors heures ouvrées.

6. Realm master uniquement pour l'administration Keycloak. Migrer toutes les applications et utilisateurs vers des realms dédiés. Réserver le realm master aux opérations de gestion de Keycloak uniquement, avec un nombre minimal d'administrateurs globaux.

7. Appliquer les patches Keycloak sans délai. Suivre le flux de CVE Keycloak (Red Hat Security Advisories, NVD) et définir un SLA de patch maximum de 30 jours pour les CVE critiques, 7 jours pour les CVE exploitées activement. Ce SLA doit être formalisé et suivi.

8. Durée de vie des tokens adaptée au risque. Access tokens : 5 à 15 minutes maximum. Refresh tokens : durée de session utilisateur (8 heures pour une journée de travail). Désactiver le refresh token tournant uniquement si votre architecture ne le supporte pas techniquement, et documenter ce choix.

9. Auditer régulièrement les clients OAuth et leurs permissions. Désactiver les clients inutilisés. Supprimer les permissions excessives. Vérifier que chaque client n'a accès qu'aux scopes dont il a strictement besoin. Un audit annuel minimum, idéalement à chaque revue d'accès trimestrielle.

10. Plan de résilience IAM documenté et testé. Que se passe-t-il si Keycloak tombe ? Avez-vous des comptes de break-glass locaux sur vos systèmes critiques ? Un backup de la configuration du realm ? Une procédure de restauration testée ? L'IAM est un SPOF (Single Point of Failure) que trop d'organisations ne traitent pas comme tel.

Et si votre IAM tombait demain — avez-vous un plan ?

La résilience de l'IAM est un angle mort dans beaucoup d'organisations. On passe du temps à sécuriser l'IAM contre les attaques externes, et on oublie de se demander ce qui se passe quand l'IAM lui-même est indisponible — que ce soit à cause d'une attaque, d'une panne, ou d'une mise à jour ratée.

Dans les architectures qui dépendent intégralement du SSO Keycloak ou Entra, une indisponibilité de l'IAM peut signifier l'impossibilité totale pour les utilisateurs de se connecter à leurs outils de travail. Les applications, les VPN, les accès aux serveurs — tout est conditionné à la disponibilité de l'IAM. J'ai vu des organisations incapables d'accéder à leurs propres systèmes de monitoring pendant une panne IAM — ce qui rend le diagnostic exponentiellement plus difficile.

Les contrôles de résilience minimaux : des comptes locaux de break-glass documentés et sécurisés sur chaque système critique (avec procédure d'accès physique pour les secrets de ces comptes), un backup automatique et testé de la configuration des realms Keycloak, une procédure de restauration validée en conditions réelles au moins une fois par an, et une architecture haute disponibilité (cluster Keycloak avec base de données répliquée) pour tout environnement de production.

La résilience de l'IAM n'est pas un luxe — c'est une exigence opérationnelle de base dans tout système sur lequel votre organisation dépend pour fonctionner.

Conclusion

L'identité est le périmètre. Ce n'est plus une tendance — c'est la réalité opérationnelle de 2026. Les attaquants ont parfaitement intégré que compromettre un IAM leur donne les clés du royaume, et ils ciblent ces systèmes avec une sophistication croissante, comme l'illustrent les CVE Keycloak récentes (CVE-2026-11800, CVE-2026-9796) et les incidents majeurs documentés chez Okta et Microsoft.

La bonne nouvelle : la plupart des vecteurs d'attaque contre les IAM ne sont pas des 0-days impossibles à anticiper. Ce sont des erreurs de configuration, des politiques de maintenance défaillantes, et des lacunes de visibilité que des mesures concrètes permettent de corriger. Les 10 contrôles détaillés dans cet article ne sont pas des projets de 6 mois — plusieurs peuvent être appliqués en quelques heures. Commencez par restreindre l'accès à votre console d'administration, activez le MFA sur les comptes admin, et connectez vos logs d'événements IAM à votre SIEM. Le reste suivra.

Si vous n'avez pas de visibilité sur ce que fait votre IAM en ce moment — qui s'y connecte, quels clients OAuth sont actifs, quels comptes admin existent — c'est le signe qu'un audit s'impose avant que quelqu'un d'autre ne le fasse à votre place.