OIDC ou SAML : choisir le protocole et fédérer Keycloak avec Entra ID

Une application doit accepter les comptes professionnels d'un client, un logiciel acheté ne parle que SAML, une application monopage rejoint le portefeuille : le choix entre OpenID Connect (OIDC) et SAML 2.0 revient à chaque intégration, et il peut se doubler d'une fédération avec Microsoft Entra ID. Comparer les formats de jetons ne suffit pas : les incidents peuvent naître dans la déconnexion, la rotation des clés, la liaison des comptes et les groupes qui disparaissent du jeton.

Cet article tranche le choix du protocole, puis détaille la fédération de Keycloak avec Entra ID en OIDC et en SAML, jusqu'à la liste de contrôle. Cette lecture est établie sur Keycloak 26.7.4, dernière version publiée (16 septembre 2026), dont la documentation et le code ont été relus au tag correspondant ; les pages Microsoft Learn et les spécifications OpenID, OASIS et IETF citées ont été vérifiées le 29 septembre 2026.

Ce que transportent OIDC et SAML 2.0

Les deux protocoles disent qui est l'utilisateur et comment il s'est authentifié, mais pas avec les mêmes objets ni les mêmes hypothèses sur le client.

Un jeton JSON contre une assertion XML

OpenID Connect Core 1.0 est une couche d'identité posée sur OAuth 2.0. L'application reçoit un jeton d'identité JWT dont cinq revendications sont obligatoires : iss, sub, aud, exp et iat. Il est signé en JWS et peut être chiffré en JWE. Selon la spécification, le couple iss et sub est l'identifiant stable de l'utilisateur ; ni l'adresse e-mail ni le nom d'utilisateur préféré ne doivent en servir.

SAML 2.0, standard OASIS du 15 mars 2005, transporte une assertion XML, signée par XML Signature et chiffrable en EncryptedAssertion selon XML Encryption. L'utilisateur est désigné par le NameID du sujet, dont le format se négocie dans la requête, ou par un attribut choisi par le fournisseur de service.

Le trajet de la réponse décide des clients possibles

Dans OIDC, le navigateur ne rapporte qu'un code d'autorisation, que l'application échange ensuite contre les jetons. Le RFC 9700 (BCP 240, janvier 2025) fixe l'usage : le flux implicite ne devrait plus être utilisé ; PKCE est obligatoire pour un client public et recommandé pour un client confidentiel ; les URI de redirection se comparent par égalité exacte. Le RFC 7636 impose S256 à tout client capable de le calculer. Pour une application mobile, le RFC 8252 (BCP 212) demande de passer par un agent externe, en pratique le navigateur du système, plutôt que par une vue web intégrée.

Dans le profil Web Browser SSO de SAML, la requête peut voyager par redirection, POST ou artefact, mais la réponse ne passe que par POST ou artefact, parce qu'elle dépasse en général la longueur d'URL admise par les navigateurs. Elle arrive donc en formulaire posté sur le point de consommation (ACS) du fournisseur de service. Une application monopage sans serveur ne peut pas jouer ce rôle : il lui faut un serveur ou une passerelle.

Clés et métadonnées

OIDC publie un document de découverte (/.well-known/openid-configuration) qui pointe vers un jeu de clés jwks_uri ; chaque jeton désigne sa clé par kid. Avec « Use JWKS URL », Keycloak télécharge les nouvelles clés quand le fournisseur en génère : la rotation n'exige aucune action.

SAML décrit les clés dans des métadonnées : un KeyDescriptor porte un certificat X.509 et son usage, signing ou encryption, et les attributs validUntil et cacheDuration bornent validité et mise en cache. Keycloak recharge ces certificats depuis une URL de métadonnées (« Use metadata descriptor URL ») ; sans cette option, chaque renouvellement se réimporte à la main.

Déconnexion : trois mécanismes d'un côté, deux canaux de l'autre

OIDC répartit la déconnexion entre trois spécifications finales. RP-Initiated Logout renvoie le navigateur vers end_session_endpoint. Front-Channel Logout fait charger dans des iframes l'URL de déconnexion de chaque application ; la spécification signale que les navigateurs qui bloquent le contenu tiers peuvent empêcher l'application de retrouver sa session. Back-Channel Logout envoie de serveur à serveur un jeton de déconnexion signé, qui peut porter l'identifiant de session sid. Le Single Logout de SAML existe sur le canal du navigateur et sur un canal serveur en SOAP.

Choisir le protocole, application par application

Le choix se fait deux fois, indépendamment. Un client Keycloak parle OIDC ou SAML à l'application ; un fournisseur d'identité déclaré dans Keycloak parle OIDC ou SAML à l'annuaire amont. Keycloak traduit : une application OIDC peut recevoir des utilisateurs authentifiés en SAML, et l'inverse.

Côté application

La documentation de Keycloak 26.7 recommande OIDC « pour la plupart des usages » et rappelle ce qui fait encore choisir SAML : une perception de maturité et, surtout, les applications déjà protégées par lui. Une application neuve, une API, une application monopage ou mobile se branchent en OIDC. Un progiciel qui n'accepte que SAML, ou une application Java déjà équipée d'un adaptateur SAML, se branche en SAML ; Keycloak maintient un adaptateur SAML en module Galleon pour WildFly et JBoss EAP.

Côté fédération

Face à Entra ID, les deux protocoles sont disponibles : OIDC par un enregistrement d'application, SAML par une application d'entreprise hors galerie. OIDC coûte moins à exploiter : ses clés tournent par le JWKS sans intervention, alors qu'un certificat de signature SAML d'Entra ID expire par défaut au bout de trois ans et se remplace de façon coordonnée. SAML reste le bon choix quand l'administrateur du locataire n'accepte que des applications SAML, ou quand l'annuaire amont ne sait émettre que des assertions.

Dans le secteur public, l'espace partenaires de ProConnect documente l'intégration de ses fournisseurs d'identité en OpenID Connect, avec des pages dédiées à Keycloak et à Entra ID.

Fédérer Keycloak avec Entra ID, en OIDC ou en SAML

Dans ce montage, Keycloak est client d'Entra ID et fournisseur d'identité pour les applications. Les applications ne dialoguent jamais avec Entra ID : elles reçoivent des jetons émis par Keycloak.

Le parcours de connexion

« Microsoft » ou « OpenID Connect v1.0 » dans Keycloak

Keycloak propose un fournisseur social « Microsoft ». Son code, au tag 26.7.4, en montre les limites en entreprise : il lit le profil sur Microsoft Graph (/v1.0/me, portée User.read) au lieu de valider un jeton d'identité, prend comme e-mail l'attribut mail ou, à défaut, l'UPN s'il a la forme d'une adresse e-mail, et vise le point common si aucun locataire n'est renseigné, sans contrôler le locataire à la connexion : les comptes admis ne sont alors bornés que par les types de comptes acceptés par l'enregistrement d'application. Le fournisseur générique « OpenID Connect v1.0 », pointé sur les URL du locataire, vérifie la signature du jeton, son audience et son émetteur : c'est lui qu'il faut retenir.

Côté Entra ID : enregistrement, URI et identifiants

L'enregistrement d'application se crée avec la plateforme « Web » et l'URI de redirection affichée par Keycloak, https://<hôte>/realms/<royaume>/broker/<alias>/endpoint. Si Keycloak doit aussi déconnecter l'utilisateur d'Entra ID, une seconde URI s'impose, .../endpoint/logout_response, que Keycloak transmet comme post_logout_redirect_uri : Entra ID n'accepte qu'une URI de retour enregistrée. Les URI sont en https et ne dépassent pas 256 caractères.

Pour l'authentification du client, Microsoft présente le certificat comme le type d'identifiant recommandé et déconseille les secrets en production. Keycloak sait signer une assertion (« JWT signed with private key ») avec la clé privée du royaume : le certificat de cette clé se téléverse dans l'enregistrement, et toute rotation des clés du royaume impose de téléverser le nouveau certificat avant d'activer la nouvelle clé. La page Microsoft décrit toutefois un en-tête x5t#S256 et l'algorithme PS256, alors que Keycloak 26.7.4 désigne sa clé par kid ou, option « Add X.509 Headers to the JWT » activée, par x5t (empreinte SHA-1), et signe par défaut en RS256. Aucune des deux documentations n'établit que cette assertion est acceptée : elle se valide sur un locataire de test avant d'être retenue. Les informations d'identification fédérées ne s'appliquent pas : Entra ID y attend un jeton émis par un fournisseur OIDC externe, audience recommandée api://AzureADTokenExchange, alors que Keycloak signe lui-même une assertion dont l'émetteur est l'identifiant du client. Si le secret reste la solution retenue, c'est un écart à la recommandation de Microsoft, à documenter : il se range dans le coffre de Keycloak (${vault.<clé>}) et son échéance entre dans la supervision.

Les revendications, et l'identifiant sur lequel repose la liaison

La première ligne a une conséquence pratique. Le courtier OIDC de Keycloak lie le compte local au sub du jeton d'identité, qu'Entra ID calcule par application. Recréer l'enregistrement d'application produit des sub nouveaux : chaque utilisateur repasse par la première connexion, où son compte n'est plus reconnu que par l'e-mail ou le nom d'utilisateur. L'enregistrement se conserve, il ne se régénère pas.

Configuration de référence

Exemple fictif : royaume plateforme, alias entra, locataire unique, secret conservé en coffre ; les identifiants sont illustratifs. La représentation suit IdentityProviderRepresentation au tag 26.7.4 ; les booléens du dictionnaire config sont des chaînes.

{
  "alias": "entra",
  "displayName": "Compte Microsoft professionnel",
  "providerId": "oidc",
  "enabled": true,
  "trustEmail": false,
  "firstBrokerLoginFlowAlias": "first broker login",
  "config": {
    "issuer": "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/v2.0",
    "authorizationUrl": "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/oauth2/v2.0/authorize",
    "tokenUrl": "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/oauth2/v2.0/token",
    "logoutUrl": "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/oauth2/v2.0/logout",
    "jwksUrl": "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/discovery/v2.0/keys",
    "useJwksUrl": "true",
    "validateSignature": "true",
    "clientId": "11111111-1111-1111-1111-111111111111",
    "clientAuthMethod": "client_secret_post",
    "clientSecret": "${vault.entra-client-secret}",
    "defaultScope": "openid profile email",
    "pkceEnabled": "true",
    "pkceMethod": "S256",
    "syncMode": "IMPORT"
  }
}

# Création puis relecture des réglages sensibles (Keycloak 26.7.4)
kcadm.sh create identity-provider/instances -r plateforme -f entra-idp.json
kcadm.sh get identity-provider/instances/entra -r plateforme \
  --fields alias,enabled,trustEmail,firstBrokerLoginFlowAlias,linkOnly,config

Le mode IMPORT du fournisseur n'écrit les données qu'à la création ; les mappers qui doivent suivre Entra ID reçoivent un mode FORCE explicite. Quand ce fournisseur est décrit dans Git, le secret revient masqué à la relecture et sa dérive ne se détecte pas par simple comparaison : « Piloter la configuration Keycloak en GitOps : adoption, dérive et suppression de champs » détaille ce point.

Plusieurs locataires

Une application multilocataire utilise le point organizations ou common, dont le document de découverte annonce un émetteur générique, https://login.microsoftonline.com/{tenantid}/v2.0. Microsoft demande de vérifier que l'émetteur du jeton correspond à ce modèle et contient le tid du jeton. Keycloak ne sait pas évaluer un modèle : il compare iss à une liste de valeurs exactes séparées par des virgules, et ne vérifie rien si « Issuer » est vide. Deux réglages ferment la porte :

• le champ « Issuer » liste explicitement l'émetteur de chaque locataire admis ;
• « Verify essential claim » exige tid, avec pour valeur une expression régulière des locataires admis, par exemple ^(<tid-a>|<tid-b>)$, comparée aux revendications du jeton d'identité.

Quand chaque organisation cliente a son propre locataire, un fournisseur par locataire, rattaché à une organisation Keycloak, reste plus lisible : l'organisation porte ses domaines et peut rediriger automatiquement un utilisateur vers son fournisseur (« Redirect when email domain matches »).

Variante SAML

Côté Entra ID, l'application d'entreprise hors galerie reçoit comme « Identifier (Entity ID) » l'identifiant de fournisseur de service de Keycloak, par défaut l'URL du royaume, et comme « Reply URL (Assertion Consumer Service URL) » le point /broker/<alias>/endpoint. Keycloak publie ses métadonnées à /realms/<royaume>/broker/<alias>/endpoint/descriptor. Côté Keycloak :

• « Metadata descriptor URL » pointe vers l'URL de métadonnées propre au locataire et à l'application, « Use metadata descriptor URL » activé ;
• « Identity provider entity ID » vaut https://sts.windows.net/<id-du-locataire>/, valeur de l'élément Issuer d'Entra ID ; vide, aucun contrôle de l'émetteur n'a lieu ;
• « Principal type » désigne l'attribut http://schemas.microsoft.com/identity/claims/objectidentifier plutôt que le NameID ;
• « Validate Signatures » et « Want Assertions signed » sont activés ; côté Entra ID, « Sign SAML response and assertion » signe la réponse et l'assertion ; « Sign SAML assertion », réglage par défaut de la plupart des applications de la galerie, suffit aussi aux contrôles de Keycloak 26.7.4 mais laisse la réponse non signée ;
• « HTTP-POST binding logout » est désactivé : Entra ID n'accepte la déconnexion SAML qu'en redirection.

Le renouvellement du certificat de signature est la charge propre de SAML. Entra ID génère un certificat valable trois ans, prévient 60, 30 et 7 jours avant l'expiration, et bascule par « Make certificate active ». Microsoft recommande aux éditeurs d'applications de relire les métadonnées au moins toutes les 24 heures et d'accepter un certificat secondaire avant sa bascule. Keycloak s'en approche : il recharge les certificats quand une réponse POST est signée par une clé inconnue, et son cache expire par défaut au bout de 24 heures. Une bascule répétée sur une application de test vaut mieux qu'une expiration découverte en production.

Première connexion, liaison de comptes et mappers

Le flux de première connexion par défaut

À la première connexion par un fournisseur, Keycloak exécute le flux désigné par « First login flow », par défaut « first broker login ». « Review Profile » affiche le profil reçu ; « Create User If Unique » cherche un compte local de même e-mail ou de même nom d'utilisateur, et en crée un s'il n'en trouve pas. Sinon, le sous-flux de compte existant demande à l'utilisateur de confirmer la liaison (« Confirm link existing account »), puis la fait prouver par un courriel envoyé à l'adresse du compte local, si le royaume a un serveur SMTP, ou par une réauthentification sur ce compte. Tel quel, ce flux ne lie jamais deux comptes sur la seule foi d'une adresse e-mail.

Trust Email et liaison automatique : le chemin de prise de compte

« Trust Email », activé, marque comme vérifiée l'adresse reçue du fournisseur, à la création du compte et, en mode force, à chaque changement. Pour un fournisseur OIDC, Keycloak lit d'abord email_verified si le jeton la porte ; le document de découverte d'Entra ID ne la liste pas, et Microsoft précise que l'e-mail n'est ni garanti ni stable. Activer l'option revient à certifier une donnée que l'émetteur ne certifie pas.

Le danger apparaît quand un flux de liaison automatique remplace le flux par défaut. « Automatically set existing user » rattache l'identité externe au compte local trouvé par e-mail ou par nom d'utilisateur, sans vérification ; la documentation Keycloak le qualifie de dangereux dès que les adresses ne sont pas maîtrisées. Avec un fournisseur multilocataire sans liste d'émetteurs, un risque est que l'administrateur d'un autre locataire crée un utilisateur portant l'adresse d'un compte existant et en prenne le contrôle. « Detect existing broker user » rapproche lui aussi par e-mail ou nom d'utilisateur : il réserve la connexion aux comptes existants, il ne protège pas de cette usurpation.

Les règles en découlent. « Trust Email » reste désactivé pour Entra ID. Toute liaison automatique suppose un locataire unique, un émetteur vérifié et des comptes locaux dont l'e-mail est maîtrisé. Entra ID propose aussi une revendication facultative xms_edov, vraie quand le domaine de l'adresse a été vérifié par le locataire, et émise seulement avec la revendication email : elle renseigne sur le domaine, pas sur la personne, et ne remplace ni le locataire unique ni l'émetteur vérifié.

Mappers et modes de synchronisation

Le mode de synchronisation se règle sur le fournisseur (« Sync mode ») et se surcharge par mappeur (« Sync mode override »). En l'absence de valeur, le code de Keycloak retient legacy.

Trois mappeurs couvrent l'essentiel d'une fédération Entra ID :

• « Attribute Importer » copie une revendication dans un attribut, par exemple oid et tid. Un attribut non déclaré dans le profil utilisateur est ignoré par défaut (« Unmanaged Attributes » à « Disabled ») : il se déclare avant l'import.
• « Hardcoded Role » accorde un rôle à l'import, et à chaque connexion en mode force. Le code ne prévoit aucun retrait : supprimer le mappeur ne reprend pas les rôles accordés.
• « Advanced Claim to Group » ajoute l'utilisateur à un groupe si toutes les revendications listées ont les valeurs attendues, exactes ou en expression régulière. En mode force, il l'en retire dès que la condition n'est plus remplie.

Exemple fictif, dans la continuité du royaume plateforme : le groupe /admins-plateforme et l'identifiant d'objet Entra ID sont illustratifs.

{
  "name": "entra-admins-plateforme",
  "identityProviderAlias": "entra",
  "identityProviderMapper": "oidc-advanced-group-idp-mapper",
  "config": {
    "syncMode": "FORCE",
    "claims": "[{\"key\":\"groups\",\"value\":\"22222222-2222-2222-2222-222222222222\"}]",
    "are.claim.values.regex": "false",
    "group": "/admins-plateforme"
  }
}

# Création du mappeur (exemple fictif)
kcadm.sh create identity-provider/instances/entra/mappers -r plateforme -f mapper-admins.json

La valeur de claims est une chaîne qui contient une liste JSON de paires key et value, et group est le chemin du groupe Keycloak.

Le dépassement des groupes

Entra ID émet au plus 200 groupes dans un JWT et 150 dans une assertion SAML, groupes imbriqués compris. Au-delà, la revendication groups disparaît au profit d'une indication de dépassement (_claim_names) qui renvoie vers Microsoft Graph. Keycloak n'appelle pas Graph. Combiné au mode force, le dépassement agit en silence : à la connexion suivante, l'utilisateur quitte tous les groupes mappés.

Trois parades, par ordre de préférence :

• n'émettre que les « Groups assigned to the application », option que Microsoft recommande aux grandes organisations ; les groupes imbriqués n'y figurent pas, et affecter des groupes à une application demande Entra ID P1 ou P2 ;
• remplacer les groupes par des rôles d'application, émis dans la revendication roles ;
• écrire un mappeur qui interroge GET /me/transitiveMemberOf avec le jeton de l'utilisateur, User.Read étant la permission déléguée la moins privilégiée selon la page Graph ; une telle extension devient alors un composant à maintenir à chaque version de Keycloak.

Déconnexion, sessions et liste de contrôle

La chaîne de déconnexion

Une déconnexion demandée par l'application atteint Keycloak, qui ferme sa session et prévient les clients selon leurs réglages front-channel ou back-channel. Si le fournisseur porte un « Logout URL », Keycloak renvoie ensuite le navigateur vers la déconnexion d'Entra ID, avec post_logout_redirect_uri vers /endpoint/logout_response. « Backchannel logout » reste désactivé : activé, il remplace cette redirection par un appel de serveur à serveur, que la documentation Keycloak réserve aux fournisseurs qui ne déconnectent pas uniquement par le navigateur, alors que Microsoft décrit la déconnexion comme une redirection du navigateur vers end_session_endpoint.

Le sens inverse n'est pas documenté. Pour la déconnexion unique, Entra ID décrit le front-channel : une requête GET vers l'URL de déconnexion front-channel de chaque application où l'utilisateur est connecté, et son document de découverte n'annonce pas de déconnexion back-channel. Au tag 26.7.4, le point /broker/<alias>/endpoint de Keycloak ne traite que la réponse d'authentification et logout_response, et la déconnexion venue d'un fournisseur amont passe par un point back-channel qui attend un jeton de déconnexion. Aucune des deux documentations ne décrit donc de chemin par lequel une déconnexion faite ailleurs dans Entra ID fermerait la session Keycloak : il ne faut pas compter dessus, et les durées de session de Keycloak bornent l'exposition. Ces réglages se relisent à chaque montée de version de Keycloak.

Sessions et réauthentification

La session Keycloak vit indépendamment de celle d'Entra ID : tant que Keycloak ne renvoie pas l'utilisateur vers Entra ID, les règles d'Entra ID, accès conditionnel compris, ne sont pas réévaluées. Le réglage « Prompt » du fournisseur à login force la saisie des identifiants à chaque passage par Entra ID, paramètre que Microsoft documente. « Pass max_age » transmet le max_age demandé par l'application, et Keycloak refuse alors un jeton dont auth_time est trop ancien ou absent ; Microsoft ne documente pas max_age sur son point d'autorisation et range auth_time parmi les revendications facultatives : ce réglage se valide sur un locataire de test avant d'être retenu. Si l'étape qui suit la connexion doit être locale, par exemple un second facteur propre à Keycloak, elle se place dans le « Post login flow » du fournisseur, car la redirection vers un fournisseur par défaut interrompt le flux de navigateur.

Liste de contrôle de mise en service

Cette revue se fait avant l'ouverture aux utilisateurs. Quand Keycloak fait partie d'une plateforme Kubernetes à mettre en production, la démarche d'ensemble est décrite sur la page Mise en production Kubernetes : ouvrir par étapes.

Sources officielles et limites de lecture

Trois limites. Les comportements lus dans le code et la documentation n'ont pas été rejoués sur un locataire Entra ID : l'assertion signée par Keycloak, max_age et la déconnexion venue d'Entra ID restent à valider sur un locataire de test. Les écrans d'Entra ID changent plus vite que les protocoles ; les libellés cités sont ceux du 29 septembre 2026. Enfin, les noms d'options et la structure des représentations Keycloak sont à relire à chaque version mineure.

Sources

1. OpenID Connect Core 1.0 incorporating errata set 2, OpenID Foundation, https://openid.net/specs/openid-connect-core-1_0.html, consulté le 29/09/2026.
2. OpenID Connect Front-Channel Logout 1.0, OpenID Foundation, https://openid.net/specs/openid-connect-frontchannel-1_0.html, consulté le 29/09/2026.
3. OpenID Connect Back-Channel Logout 1.0 incorporating errata set 1, OpenID Foundation, https://openid.net/specs/openid-connect-backchannel-1_0.html, consulté le 29/09/2026.
4. OpenID Connect RP-Initiated Logout 1.0, OpenID Foundation, https://openid.net/specs/openid-connect-rpinitiated-1_0.html, consulté le 29/09/2026.
5. Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 15 mars 2005, https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf, consulté le 29/09/2026.
6. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 15 mars 2005, https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf, consulté le 29/09/2026.
7. Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 15 mars 2005, https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf, consulté le 29/09/2026.
8. RFC 9700, Best Current Practice for OAuth 2.0 Security (BCP 240), IETF, https://www.rfc-editor.org/rfc/rfc9700, consulté le 29/09/2026.
9. RFC 7636, Proof Key for Code Exchange by OAuth Public Clients, IETF, https://www.rfc-editor.org/rfc/rfc7636, consulté le 29/09/2026.
10. RFC 8252, OAuth 2.0 for Native Apps (BCP 212), IETF, https://www.rfc-editor.org/rfc/rfc8252, consulté le 29/09/2026.
11. Keycloak 26.7.4, note de version, GitHub, https://github.com/keycloak/keycloak/releases/tag/26.7.4, consulté le 29/09/2026.
12. Server Administration Guide, OpenID Connect compared to SAML, Keycloak 26.7.4, https://github.com/keycloak/keycloak/blob/26.7.4/docs/documentation/server_admin/topics/sso-protocols/ref-saml-vs-oidc.adoc, consulté le 29/09/2026.
13. Server Administration Guide, Identity brokering (General configuration, OpenID Connect v1.0 identity providers, SAML v2.0 identity providers, Microsoft, Mapping claims and assertions, First login flow, Default identity provider, Post login flow, Identity broker logout), Keycloak 26.7.4, https://github.com/keycloak/keycloak/tree/26.7.4/docs/documentation/server_admin/topics/identity-broker, consulté le 29/09/2026.
14. Server Administration Guide, Managing identity providers (organizations), Keycloak 26.7.4, https://github.com/keycloak/keycloak/blob/26.7.4/docs/documentation/server_admin/topics/organizations/managing-identity-providers.adoc, consulté le 29/09/2026.
15. Server Administration Guide, user profile (managed and unmanaged attributes), realm keys, vault, admin CLI, Keycloak 26.7.4, https://github.com/keycloak/keycloak/tree/26.7.4/docs/documentation/server_admin/topics, consulté le 29/09/2026.
16. Keycloak SAML Galleon feature pack for WildFly and EAP, Keycloak 26.7.4, https://github.com/keycloak/keycloak/blob/26.7.4/docs/guides/securing-apps/saml-galleon-layers.adoc, consulté le 29/09/2026.
17. Code source Keycloak au tag 26.7.4 : OIDCIdentityProvider, AbstractOAuth2IdentityProvider, OAuth2IdentityProviderConfig, OIDCIdentityProviderConfig, IdentityProviderModel, IdentityProviderRepresentation, MicrosoftIdentityProvider, AbstractIdentityProvider, IdentityBrokerService, IdpAutoLinkAuthenticator, IdpCreateUserIfUniqueAuthenticator, IdpDetectExistingBrokerUserAuthenticator, AbstractClaimMapper, AbstractClaimToGroupMapper, AdvancedClaimToGroupMapper, HardcodedRoleMapper, IdentityProviderMapperSyncModeDelegate, IdentityProviderMapperModel, MapperTypeSerializer, LogoutEndpoint, messages_en.properties de la console, https://github.com/keycloak/keycloak/tree/26.7.4, consulté le 29/09/2026.
18. OpenID Connect on the Microsoft identity platform, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc, consulté le 29/09/2026.
19. Document de découverte OpenID de Microsoft Entra ID (autorité organizations), https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration, consulté le 29/09/2026.
20. ID token claims reference, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference, consulté le 29/09/2026.
21. Optional claims reference, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity-platform/optional-claims-reference, consulté le 29/09/2026.
22. Configure group claims for applications by using Microsoft Entra ID, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims, consulté le 29/09/2026.
23. Add app roles and get them from a token, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity-platform/howto-add-app-roles-in-apps, consulté le 29/09/2026.
24. Manage users and groups assignment to an application, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/assign-user-or-group-access-portal, consulté le 29/09/2026.
25. List a user's memberships (direct and transitive), Microsoft Graph, https://learn.microsoft.com/en-us/graph/api/user-list-transitivememberof?view=graph-rest-1.0, consulté le 29/09/2026.
26. Redirect URI (reply URL) best practices and limitations, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity-platform/reply-url, consulté le 29/09/2026.
27. Add and manage app credentials in Microsoft Entra ID, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity-platform/how-to-add-credentials, consulté le 29/09/2026.
28. Microsoft identity platform certificate credentials, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity-platform/certificate-credentials, consulté le 29/09/2026.
29. Create a trust relationship between an app and an external identity provider, Microsoft Learn, https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust, consulté le 29/09/2026.
30. Convert single-tenant app to multitenant on Microsoft Entra ID, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity-platform/howto-convert-app-to-be-multi-tenant, consulté le 29/09/2026.
31. Single sign-on SAML protocol, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity-platform/single-sign-on-saml-protocol, consulté le 29/09/2026.
32. Single Sign-Out SAML Protocol, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity-platform/single-sign-out-saml-protocol, consulté le 29/09/2026.
33. Customize SAML token claims, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity-platform/saml-claims-customization, consulté le 29/09/2026.
34. Enable SAML single sign-on for an enterprise application, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/add-application-portal-setup-sso, consulté le 29/09/2026.
35. Certificate signing options in a SAML token, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/certificate-signing-options, consulté le 29/09/2026.
36. Tutorial: Manage federation certificates, Microsoft Learn, https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-manage-certificates-for-federated-single-sign-on, consulté le 29/09/2026.
37. Configurer OpenID Connect (OIDC) pour ProConnect en tant que Fournisseur d'Identité (FI), DINUM, https://partenaires.proconnect.gouv.fr/docs/fournisseur-identite/configuration, consulté le 29/09/2026.