Aller au contenu principal

Ressources

Keycloak, c'est quoi et quand le choisir (ou pas) face aux IdP managés et aux alternatives open source

Keycloak c'est quoi ? SSO, OIDC, SAML et MFA expliqués, coût réel d'exploitation et comparaison avec Entra ID, Auth0, Cognito, authentik et ZITADEL.

Par , publié le · 20 min de lecture

Base d'expérience : Méthode et documentation officielle (documentation et code de Keycloak 26.7.4, politique de publication du projet, pages officielles des solutions comparées) ; opérateur Keycloak open source publié par CTN Solutions sous licence Apache 2.0 ; sans donnée, configuration ni référence client.

Relecture factuelle : Claude Code (revue indépendante déléguée par Corentin Mas, 28/09/2026), le

Une plateforme qui grandit doit tôt ou tard centraliser l'authentification : applications multiples, clients qui veulent utiliser le compte de leur entreprise, questionnaire de sécurité sur la double authentification. Keycloak fait alors partie des candidats, à côté d'Entra ID, d'Auth0 ou de Cognito. Dans les résultats de recherche consultés le 27 septembre 2026, les présentations décrivent ses fonctions et les comparatifs viennent surtout d'éditeurs concurrents ; le coût de son exploitation et les cas où s'en passer y sont peu traités.

Les chapitres qui suivent le traduisent en termes de décision : fonctions, exploitation, comparaison vérifiable avec cinq alternatives, critères pour ou contre Keycloak. Cette lecture est établie sur Keycloak 26.7.4, dernière version publiée ; les pages officielles de Keycloak et des solutions comparées ont été vérifiées le . Seules les structures de prix sont décrites, jamais des montants.

Ce que fait Keycloak, en langage de décideur

Keycloak est un fournisseur d'identité, ou IdP (identity provider) : les applications lui délèguent la question « qui est cet utilisateur, et comment l'a-t-on vérifié ? ». Au lieu que chacune gère ses mots de passe, toutes redirigent l'utilisateur vers Keycloak, qui l'authentifie et leur renvoie une preuve signée de son identité et de ses rôles. Le projet est distribué sous licence Apache 2.0 et a été accepté à la Cloud Native Computing Foundation (CNCF) le 10 avril 2023, au niveau « incubating ».

L'unité d'organisation est le royaume (realm) : un espace isolé qui porte ses utilisateurs, ses applications déclarées (les clients) et ses parcours de connexion. Un serveur peut en héberger plusieurs, par exemple un pour les collaborateurs et un pour les utilisateurs d'un produit.

Besoin exprimé par l'organisation, ce que fait Keycloak et le terme technique correspondant
Besoin expriméCe que fait KeycloakTerme technique
« Se connecter une fois pour toutes nos applications »Une session ouverte sur Keycloak sert à toutes les applications du royaumeSSO
« Brancher une application web, mobile ou une API »Émission de jetons signés portant identité et droitsOpenID Connect, OAuth 2.0
« Brancher un logiciel d'entreprise qui ne parle que SAML »Keycloak joue le rôle de fournisseur d'identité SAMLSAML 2.0
« Laisser les salariés d'un client utiliser leur compte d'entreprise »Courtage vers des fournisseurs d'identité OIDC ou SAML 2.0, connexion par réseaux sociauxIdentity brokering
« Réutiliser notre annuaire interne »Fédération d'annuaires LDAP et Active Directory, KerberosUser federation
« Imposer une double authentification »Codes à usage unique (TOTP, HOTP), WebAuthn, passkeys, codes de récupération, authentification renforcée pour une action sensibleMFA, step-up

OIDC, SAML et SSO sans jargon

OpenID Connect (OIDC) est une couche d'identité posée sur OAuth 2.0 : l'application reçoit des jetons JSON signés, simples à vérifier, adaptés aux applications web, mobiles et aux API. SAML 2.0 (Security Assertion Markup Language), plus ancien, échange des assertions XML ; certains logiciels d'entreprise ne proposent que lui. Keycloak parle les deux : une application peut se connecter en OIDC pendant que l'identité vient d'un fournisseur SAML, et inversement.

Le SSO repose sur la session ouverte sur Keycloak, pas dans chaque application : la seconde application redirige aussi vers Keycloak, qui reconnaît la session et renvoie des jetons sans nouvelle saisie.

Connexion unique et fédération avec l'IdP d'une entreprise cliente

Deux applications délèguent l'authentification à Keycloak, qui s'appuie lui-même sur le fournisseur d'identité de l'entreprise cliente.

Schéma défilable horizontalement ; sa version textuelle complète suit.

Lire le schéma sous forme textuelle
  1. L'utilisateur ouvre l'application A, qui le redirige vers Keycloak par une requête OpenID Connect.
  2. Keycloak délègue l'authentification au fournisseur d'identité de l'entreprise cliente, en OIDC ou en SAML.
  3. Ce fournisseur confirme l'identité, double authentification comprise.
  4. Keycloak renvoie à l'application A des jetons signés portant l'identité et les rôles.
  5. L'utilisateur ouvre ensuite l'application B, qui le redirige à son tour vers Keycloak.
  6. Keycloak reconnaît la session ouverte et émet des jetons pour B sans nouvelle saisie.
Modèle explicatif, sans donnée client, d'après la documentation de Keycloak 26.7.4.

En 26.7.4, passkeys, codes de récupération, authentification renforcée et organisations (les utilisateurs d'une entreprise cliente regroupés dans un royaume) sont activés par défaut. L'API SCIM (System for Cross-domain Identity Management, provisionnement des comptes), promue en préversion avec la 26.7.0 du 9 juillet 2026 et désactivée par défaut, n'est pas prête pour la production selon la politique du projet. Enfin, LDAP et Kerberos servent à Keycloak à lire des annuaires existants ; vers les applications, Keycloak documente OpenID Connect et SAML.

Ce que coûte vraiment son exploitation

Keycloak ne coûte aucune licence. Son coût réel se compte en infrastructure et en temps d'équipe, et la politique de versions du projet en fixe l'essentiel.

Une version mineure par trimestre, une seule supportée

La politique de publication du dépôt est explicite : environ quatre mineures par an, une majeure tous les deux à trois ans, des correctives au besoin. Seule la dernière mineure reçoit des correctifs ; à la sortie d'une nouvelle, la précédente n'est plus supportée, et les utilisateurs sont censés passer chaque mineure pour rester couverts. Les garanties de compatibilité ne valent que pour les fonctionnalités supportées et les API publiques, et un correctif important ou de sécurité peut introduire une rupture dans n'importe quelle version.

À la date de vérification, la branche supportée est la 26.7, ouverte le 9 juillet 2026 ; sa version 26.7.4 du 16 septembre 2026 corrige six vulnérabilités. Rester sous correctifs impose donc une montée mineure par trimestre, plus les correctives. Un support étendu est en discussion (ticket GitHub n° 52656, ouvert le 11 septembre 2026), mais c'est une proposition ouverte aux commentaires, dont les auteurs préviennent qu'ils n'ont pas la capacité de livrer plusieurs options : elle ne fonde pas un plan.

La distribution commerciale change l'équation. Le Red Hat build of Keycloak publie une mineure environ tous les six mois, fondée sur les mineures paires de la communauté (26.0, 26.2, 26.4), maintenue jusqu'à la disponibilité de la deuxième mineure suivante ; une majeure est couverte au moins deux ans pour la 26.x, trois ans à partir de la 27.x. Moins de montées de version et un support éditeur, contre une souscription.

Montées de version : arrêt, migration, pas d'annulation

Selon le guide de montée de version de la 26.7.4, une version corrective de la même branche peut s'appliquer sans interruption, en mise à jour progressive sur au moins deux nœuds, depuis la 26.6.0. Une montée mineure ou majeure impose d'arrêter Keycloak et de sauvegarder installation et base. Au premier démarrage, la nouvelle version migre le schéma, que l'ancien serveur ne sait plus lire, et Keycloak n'annule pas ces changements : revenir en arrière signifie restaurer l'installation puis la base. La migration dispose par défaut de 30 minutes, et les parcours de connexion en cours lors de l'arrêt sont à recommencer. La sous-commande update-compatibility check indique par son code de sortie si une mise à jour progressive est possible (0) ; les codes 3 et 4 imposent un arrêt, 1 et 2 signalent une erreur.

Haute disponibilité et sauvegardes : la base au centre

Les architectures de haute disponibilité documentées reposent toutes sur une base de données correctement configurée. La base dev-file, utilisée par défaut, est réservée au développement ; la 26.7.4 supporte PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, Azure SQL, Amazon Aurora PostgreSQL et EnterpriseDB Advanced.

Architecture documentée, pannes tolérées et contraintes imposées
Architecture documentéeCe qu'elle tolèreCe qu'elle impose
Un cluster, éventuellement sur plusieurs zonesPerte d'une zone si le cluster est répartiAucune dépendance externe ; le cluster Kubernetes reste un point unique de défaillance
Multi-cluster v1Perte d'une zone ou d'un clusterRépartiteur externe, cluster Infinispan séparé par site, deux plans de contrôle ; non supporté sur trois zones ou plus
Multi-cluster v2 (préversion)Perte d'une zone ou d'un clusterRépartiteur externe ; sessions en base, environ deux fois plus de CPU et d'écritures sur la base selon la documentation

Côté sauvegarde, la documentation encadre l'export de royaume : sa cohérence n'est garantie que tous nœuds arrêtés, et un export depuis la console masque les secrets et ne sert pas de sauvegarde. La référence est la sauvegarde de la base, complétée par une configuration décrite dans Git, et elle ne vaut que si sa restauration a été répétée.

Extensions : chaque mineure peut casser

Au-delà de la configuration, Keycloak s'étend en Java par ses interfaces de fournisseurs de service (SPI, service provider interfaces) : authentificateur, mappeur de protocole, écouteur d'événements, action requise. En 26.7.4, ces SPI sont déclarés internes, et le serveur signale toute extension qui les implémente par l'avertissement « This SPI is internal and may change without notice ». Chaque extension maison se reteste à chaque mineure, et se corrige si l'interface a changé ; les thèmes de connexion personnalisés font aussi l'objet d'une étape de migration dans le guide de montée de version.

Configuration, supervision et réponse aux incidents

Un royaume configuré à la main ne se relit pas en revue de code. L'opérateur officiel pour Kubernetes et OpenShift, le fournisseur Terraform et keycloak-config-cli permettent de le piloter depuis Git ; « Piloter la configuration Keycloak en GitOps : adoption, dérive et suppression de champs » les compare. L'opérateur open source que nous publions sous licence Apache 2.0, ctn-solutions/keycloak-operator, gère royaumes, clients, portées, rôles, fournisseurs d'identité et groupes. Sa matrice d'intégration couvre Keycloak 26.0 à 26.3 : elle ne vaut pas validation sur la branche 26.7, et rappelle que tout outil autour de Keycloak doit suivre la même cadence pour rester validé.

Un fournisseur d'identité est sur le chemin critique : s'il tombe, les nouvelles connexions échouent partout. Keycloak expose des sondes de santé sur un port de gestion (9000 par défaut) avec l'option health-enabled ; restent les alertes, les procédures et une organisation de réponse aux incidents.

Poste d'exploitation, ce qu'impose Keycloak 26.7 et ce qu'il faut prévoir
PosteCe qu'impose Keycloak 26.7À prévoir
VersionsEnviron quatre mineures par an, seule la dernière est corrigéeUne montée mineure par trimestre, ou une distribution à support plus long
Montée mineureArrêt de tous les nœuds, migration du schéma sans annulationFenêtre de maintenance annoncée, restauration testée
Haute disponibilitéBase obligatoire, topologies documentéesBase supportée, zones multiples, répartiteur externe en multi-cluster
Extensions et thèmesSPI internes susceptibles de changer sans préavisTests de chaque extension à chaque mineure
ExploitationService sur le chemin critiqueSondes, alertes, procédures, réponse aux incidents

Alternatives à Keycloak : IdP managés et autres solutions open source

Six solutions, cinq critères, d'après les pages officielles consultées le , sans classement ni montant.

Hébergement, protocoles exposés aux applications, extensibilité, modèle de prix et localisation des données de six solutions d'identité, d'après leurs pages officielles
SolutionHébergementProtocoles exposés aux applicationsExtensibilitéModèle de prixLocalisation des données
KeycloakAuto-hébergé, licence Apache 2.0 ; distribution Red Hat ; offres managées de tiersOIDC, OAuth 2.0, SAML 2.0SPI Java, thèmesAucune licence ; souscription pour la distribution Red HatLà où l'organisation l'héberge
Microsoft Entra External IDService Microsoft (tenant externe)OIDC, OAuth 2.0, applications SAMLExtensions d'authentification personnalisées appelant une API REST (émission du jeton, collecte d'attributs, envoi de code)Par utilisateur actif mensuel (MAU), palier gratuit ; modules facturés en plus (SMS, machine à machine, Go-Local)Pays ou région choisi à la création, non modifiable ; option Go-Local pour certains pays, comme l'Australie ou le Japon
Auth0 (groupe Okta)Service managé : cloud public mutualisé ou cloud privé dédié (AWS, Azure)OIDC, OAuth 2.0, SAML, WS-FederationActions en Node.jsFormules par MAU, formule gratuite, variantes B2C et B2B, Enterprise sur devisCloud public : États-Unis, Europe, Royaume-Uni, Australie, Japon, Canada ; autres régions en cloud privé
Amazon CognitoService managé AWSOIDC, OAuth 2.0 ; SAML et OIDC en fédération entranteDéclencheurs LambdaPar MAU, plans Lite, Essentials, Plus ; machine à machine par demande de jetonRégion AWS du groupe d'utilisateurs ; réplique dans une seconde région en option
authentikAuto-hébergé ; cœur sous licence MIT, fonctions Enterprise sous licence propreOIDC, OAuth 2.0, SAML, LDAP, RADIUS, proxy ; WS-Federation en EnterpriseFlows et étapes, politiques d'expression en PythonOpen source sans licence ; Enterprise par utilisateur interne et par utilisateur externe, par moisLà où l'organisation l'héberge
ZITADELZITADEL Cloud ou auto-hébergement, même code ; AGPL-3.0 ou licence commercialeOIDC, OAuth 2.0, SAML 2.0Actions v2 (appels à des points de terminaison externes sur requêtes, réponses, événements)Cloud par utilisateurs actifs quotidiens (DAU), formule gratuite ; Enterprise sur devisCloud : UE, États-Unis, Suisse, Australie ; sinon là où l'organisation l'héberge

Ce que le tableau implique

  • Entra External ID vise les utilisateurs externes, à côté du tenant des collaborateurs ; Azure AD B2C n'est plus proposé à l'achat aux nouveaux clients depuis le 1er mai 2025. Les MAU des tenants liés à un même abonnement s'additionnent, et la région se décide avant le premier utilisateur.
  • Auth0 est l'offre d'identité client d'Okta ; pour les collaborateurs, Okta Workforce Identity est vendu par utilisateur et par mois, facturé annuellement, avec un minimum contractuel annuel.
  • Cognito émet des jetons OIDC pour les applications ; face à un IdP SAML, la documentation le présente comme fournisseur de service, qui convertit les assertions reçues en jetons, et non comme fournisseur d'identité SAML pour les applications. Sa réplication multirégion, annoncée en juin 2026 pour les plans Essentials et Plus, ne crée pas d'utilisateurs et ne prend pas en charge le TOTP dans la région secondaire.
  • authentik documente des fournisseurs LDAP et RADIUS qui exposent ces protocoles aux applications, utiles face à des logiciels anciens.
  • ZITADEL exécute le même code en cloud et en auto-hébergement, sous licence AGPL-3.0 ou licence commerciale.
  • Keycloak : le site du projet ne propose pas d'offre hébergée ; restent la distribution Red Hat ou un hébergeur tiers. Des hébergeurs tiers proposent des offres Keycloak managées, dont le périmètre (mises à jour, sauvegardes, base) se vérifie auprès de chacun.

La colonne « Localisation des données » décrit où les données sont stockées, pas le droit applicable au fournisseur ni ses sous-traitants, que cette lecture ne couvre pas. Disponibilité garantie, certifications, support et prix au volume visé se demandent par écrit à chaque éditeur.

Quand ne pas choisir Keycloak, et quand il se justifie

Deux critères pèsent contre Keycloak : une organisation qui ne peut pas l'exploiter, ou un service déjà en place qui couvre le besoin.

Critères défavorables à Keycloak

  • Personne pour l'exploiter : sans équipe pour un service critique avec base, supervision et réponse aux incidents, la gratuité de la licence est trompeuse.
  • Une montée mineure par trimestre est impossible (gel des changements, validation lourde, homologation) : la version installée sort vite du support ; la distribution Red Hat publie une mineure environ tous les six mois, avec un support plus long, contre une souscription.
  • Seulement le SSO des collaborateurs sur un Entra ID existant : Keycloak serait un second IdP à exploiter à côté d'Entra ID ; le critère est la capacité qu'il ajouterait au besoin exprimé.
  • Une application aux parcours standards, en OIDC, chez un fournisseur cloud qui propose un service d'identité managé : le critère est de savoir si les points d'extension de ce service couvrent les parcours ; la colonne « Extensibilité » du tableau les liste par solution.
  • Des applications anciennes limitées à LDAP ou RADIUS : Keycloak n'expose pas ces protocoles aux applications ; la colonne « Protocoles exposés aux applications » du tableau indique les solutions qui les documentent.
  • Un provisionnement SCIM de production indispensable tout de suite : l'API SCIM est en préversion dans Keycloak 26.7 ; l'état de SCIM se vérifie alors chez chaque solution candidate.
  • Des extensions lourdes sans budget de maintenance : une extensibilité par code hébergé ou par appels externes déplace la maintenance vers des points d'extension publics (Actions d'Auth0, Actions v2 de ZITADEL, déclencheurs Lambda), qui suivent eux aussi le cycle de vie de chaque service.

Critères favorables à Keycloak

  • Un éditeur SaaS B2B dont chaque client impose son IdP, en SAML ou en OIDC : courtage d'identité et organisations y répondent ; auto-hébergé, Keycloak n'est pas facturé par utilisateur actif.
  • Une exigence d'auto-hébergement ou de maîtrise complète de la localisation, base comprise.
  • Des parcours d'authentification sur mesure, au-delà de ce que permettent les points d'extension d'un service managé.
  • Un coût indépendant du nombre d'utilisateurs actifs, à mettre en regard du coût de l'équipe d'exploitation.
  • Une plateforme Kubernetes déjà exploitée avec GitOps et une organisation de réponse aux incidents, où Keycloak devient un service de plus.

Ces cinq critères valent aussi pour les solutions auto-hébergeables du tableau (authentik, ZITADEL).

Arbre de décision pour choisir un fournisseur d'identité

Quatre questions successives confrontent le besoin et la capacité d'exploitation aux critères du tableau comparatif.

Schéma défilable horizontalement ; sa version textuelle complète suit.

Lire le schéma sous forme textuelle
  1. Si le besoin se limite au SSO des collaborateurs sur un Entra ID existant, Keycloak serait un second IdP à exploiter à côté d'Entra ID ; le critère est la capacité qu'il ajouterait au besoin exprimé.
  2. Sinon, si aucune équipe ne peut exploiter un service critique et suivre une version mineure par trimestre, les options sont un service managé ou un Keycloak hébergé par un tiers ; si seule la cadence bloque, la distribution Red Hat, à support plus long.
  3. Si une équipe le peut et qu'il faut à la fois SAML et OIDC, une fédération par client ou des parcours sur mesure, Keycloak couvre ces critères ; les autres solutions du tableau se vérifient sur les mêmes.
  4. Sinon, si des applications anciennes exigent LDAP ou RADIUS : Keycloak n'expose pas ces protocoles aux applications ; la colonne « Protocoles exposés aux applications » du tableau indique les solutions qui les documentent.
  5. Dans les autres cas, comparer les solutions sur les critères du tableau comparatif.
Modèle explicatif, sans donnée client, d'après la documentation de Keycloak 26.7.4 et les pages officielles des solutions comparées.

Réussir la mise en production si Keycloak est retenu

Retenir Keycloak engage l'organisation sur son cycle de vie ; ces points se décident avant la mise en service :

  1. Politique de versions écrite : chaque mineure dans le trimestre, ou une distribution à support plus long ; suivi des notes de version et des avis de sécurité.
  2. Image versionnée contenant extensions et thèmes, avec update-compatibility dans la chaîne de livraison pour choisir entre mise à jour progressive et arrêt complet.
  3. Base de production supportée, sauvegardée, avec une restauration répétée avant chaque montée mineure.
  4. Topologie de haute disponibilité documentée et essais de panne écrits.
  5. Royaumes décrits dans Git, avec une politique explicite d'adoption des objets existants et de suppression.
  6. Inventaire des extensions et des SPI internes utilisés, testés à chaque mineure en préproduction.
  7. Sondes, alertes et procédures de restauration et de bascule, et une organisation de réponse aux incidents.
  8. Chaque fédération documentée : contact côté client, protocole, certificats de signature et date d'expiration, attributs attendus.

Une mise en production se prépare point par point : chacun reçoit un responsable, un critère vérifiable et une date avant l'ouverture du service. Pour cadrer ces points avec l'équipe qui exploitera la plateforme, la page Mise en production Kubernetes : ouvrir par étapes décrit notre périmètre d'intervention.

Sources officielles et limites de lecture

Faits datés

Les faits sur Keycloak ont été vérifiés le contre la documentation de la 26.7.4, la politique de publication du dépôt et le code du tag 26.7.4; les pages officielles des solutions comparées l'ont été à la même date. Ces faits datés sont à revérifier avant toute décision ; sur une autre version de Keycloak, ses propres guides font foi.

Vérifié le

Le tableau reprend ce qu'affirment les pages officielles des éditeurs, pas des essais de chaque produit ; prix, régions et options peuvent évoluer, et un devis écrit remplace toute lecture de page tarifaire. Le ticket n° 52656 reste une proposition. Les informations sur Okta, Auth0, authentik et ZITADEL viennent en partie de pages commerciales, pas de documents contractuels. Les critères de cet article sont sourcés et datés ; ils ne valent pas recommandation d'un éditeur, et la mention d'une solution n'implique ni partenariat ni référence de mise en œuvre par CTN Solutions.

Sources

  1. Keycloak 26.7.4 released, Keycloak, https://www.keycloak.org/2026/09/keycloak-2674-released, consulté le 29/09/2026.
  2. Keycloak 26.7.0 released, Keycloak, https://www.keycloak.org/2026/07/keycloak-2670-released, consulté le 29/09/2026.
  3. Keycloak, page d'accueil, https://www.keycloak.org/, consulté le 29/09/2026.
  4. Keycloak, fiche projet, Cloud Native Computing Foundation, https://www.cncf.io/projects/keycloak/, consulté le 29/09/2026.
  5. Keycloak Releases (RELEASES.md), dépôt keycloak/keycloak, https://github.com/keycloak/keycloak/blob/main/RELEASES.md, consulté le 29/09/2026.
  6. Extended release support, ticket n° 52656, dépôt keycloak/keycloak, https://github.com/keycloak/keycloak/issues/52656, consulté le 29/09/2026.
  7. Red Hat build of Keycloak Life Cycle and Support Policies, Red Hat, https://access.redhat.com/support/policy/updates/red_hat_build_of_keycloak_notes, consulté le 29/09/2026.
  8. Upgrading Guide, Keycloak, https://www.keycloak.org/docs/latest/upgrading/index.html, consulté le 29/09/2026.
  9. Preparing for an upgrade (prep_migration.adoc), tag 26.7.4, dépôt keycloak/keycloak, https://github.com/keycloak/keycloak/blob/26.7.4/docs/documentation/upgrading/topics/prep_migration.adoc, consulté le 29/09/2026.
  10. Migrating the database (migrate_db.adoc), tag 26.7.4, dépôt keycloak/keycloak, https://github.com/keycloak/keycloak/blob/26.7.4/docs/documentation/upgrading/topics/migrate_db.adoc, consulté le 29/09/2026.
  11. Checking if rolling updates are possible, Keycloak, https://www.keycloak.org/server/update-compatibility, consulté le 29/09/2026.
  12. High availability overview, Keycloak, https://www.keycloak.org/high-availability/introduction, consulté le 29/09/2026.
  13. Configuring the database, Keycloak, https://www.keycloak.org/server/db, consulté le 29/09/2026.
  14. Importing and exporting realms, Keycloak, https://www.keycloak.org/server/importExport, consulté le 29/09/2026.
  15. Server Developer Guide, Keycloak, https://www.keycloak.org/docs/latest/server_development/index.html, consulté le 29/09/2026.
  16. ServicesLogger.java, tag 26.7.4, dépôt keycloak/keycloak, https://github.com/keycloak/keycloak/blob/26.7.4/services/src/main/java/org/keycloak/services/ServicesLogger.java, consulté le 29/09/2026.
  17. Liste des SPI internes (server-spi-private), tag 26.7.4, dépôt keycloak/keycloak, https://github.com/keycloak/keycloak/blob/26.7.4/server-spi-private/src/main/resources/META-INF/services/org.keycloak.provider.Spi, consulté le 29/09/2026.
  18. Server Administration Guide, Keycloak, https://www.keycloak.org/docs/latest/server_admin/index.html, consulté le 29/09/2026.
  19. Profile.java (statut des fonctionnalités), tag 26.7.4, dépôt keycloak/keycloak, https://github.com/keycloak/keycloak/blob/26.7.4/common/src/main/java/org/keycloak/common/Profile.java, consulté le 29/09/2026.
  20. Enabling Keycloak Health checks, Keycloak, https://www.keycloak.org/observability/health, consulté le 29/09/2026.
  21. Keycloak Operator Installation, Keycloak, https://www.keycloak.org/operator/installation, consulté le 29/09/2026.
  22. Licence Apache 2.0, tag 26.7.4, dépôt keycloak/keycloak, https://github.com/keycloak/keycloak/blob/26.7.4/LICENSE.txt, consulté le 29/09/2026.
  23. ctn-solutions/keycloak-operator, README, CTN Solutions, https://github.com/ctn-solutions/keycloak-operator, consulté le 29/09/2026.
  24. External ID pricing, Microsoft Learn, https://learn.microsoft.com/en-us/entra/external-id/external-identities-pricing, consulté le 29/09/2026.
  25. Supported features in workforce and external tenants, Microsoft Learn, https://learn.microsoft.com/en-us/entra/external-id/customers/concept-supported-features-customers, consulté le 29/09/2026.
  26. Custom authentication extensions, Microsoft Learn, https://learn.microsoft.com/en-us/entra/external-id/customers/concept-custom-extensions, consulté le 29/09/2026.
  27. Create an external tenant, Microsoft Learn, https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-create-external-tenant-portal, consulté le 29/09/2026.
  28. Microsoft Entra ID and data residency, Microsoft Learn, https://learn.microsoft.com/en-us/entra/fundamentals/data-residency, consulté le 29/09/2026.
  29. Azure AD B2C: Frequently asked questions, Microsoft Learn, https://learn.microsoft.com/en-us/azure/active-directory-b2c/faq, consulté le 29/09/2026.
  30. Protocols, Auth0 Docs, https://auth0.com/docs/authenticate/protocols, consulté le 29/09/2026.
  31. Migrate from Node 18 to Node 22, Auth0 Docs, https://auth0.com/docs/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-nodejs-22, consulté le 29/09/2026.
  32. Pricing, Auth0, https://auth0.com/pricing, consulté le 29/09/2026.
  33. Cloud Deployment, Auth0, https://auth0.com/platform/cloud-deployment, consulté le 29/09/2026.
  34. Public Cloud Service Endpoints, Auth0 Docs, https://auth0.com/docs/troubleshoot/customer-support/operational-policies/public-cloud-service-endpoints, consulté le 29/09/2026.
  35. Plans and Pricing, Okta, https://www.okta.com/pricing/, consulté le 29/09/2026.
  36. Amazon Cognito user pools, AWS Documentation, https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools.html, consulté le 29/09/2026.
  37. Using SAML identity providers with a user pool, AWS Documentation, https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-saml-idp.html, consulté le 29/09/2026.
  38. Customizing user pool workflows with Lambda triggers, AWS Documentation, https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html, consulté le 29/09/2026.
  39. Amazon Cognito pricing, AWS, https://aws.amazon.com/cognito/pricing/, consulté le 29/09/2026.
  40. Multi-Region replication for user pools, AWS Documentation, https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-multi-region.html, consulté le 29/09/2026.
  41. Amazon Cognito now supports multi-Region replication, AWS, https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-cognito-multi-region/, consulté le 29/09/2026.
  42. Providers, authentik Docs, https://docs.goauthentik.io/add-secure-apps/providers/, consulté le 29/09/2026.
  43. Expression policies, authentik Docs, https://docs.goauthentik.io/customize/policies/types/expression/, consulté le 29/09/2026.
  44. Pricing, authentik, https://goauthentik.io/pricing/, consulté le 29/09/2026.
  45. LICENSE, dépôt goauthentik/authentik, https://github.com/goauthentik/authentik/blob/main/LICENSE, consulté le 29/09/2026.
  46. README, dépôt zitadel/zitadel, https://github.com/zitadel/zitadel, consulté le 29/09/2026.
  47. LICENSING.md, dépôt zitadel/zitadel, https://github.com/zitadel/zitadel/blob/main/LICENSING.md, consulté le 29/09/2026.
  48. Pricing, ZITADEL, https://zitadel.com/pricing, consulté le 29/09/2026.
  49. ZITADEL Cloud, ZITADEL, https://zitadel.com/zitadel-cloud, consulté le 29/09/2026.
  50. Authenticate users with SAML, ZITADEL Docs, https://zitadel.com/docs/guides/integrate/login/saml, consulté le 29/09/2026.
  51. ZITADEL Actions v2, ZITADEL Docs, https://zitadel.com/docs/concepts/features/actions_v2, consulté le 29/09/2026.

Parlons de votre contexte.

Cet article expose une pratique générale ; votre situation a ses propres contraintes. Décrivez-la, nous répondons avec un périmètre.

Ouvrir le formulaire