Skip to content

Comment fonctionne l'authentification unique, et en quoi SAML et OIDC diffèrent-ils ?

Réponse courte

Le SSO centralise l'authentification chez un fournisseur d'identité (IdP). Quand un utilisateur visite un fournisseur de service (l'application), l'application redirige vers l'IdP ; l'utilisateur se connecte une fois, et l'IdP renvoie une assertion ou un jeton signé attestant son identité. SAML porte cela comme une assertion XML signée ; OIDC le porte comme un jeton d'identité JSON signé posé sur OAuth 2.0. L'application fait confiance à la signature de l'IdP plutôt que de gérer elle-même les mots de passe.

Les questions sur le SSO testent si vous comprenez la confiance fédérée : de nombreuses applications externalisant l'acte d'authentification à un seul fournisseur d'identité. Bien distinguer SAML et OIDC montre que vous avez réellement travaillé avec.

Le modèle de base

Dans le SSO, il y a deux rôles : le fournisseur d'identité (IdP) qui authentifie les utilisateurs et le fournisseur de service (SP) — l'application — qui s'y fie. Quand un utilisateur arrive sur l'application, celle-ci le redirige vers l'IdP. S'il y est déjà connecté, aucune invite n'apparaît ; sinon il s'authentifie une fois. L'IdP renvoie alors le navigateur vers l'application en portant une déclaration cryptographiquement signée disant « voici qui est l'utilisateur ». L'application vérifie la signature de l'IdP et crée une session locale. L'utilisateur saisit ses identifiants une seule fois et atteint toutes les applications fédérées.

Le grand avantage est la centralisation : un seul endroit pour imposer la MFA, la politique de mots de passe, l'accès conditionnel et le déprovisionnement. Désactivez le compte chez l'IdP et l'accès partout meurt d'un coup.

SAML vs OIDC

  • SAML 2.0 est le standard d'entreprise plus ancien. L'IdP émet une assertion XML signée, généralement délivrée via un POST de navigateur. Il est mature et omniprésent en B2B/entreprise, mais le XML est lourd et peu pratique pour le mobile et les SPA.
  • OIDC (OpenID Connect) est une couche d'identité posée sur OAuth 2.0. L'IdP émet un jeton d'identité JSON (un JWT) aux côtés des jetons OAuth. Il est léger, compatible JSON/REST, et la valeur par défaut pour les applications web, mobiles et pilotées par API modernes.

Les deux reposent sur la vérification par le SP de la signature de l'IdP pour faire confiance à l'assertion — cette signature est toute la base de la confiance.

Le risque

Le SSO concentre le risque : l'IdP devient un point de défaillance unique et une cible alléchante. S'il est compromis (ou si une assertion SAML peut être forgée à cause d'un bug d'analyse), l'attaquant obtient tout. C'est pourquoi les IdP exigent la MFA la plus forte et résistante à l'hameçonnage.

Ce que recherchent les recruteurs

Le modèle IdP/SP de redirection-et-assertion-signée, l'avantage une-connexion-plusieurs-applications, SAML (XML signé) vs OIDC (JWT sur OAuth), la vérification de signature comme racine de la confiance, et la conscience du rayon d'impact concentré.

Questions de suivi probables

  • Pourquoi OIDC est-il souvent préféré à SAML pour les applications modernes et mobiles ?
  • Quel est le rayon d'impact si l'IdP est compromis, et comment le réduire ?
  • Comment l'application vérifie-t-elle qu'une assertion SAML ou un jeton d'identité OIDC est authentique ?

Sources

Certifications

Recevez 100 questions d'entretien en cybersécurité + réponses

Laissez votre e-mail et nous vous enverrons le pack PDF gratuit et le jeu de flashcards.

Pas de spam. Désabonnez-vous à tout moment.