OIDC, SAML et OAuth 2.1 en fédération

La fédération délègue l’authentification à une autorité d’identité tout en laissant chaque application décider de ce qu’elle accepte. Le compromis central est net : gagner un point de contrôle et une expérience cohérente, payer une dépendance critique au fournisseur d’identité, à ses clés, à ses métadonnées et à sa disponibilité.

→ Lire l’explication complète de la marmotte

OIDC et SAML : deux modèles, deux terrains

OpenID Connect (OIDC) ajoute une couche d’authentification au protocole OAuth (Open Authorization). Une application cliente redirige le navigateur vers un fournisseur d’identité, reçoit une réponse signée, puis valide l’identité du sujet et les conditions de cette réponse. Le format dominant est le JSON Web Token (JWT), un objet JSON signé et transportable.

Security Assertion Markup Language (SAML) fédère également l’authentification, mais au moyen d’assertions XML signées. Le fournisseur d’identité émet une assertion destinée à un fournisseur de service, généralement via le navigateur. SAML reste très implanté dans les applications métier historiques, les portails SaaS d’entreprise et les produits ayant une intégration SAML mature. Il n’est pas obsolète : il est surtout encombrant, verbeux et moins agréable à intégrer dans une API. Nuance qui évite de remplacer une fédération stable par une migration motivée par trois slides de salon.

Le choix doit être tranché ainsi :

choisir OIDC pour les nouvelles applications web, mobiles, les API et les architectures cloud natives ;
conserver SAML lorsqu’un fournisseur de service ne propose pas OIDC ou lorsqu’une fédération existante repose déjà sur des métadonnées SAML maîtrisées ;
ne pas exposer SAML directement à des clients mobiles ou à des API : un pont de fédération côté fournisseur d’identité évite de propager XML Signature dans chaque composant.

OIDC sépare deux objets qu’il ne faut pas mélanger. Le jeton d’identité prouve une authentification auprès du client identifié par son audience. Le jeton d’accès porte une délégation vers une ressource, par exemple une API. Présenter un jeton d’identité à une API est une erreur d’architecture, même si le JWT contient un champ sub très convaincant. L’API doit vérifier un jeton d’accès dont l’audience lui est explicitement destinée.

SAML concentre davantage les informations dans l’assertion, mais exige les mêmes vérifications fondamentales : signature, émetteur, destinataire, audience, fenêtre temporelle et corrélation avec la requête initiale. Accepter une assertion correctement signée mais destinée à un autre service revient à accepter le badge du parking pour ouvrir la salle serveur. La cryptographie n’a rien demandé.

Les clés de signature doivent venir de métadonnées authentifiées et être renouvelées avec chevauchement. En OIDC, le document de découverte et le JSON Web Key Set (JWKS), ensemble de clés publiques JSON, doivent être récupérés uniquement sur Transport Layer Security (TLS), avec validation du nom de serveur et de la chaîne de certificats. Le cache des clés doit tolérer une rotation : rafraîchir le jeu de clés lorsqu’un identifiant de clé inconnu apparaît, sans transformer chaque requête invalide en appel réseau.

Pour les fondations de certificats et de confiance, voir PKI et TLS et les principes d’architecture cyber.

OAuth 2.1 : déléguer un accès, pas authentifier une personne

OAuth 2.1 encadre l’autorisation déléguée. Il permet à un client d’obtenir un jeton limité pour appeler une ressource protégée, sans recevoir le mot de passe de l’utilisateur. OIDC utilise OAuth comme transport d’autorisation, puis ajoute l’authentification. OAuth seul ne répond pas à la question « qui s’est connecté ? ». Il répond à « quel client peut exercer quelle délégation ? ».

Le flux à retenir pour un client public, navigateur ou application mobile, est Authorization Code avec Proof Key for Code Exchange (PKCE). PKCE lie le code d’autorisation à une valeur secrète éphémère générée par le client. Intercepter le code dans une redirection ne suffit alors plus à l’échanger contre des jetons. Le flux implicite et le flux par mot de passe doivent disparaître : le premier expose des jetons dans des canaux fragiles, le second apprend à l’application à manipuler un mot de passe qu’elle ne devrait jamais voir.

Une redirection enregistrée doit correspondre exactement à une valeur préconfigurée : schéma, hôte, port, chemin et paramètres si l’autorité les autorise. Les jokers, les correspondances par préfixe et les sous-domaines libres sont des générateurs de fuite de code et de jeton. https://app.example/callback.evil.invalid ne doit pas être considéré comme proche de https://app.example/callback, malgré l’optimisme habituel des comparaisons de chaînes.

L’état de corrélation, souvent nommé state, doit être imprévisible, lié à la session locale et vérifié au retour. Il protège principalement contre la substitution de réponse et les attaques de type Cross-Site Request Forgery (CSRF), requêtes déclenchées depuis un site tiers. En OIDC, la valeur nonce relie aussi le jeton d’identité à la demande initiale et limite la réutilisation d’une réponse.

OAuth ne garantit ni l’autorisation métier fine, ni la sécurité de l’interface, ni l’absence de fraude sur le terminal. La décision « cet agent peut valider cette dépense » appartient au service de ressource, à ses règles métier et à ses journaux d’audit. Une portée payments.write ne constitue pas une politique de séparation des tâches. C’est une étiquette, pas un comité de contrôle interne.

Jetons d’accès, scopes et audiences

Un jeton d’accès doit être émis pour une audience précise, c’est-à-dire l’API qui le vérifiera. Une API ne doit pas accepter un jeton destiné à une autre API sous prétexte que l’émetteur est reconnu. Cette vérification bloque la réutilisation latérale d’un jeton volé entre services.

Les scopes, portées d’autorisation déclarées, doivent décrire une permission stable et compréhensible : orders.read, orders.write, admin.users.read. Éviter les scopes fourre-tout tels que full_access, ainsi que les scopes construits à partir d’identifiants de ressources. Une permission par objet ne tient pas dans un jeton sans créer un annuaire distribué déguisé en JWT. Les contrôles sur le locataire, le propriétaire, l’état de la ressource et le contexte transactionnel restent côté API.

La durée d’un jeton d’accès borne la fenêtre d’exploitation après vol. Pour un jeton porteur présenté à une API, viser 5 à 15 minutes est un compromis raisonnable. Une durée plus courte augmente les échanges avec l’autorité d’identité ; une durée de plusieurs heures transforme un vol mémoire ou un journal trop bavard en accès durable. L’horloge doit être synchronisée par Network Time Protocol (NTP), avec une tolérance de dérive limitée lors de la validation de exp et nbf.

Un JWT signé permet une validation locale, donc performante et résistante à une panne temporaire de l’autorité d’identité. Son prix est la révocation difficile. Une API ne peut pas deviner qu’un JWT encore valide a été retiré, sauf consultation d’une liste de révocation, introspection distante ou mécanisme de version de session. Les jetons opaques, références aléatoires vérifiées auprès de l’autorité, rendent la révocation immédiate mais rendent l’autorité critique dans le chemin de requête.

Le choix dépend de la tolérance au délai de révocation :

JWT courts pour des API à fort débit et un risque acceptable pendant quelques minutes ;
jetons opaques ou introspection pour les opérations sensibles exigeant un arrêt immédiat ;
réauthentification et vérification de risque hors du seul mécanisme de jeton pour les actions irréversibles.

Exemple OIDC : validation d’un jeton d’accès

L’exemple suivant utilise curl pour interroger un endpoint d’introspection OAuth. Il convient aux jetons opaques ou lorsqu’une révocation rapide prime sur l’autonomie de l’API. Le secret client doit être chargé depuis un gestionnaire de secrets, jamais placé dans un dépôt ou une variable d’image de conteneur.

# Vérifier l'état courant d'un jeton auprès de l'autorité d'identité.
# OAUTH_CLIENT_SECRET doit provenir d'un coffre de secrets au démarrage.
curl --fail --silent --show-error \
  --user "api-introspection:${OAUTH_CLIENT_SECRET}" \
  --data-urlencode "token=${ACCESS_TOKEN}" \
  https://id.example.net/oauth2/introspect | jq '{
    active,
    sub,
    aud,
    scope,
    exp,
    client_id
  }'

# L'API doit refuser si active vaut false, si aud ne la désigne pas,
# ou si scope ne contient pas la permission requise.

L’endpoint d’introspection doit être accessible uniquement aux clients autorisés, idéalement avec authentification mutuelle TLS pour les appels internes à haute sensibilité. Exposer cette interface à tous les services revient à distribuer un oracle de session : pratique pour l’attaquant, moins pour l’équipe d’astreinte.

Refresh tokens, révocation et exploitation

Le jeton de rafraîchissement obtient de nouveaux jetons d’accès sans nouvelle authentification interactive. Sa durée doit être nettement supérieure à celle du jeton d’accès, mais jamais assimilée à une session éternelle. Pour une application web, privilégier une session serveur protégée par un cookie HttpOnly, Secure et SameSite, plutôt qu’un jeton de rafraîchissement stocké dans le navigateur.

Pour les clients publics, appliquer la rotation : chaque utilisation produit un nouveau jeton de rafraîchissement et invalide le précédent. La réutilisation d’un ancien jeton signale un vol ou une course concurrente ; elle doit entraîner la révocation de la famille de jetons et une nouvelle authentification. Sans détection de réutilisation, la rotation n’est qu’une sculpture de sécurité contemporaine.

La révocation doit couvrir au minimum : déconnexion, changement de mot de passe, désactivation de compte, retrait du consentement, compromission du client et changement de privilèges. Mais elle ne rétroagit pas sur les décisions déjà prises ni sur les données déjà copiées. Elle ne révoque pas non plus magiquement les JWT déjà validés hors ligne. La durée courte des jetons d’accès est donc une contre-mesure structurelle, pas une préférence esthétique.

Superviser les échecs de validation par émetteur, audience, signature, expiration et kid inconnu. Détecter les demandes de scopes inhabituels, les rotations de jetons réutilisés et les pics d’introspection. Sauvegarder la configuration de fédération, les clés de signature actives et précédentes, les secrets de clients, ainsi que l’état de révocation et des familles de rafraîchissement. La restauration doit préserver les identifiants de clés, sinon tous les jetons existants deviennent soit invalides, soit suspects. Les pratiques de gestion des secrets sont détaillées dans les fondations et dans la rubrique identités.

🐝 Ce qui arrive si on s’en passe

Sans fédération gouvernée, chaque application redevient un point d’authentification autonome : les comptes se dupliquent, les départs ne se propagent nulle part et aucune trace commune ne permet de reconstituer qui s’est connecté, depuis quel client, avec quelle portée. Sans audience vérifiée ni redirections exactes, un jeton obtenu pour un service ouvre les autres, et un code d’autorisation intercepté suffit. Sans rotation à recouvrement des clés de signature, une simple relève de certificat invalide d’un coup les jetons en circulation et bloque les connexions. Sans introspection ni durées courtes, une révocation reste théorique : le retrait d’un accès ne se voit pas côté API. Sans supervision des échecs de validation (émetteur, signature, expiration, identifiant de clé inconnu), une réutilisation de jeton de rafraîchissement volé passe pour du trafic normal, et la reprise après compromission perd son point de départ.

🦫 Explication de la marmotte 🍫

Une application peut laisser un service central vérifier l’identité d’une personne. Après cette vérification, le service central remet des documents numériques signés. L’application contrôle la signature, vérifie que le document vient bien du service attendu, qu’il lui est destiné et qu’il n’est pas expiré.

Deux formats existent souvent. Le premier utilise des documents JSON, un format de texte structuré courant dans les applications modernes. Le second utilise des documents XML, un autre format de texte, fréquent dans des logiciels plus anciens. Les deux peuvent prouver une connexion si les signatures et les destinataires sont contrôlés.

Un protocole d’autorisation sert à donner à une application un droit limité d’appeler un service, sans lui donner le mot de passe. Ce droit doit préciser ce qui est permis, par exemple lire des commandes, et pour quel service. Il ne prouve pas à lui seul l’identité d’une personne.

Les droits d’accès expirent vite, car un document volé reste exploitable jusqu’à sa fin de validité. Un second document, gardé plus longtemps, peut demander de nouveaux droits courts. Chaque utilisation de ce second document doit le remplacer. Si un ancien document réapparaît, l’accès doit être coupé, car quelqu’un a peut-être copié une information secrète.

Supprimer un droit central ne retire pas instantanément les documents déjà acceptés par un service hors ligne. Pour les actions sensibles, le service doit demander régulièrement au service central si le droit est encore actif.

Pages voisines

La citent

OIDC, SAML et OAuth 2.1 en fédération

Elle cite

: les deux pages se citent l’une l’autre.

OIDC, SAML et OAuth 2.1 en fédération

OIDC, SAML et OAuth 2.1 en fédération

OIDC et SAML : deux modèles, deux terrains

OAuth 2.1 : déléguer un accès, pas authentifier une personne

Jetons d’accès, scopes et audiences

Exemple OIDC : validation d’un jeton d’accès

Refresh tokens, révocation et exploitation

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines