Cyberpediapar Brain
FRDEEN

Le SSO : SAML et OpenID Connect expliqués simplement

Un seul compte ouvre plusieurs applications grâce à un jeton. Ce que font SAML et OpenID Connect, et les gestes du salarié face aux pièges.

En 30 secondes

Où ça arrive
À chaque ouverture d'une application d'entreprise qui renvoie vers la page de connexion commune.
Ce que veut l'attaquant
Un jeton, un cookie de session ou une autorisation donnée à une application piégée, qui lui ouvrent l'accès sans connaître le mot de passe23.
Le réflexe
Vérifier l'adresse de la page de connexion, activer la double authentification sur le compte principal, se déconnecter sur un poste partagé et signaler toute demande de connexion inattendue.
Si c'est déjà fait
Prévenir le service informatique sans attendre, en indiquant la page ouverte et l'autorisation accordée.

De quoi parle-t-on

Le SSO (single sign-on, connexion unique) permet de s'authentifier une fois auprès d'un fournisseur d'identité, puis d'obtenir l'accès à plusieurs applications sans créer ni retenir un mot de passe pour chacune1. Le salarié saisit ses identifiants sur la page de connexion de l'entreprise, et les applications reçoivent une preuve de son identité plutôt que son mot de passe.

Deux protocoles servent surtout à cet échange : SAML et OpenID Connect (OIDC). Ils ne se voient pas à l'écran, mais leurs jetons sont devenus une cible : voler le jeton ou la session revient à voler l'accès.

Questions directes

Qu'est-ce que le SSO ?

Un compte unique, géré par un fournisseur d'identité, sert à plusieurs applications. Le document du NIST sur la fédération d'identité décrit ce cas : l'utilisateur ne s'authentifie pas directement auprès de l'application, c'est le fournisseur d'identité qui produit une assertion, souvent à la demande de l'application1. Le NIST précise que ce mécanisme dispense de détenir des identifiants séparés pour chaque service1.

Quelle différence entre SAML et OpenID Connect ?

SAML 2.0 est un protocole qui permet à des applications d'offrir le SSO à leurs utilisateurs ; il échange des assertions entre le fournisseur d'identité et l'application4. OpenID Connect étend le protocole d'autorisation OAuth 2.0 pour en faire un protocole d'authentification, et le SSO passe par un jeton de sécurité appelé jeton d'identité (ID token)5. Le NIST cite les deux comme exemples de protocoles de fédération, avec une assertion qui prend la forme d'un jeton d'identité OIDC ou d'une assertion SAML1.

Le SSO est-il moins sûr qu'un mot de passe par application ?

Il déplace le risque plus qu'il ne le supprime. Le salarié n'a plus de mot de passe à gérer pour chaque application1, mais un compte unique ouvre plusieurs services : si un attaquant en prend le contrôle, tous ceux qui l'acceptent sont exposés. Les pièges plus bas détaillent ce point.

Que protège la double authentification, et que ne protège-t-elle pas ?

Elle protège la connexion initiale. Elle ne protège pas contre un jeton ou un cookie déjà volé : l'accès direct par jeton annule l'effet d'un second facteur6, et les cookies de session peuvent contourner certains protocoles d'authentification multifacteur3.

1Comment ça marche1 min

Deux acteurs échangent des informations : le fournisseur d'identité, qui authentifie la personne, et l'application, qui fait confiance à ce qu'il affirme4. Le NIST appelle l'application « partie utilisatrice » (relying party) et nomme assertion le message du fournisseur d'identité qui la renseigne sur la personne1.

Avec SAML, Microsoft explique que l'application enregistre auprès du fournisseur d'identité une adresse de redirection et une adresse de métadonnées, qui permettent d'obtenir la clé de signature4. Avec OIDC, l'application récupère aussi un document de configuration public qui donne les adresses utiles et les clés publiques servant à vérifier la signature des jetons5. L'OWASP décrit pour SAML une réponse qui contient l'assertion signée numériquement avec la clé privée du fournisseur d'identité7.

Un jeton n'est pas un mot de passe : il atteste d'une authentification déjà faite. Pour SAML, MITRE indique une durée de vie par défaut d'une heure, modifiable dans le jeton8.

Dans la version 2017/2020 de ses lignes directrices, aujourd'hui remplacée, le NIST classe les assertions en trois niveaux. Au premier, l'assertion est signée par le fournisseur d'identité. Au deuxième, elle est aussi chiffrée pour l'application. Au troisième, l'utilisateur prouve en plus qu'il possède une clé liée à l'assertion1. La version SP 800-63C-4, datée de juillet 2025, remplace celle du 2 mars 20209 ; ces trois niveaux ne sont donc pas la règle actuelle1.

2Ce que vous faites1 min
  • Regardez l'adresse de la page de connexion avant de saisir un mot de passe. Des attaquants captent la session au passage, par exemple avec les outils evilginx2 et Muraena, utilisés dans des campagnes d'hameçonnage3.
  • Activez la double authentification sur votre compte principal, celui qui ouvre les autres applications. Compromettre un accès à la messagerie principale peut permettre d'atteindre les autres services par la procédure de mot de passe oublié6.
  • Déconnectez-vous sur un poste partagé. Les cookies de session restent souvent valides longtemps, même quand l'application n'est plus utilisée3. Chez Microsoft, la déconnexion met fin à la session de l'utilisateur5.
  • Lisez la fenêtre de demande d'autorisation avant de cliquer. Elle demande à l'utilisateur d'accorder des permissions à une application5.
  • Signalez toute demande de connexion ou d'autorisation que vous n'avez pas déclenchée, surtout après un message qui vous pousse à cliquer sur un lien : c'est ainsi qu'un attaquant fait accorder l'accès à son application2.
3Les pièges2 min

Les faux portails de connexion

Les cadres open source evilginx2 et Muraena recueillent des cookies de session par un proxy malveillant placé entre la victime et le vrai site3. Kali365 a obtenu des jetons d'accès et d'actualisation OAuth en poussant des victimes à valider une demande d'autorisation d'appareil lancée par l'attaquant, et en interceptant les sessions grâce à une infrastructure de proxy inversé2.

Le vol de jeton ou de session

Les jetons d'accès servent à faire des requêtes autorisées au nom d'un utilisateur6. Volés, ils remplacent le mot de passe : le groupe APT29 utilise des jetons volés pour accéder à des comptes sans mot de passe2. Ces accès par API sont difficiles à repérer, même côté fournisseur, car ils ressemblent à un usage normal6. Changer son mot de passe peut aussi ne pas suffire à les couper6. Les jetons d'actualisation permettent d'en obtenir de nouveaux sans interroger l'utilisateur2.

Les consentements OAuth abusifs

Un attaquant enregistre sa propre application auprès du serveur d'autorisation, puis envoie un lien d'hameçonnage pour que la cible lui accorde l'accès2. Une fois le jeton accordé, l'application peut obtenir un accès durable au compte, par exemple pour chercher dans la messagerie et lister les contacts26. Le groupe APT28 a utilisé des applications déguisées en « Google Defender », « Google Email Protection » et « Google Scanner » pour viser des utilisateurs de Gmail2.

Le compte unique, point de défaillance

Celui qui détient un certificat de signature SAML valide peut forger des jetons avec les droits et la durée qu'il choisit, et s'authentifier ainsi auprès de tous les services qui utilisent SAML 2.0 pour le SSO8. MITRE cite la compromission de SolarWinds, où le groupe APT29 a créé des jetons avec des certificats de signature SAML compromis8.

4Cas réels1 min

2012 : l'enveloppement de signature XML

L'OWASP rappelle que des vulnérabilités d'implémentations SAML liées aux attaques par enveloppement de signature XML ont été décrites en 20127. Parmi ses recommandations figure une validation sûre de la signature numérique7. Ce travail revient aux équipes informatiques, pas au salarié.

Fiche

Identifiant
CP-193
Aile
3. Protocoles et défense
Compétence Brain
Contrôler les accès (control_access)
Réflexe Brain
cr-025
Schéma
G3 · Coupe Anatomique
Langues
de, en, fr
Sources
9 sources vérifiées le 3 novembre 2026
Sources9 sources
  1. NIST, « NIST Special Publication 800-63C ». https://pages.nist.gov/800-63-3/sp800-63c.html (consulté le 3 novembre 2026)
  2. MITRE ATT&CK, « Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK® ». https://attack.mitre.org/techniques/T1528/ (consulté le 3 novembre 2026)
  3. MITRE ATT&CK, « Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK® ». https://attack.mitre.org/techniques/T1539/ (consulté le 3 novembre 2026)
  4. Microsoft, « How the Microsoft identity platform uses the SAML protocol - Microsoft identity platform ». https://learn.microsoft.com/en-us/entra/identity-platform/saml-protocol-reference (consulté le 3 novembre 2026)
  5. Microsoft, « OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform ». https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc (consulté le 3 novembre 2026)
  6. MITRE ATT&CK, « Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK® ». https://attack.mitre.org/techniques/T1550/001/ (consulté le 3 novembre 2026)
  7. OWASP, « SAML Security - OWASP Cheat Sheet Series ». https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html (consulté le 3 novembre 2026)
  8. MITRE ATT&CK, « Forge Web Credentials: SAML Tokens, Sub-technique T1606.002 - Enterprise | MITRE ATT&CK® ». https://attack.mitre.org/techniques/T1606/002/ (consulté le 3 novembre 2026)
  9. NIST, « SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions | CSRC ». https://csrc.nist.gov/pubs/sp/800/63/c/4/final (consulté le 3 novembre 2026)

Citer cet article

Brain, « Le SSO : SAML et OpenID Connect expliqués simplement », Cyberpedia, 2026. https://startbrain.io/cyberpedia/fr/articles/sso-saml-openid-connect/

BibTeX 
@misc{brain_cp193_fr_2026,
  author = {Brain},
  title = {Le SSO : SAML et OpenID Connect expliqués simplement},
  year = {2026},
  howpublished = {Cyberpedia},
  url = {https://startbrain.io/cyberpedia/fr/articles/sso-saml-openid-connect/},
  note = {CC BY 4.0}
}
Licence CC BY 4.0