OpenID Connect, construit sur OAuth 2.0, est le protocole d'identité fédérée dominant pour les stacks modernes. Chaque grand IdP d'entreprise le prend en charge ; chaque IdP cloud pour la main-d'œuvre le propose ; chaque framework applicatif moderne fournit une bibliothèque pour cela. La partie réputée facile consiste à supposer que quelques lignes de code SDK par application suffisent.
En pratique, un relying party OIDC qui transporte du vrai trafic de production a une longue liste de points à faire correctement. La signature de l'ID token doit être vérifiée contre le JWKS publié par l'IdP, en sélectionnant la bonne clé via le kid, et le cache doit être rafraîchi lorsque l'IdP effectue une rotation de clés. La revendication audience doit correspondre à l'ID client configuré. L'issuer doit correspondre à l'issuer attendu configuré. La durée de validité doit être contrôlée avec une tolérance de dérive d'horloge limitée. Le nonce contenu dans l'ID token doit correspondre au nonce envoyé par AAM dans la requête d'autorisation — s'il ne correspond pas, ce n'est pas une erreur d'analyse, c'est une tentative de rejeu.
La couche OAuth 2.0 sous-jacente a ses propres pièges. Le state doit être lié à la session de l'utilisateur comme protection CSRF et avoir un TTL court. PKCE doit être utilisé (de préférence S256), afin qu'un code d'autorisation intercepté ne puisse pas être échangé par l'attaquant. Les attaques de mixup — où l'attaquant trompe le relying party pour qu'il parle au mauvais IdP — sont déjouées en liant le callback à un IdP spécifique et en vérifiant l'issuer en conséquence. Dans une intégration SDK naïve, aucune de ces défenses n'est automatique.
Une autre forme d'échec consiste à embarquer le SDK OIDC directement dans chaque application. Chaque application porte alors séparément ses propres décisions de confiance, son cache JWKS, ses journaux d'audit et sa configuration IdP. Un seul changement d'IdP devient un déploiement coordonné multi-applications. La MFA, l'accès conditionnel, la confiance de l'appareil et le comportement de déconnexion sont résolus à nouveau séparément pour chaque application, souvent de manière incohérente.
Le côté opérationnel est tout aussi important. La mise à jour du document de discovery de l'IdP, la gestion de la rotation des clés de signature, le routage IdP différent par tenant, les mappings de revendications différents pour différentes applications et les flux de déconnexion ne sont pas de petits détails ajoutés après coup. Ce sont des éléments fondamentaux pour que la fédération OIDC fonctionne de manière sûre et durable.
Le bon endroit est la périphérie d'accès. OIDC doit être vérifié en un seul point ; il doit être géré dans la même couche que l'authentification, la MFA, l'accès conditionnel, la confiance de l'appareil et le SSO Backend. Ainsi les applications ne portent pas la complexité du protocole de fédération ; elles reçoivent seulement une identité vérifiée, propre et fiable.
Bien gérer OIDC ne se résume pas à se connecter à un IdP avec un SDK. Il s'agit de vérifier, d'auditer l'ID token en un seul point — dans le même moteur que la MFA, l'accès conditionnel, la confiance de l'appareil et le SSO Backend — de manière conforme aux standards, et de le transmettre en toute sécurité aux applications.
Une seule passerelle AAM termine OIDC correctement à la périphérie ; le reste du moteur d'accès repose dessus.
Flux de code d'autorisation avec PKCE, vérification de la signature de l'ID token via JWKS, défense contre le rejeu liée au nonce, défense CSRF liée au state, application de l'audience/issuer/validité. Le même moteur parle OAuth 2.0 simple pour les IdP qui ne fournissent pas d'ID token ; ainsi les fournisseurs qui ne livrent que des jetons et les fournisseurs OIDC complets partagent une seule base de code.
Une seule passerelle AAM peut router simultanément différentes applications vers différents IdP, et différents tenants de la même application vers différents IdP. La sélection de l'IdP se fait par requête à partir du contexte de l'application ou du tenant — pas de passerelle distincte par IdP, pas de sélecteur manuel pour l'utilisateur.
Le nonce lie l'ID token à la requête d'autorisation qui l'a demandé ; le state lie le callback à la session de l'utilisateur ; PKCE lie l'échange de code au client public d'origine. Aucun de ces éléments n'est un drapeau optionnel que l'intégrateur pourrait oublier — c'est le flux par défaut lui-même.
Une authentification OIDC ne fonctionne pas seule — elle est composée avec la MFA en périphérie (si l'IdP n'a pas appliqué de step-up), les expressions d'accès conditionnel, l'évaluation continue de la confiance et l'injection SSO Backend vers le backend. L'ID token devient une entrée de la session AAM ; il ne devient pas toute la session.
Un relying party OIDC conforme aux standards, plus les fonctionnalités opérationnelles qui rendent la fédération sûre et gérable à grande échelle.
AAM démarre le flux de code d'autorisation OAuth 2.0 avec PKCE activé par défaut — code_challenge_method=S256, un code_verifier frais pour chaque requête, jamais réutilisé. Un attaquant qui ne génère pas le verifier ne peut pas échanger un code d'autorisation intercepté contre des jetons. Le PKCE simple reste disponible pour les IdP qui l'imposent ; S256 est la valeur par défaut configurée.
À l'arrivée du callback, AAM récupère le JWKS de l'IdP, sélectionne la clé de signature à partir de l'en-tête kid de l'ID token et vérifie la signature de l'ID token avec l'algorithme indiqué dans l'en-tête (RS256 et le reste de la famille standard). Un cache miss sur le kid rafraîchit immédiatement le JWKS ; ainsi une rotation de clés de l'IdP ne bloque pas les connexions valides.
La revendication audience de l'ID token doit contenir l'ID client configuré ; l'issuer doit correspondre à l'issuer attendu configuré ; la fenêtre de validité (exp/nbf) est appliquée avec une tolérance de dérive d'horloge limitée ; le nonce doit correspondre au nonce envoyé par AAM dans la requête d'autorisation. Une non-concordance du nonce est traitée non pas comme une erreur d'analyse, mais comme un signal de rejeu avec son propre événement d'audit.
Les réponses JWKS sont mises en cache avec un TTL d'une heure dans un magasin partagé entre les processus workers et les instances de passerelle. Un cache hit élimine l'aller-retour réseau à chaque connexion ; un cache miss sur le kid demandé déclenche un rafraîchissement instantané depuis l'URI JWKS ; ainsi la rotation de routine des clés de l'IdP ne produit pas d'interruption de connexion.
Les paramètres d'autorisation OIDC standard sont une configuration de premier ordre : scope (openid ajouté automatiquement), display pour l'expérience de connexion à l'IdP, max_age pour la réauthentification forcée, ui_locales pour les pages IdP localisées et acr_values pour demander une classe de contexte d'authentification spécifique — utile pour demander à l'IdP d'appliquer une MFA step-up.
Les profils intégrés sont fournis avec des valeurs par défaut raisonnables pour les fournisseurs courants (endpoints well-known, URI JWKS, habitudes de scope). Le chemin IdP personnalisé, où les endpoints, les scopes et les mappings sont saisis manuellement, reste disponible pour tout fournisseur OIDC ou OAuth 2.0 conforme aux standards.
Après la vérification de la signature, les revendications de l'ID token sont fusionnées avec la réponse de l'endpoint userinfo de l'IdP. En cas de conflit, les revendications signées de l'ID token sont considérées comme prioritaires sur les champs userinfo non signés ; ainsi un attaquant qui altère la réponse userinfo ne peut pas modifier silencieusement une revendication d'identité signée.
Le RP-Initiated Logout (déconnexion front-channel signée de la spéc OIDC) et la déconnexion back-channel pour les notifications de fin de session depuis l'IdP sont sur la feuille de route. L'enregistrement dynamique de client OIDC — mettre en service une nouvelle application en l'enregistrant automatiquement auprès de l'IdP — est également planifié. L'infrastructure de session et d'audit est déjà conçue pour prendre en charge ces flux.
Les mécanismes qui maintiennent une fédération OIDC sûre, à jour et observable.
Le paramètre OAuth state est stocké contre la session de l'utilisateur avec un TTL de 10 minutes. À l'arrivée du callback, AAM vérifie que le state appartient à la même session qui a démarré le flux — un attaquant qui rejoue une valeur de state dans le navigateur d'un autre utilisateur est rejeté avec un événement d'audit OAUTH_STATE_MISMATCH.
Lorsque la vérification de la signature de l'ID token est sautée pour une raison opérationnelle — JWKS inaccessible, aucun kid correspondant, JWK corrompu, URI JWKS manquant — un événement d'audit dédié enregistre la cause racine spécifique. Les opérateurs peuvent distinguer une panne temporaire du JWKS d'une mauvaise configuration ou d'un type de clé non pris en charge sans relire les journaux d'exécution.
Les ID tokens portent des horodatages iat, nbf et exp. Les vraies horloges dérivent ; AAM applique une tolérance de dérive d'horloge limitée (60 secondes par défaut pour le validateur JWT sous-jacent) ; ainsi une petite dérive ne rejette pas les connexions valides, tandis qu'une grande dérive — indicateur de mauvaise configuration ou de rejeu — est tout de même rejetée.
L'échange de jetons et les requêtes userinfo vers l'IdP utilisent des délais d'attente limités pour la connexion, le DNS et la durée totale ; ainsi un IdP lent ou non réactif ne peut pas occuper les workers de la passerelle. L'échange de jetons fonctionne avec un budget total de 30 secondes ; userinfo fonctionne avec un budget de 15 secondes ; les budgets de connexion et de DNS des deux sont plus courts ; ainsi les échecs échouent rapidement.
Chaque étape du flux OIDC — début du flux, succès du callback, échange de jetons (quels jetons sont revenus), résultat de la vérification de la signature de l'ID token, résultat de la récupération du JWKS — est enregistrée avec un ID de corrélation qui revient à la session AAM et au(x) backend(s) derrière elle. La question « qui s'est connecté via quel IdP et quand » se répond avec une seule requête.
La découverte automatique du fournisseur OIDC via l'endpoint .well-known/openid-configuration et l'alerte de l'opérateur lorsque les endpoints découverts ou les jeux de clés de signature changent sont sur la feuille de route. La télémétrie de rotation JWKS — métriques de changement des clés de signature, indices de jours restants avant l'expiration de la clé actuelle, runbooks de rotation automatique — est également planifiée.
Les IdP d'entreprise existants qui authentifient déjà la main-d'œuvre via OIDC. AAM s'enfiche comme un relying party sans demander à l'équipe IdP de changer quoi que ce soit. Les nouvelles applications rejoignent la fédération non pas en ajoutant un nouveau SDK OIDC à chaque base de code, mais en ajoutant un enregistrement dans AAM.
Des outils internes qui s'authentifient contre le tenant Google Workspace de l'organisation, ou des outils pour développeurs qui utilisent GitHub comme IdP. AAM parle OIDC à Google et OAuth 2.0 à GitHub — depuis le même moteur — et mappe chacun vers le format de session canonique d'AAM.
Des applications SaaS où chaque client apporte son propre IdP OIDC. Une seule passerelle AAM place tous les tenants en façade ; le trafic de chaque tenant est routé vers l'IdP de ce tenant. Ajouter un tenant n'est pas un déploiement ; c'est ajouter une modification de configuration au magasin d'enregistrements d'IdP.
Certains IdP authentifient mais n'appliquent pas la MFA step-up ou l'accès conditionnel de manière uniforme pour chaque application. AAM accepte l'authentification de l'IdP, puis fait reposer sa propre MFA, ses expressions d'accès conditionnel et son évaluation continue de la confiance par-dessus, avant d'accorder l'accès à l'application.
Connectons AAM à votre IdP OIDC — d'entreprise, cloud ou auto-hébergé — et faisons reposer le reste du moteur d'accès, avec MFA, accès conditionnel, confiance de l'appareil et SSO Backend, sur l'ID token vérifié.