--- id: CP-193 slug: sso-saml-openid-connect lang: fr title: "Le SSO : SAML et OpenID Connect expliqués simplement" description: 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. canonical_url: https://startbrain.io/cyberpedia/fr/articles/sso-saml-openid-connect/ markdown_url: https://startbrain.io/cyberpedia/fr/articles/sso-saml-openid-connect.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: "Brain, « Le SSO : SAML et OpenID Connect expliqués simplement », Cyberpedia, 2026. https://startbrain.io/cyberpedia/fr/articles/sso-saml-openid-connect/ (CC BY 4.0)" wing: 3 theme: control_access reflex: cr-025 schema: G3 updated: "2026-11-03" translations: fr: https://startbrain.io/cyberpedia/fr/articles/sso-saml-openid-connect/ en: https://startbrain.io/cyberpedia/en/articles/sso-saml-openid-connect-explained/ de: https://startbrain.io/cyberpedia/de/articles/sso-saml-openid-connect/ es: https://startbrain.io/cyberpedia/es/articles/sso-saml-openid-connect/ sources: - "n": 1 title: NIST Special Publication 800-63C publisher: NIST url: https://pages.nist.gov/800-63-3/sp800-63c.html accessed: "2026-11-03" - "n": 2 title: Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 3 title: Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1539/ accessed: "2026-11-03" - "n": 4 title: How the Microsoft identity platform uses the SAML protocol - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/saml-protocol-reference accessed: "2026-11-03" - "n": 5 title: OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc accessed: "2026-11-03" - "n": 6 title: "Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/001/ accessed: "2026-11-03" - "n": 7 title: SAML Security - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html accessed: "2026-11-03" - "n": 8 title: "Forge Web Credentials: SAML Tokens, Sub-technique T1606.002 - Enterprise | MITRE ATT&CK®" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1606/002/ accessed: "2026-11-03" - "n": 9 title: "SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions | CSRC" publisher: NIST url: https://csrc.nist.gov/pubs/sp/800/63/c/4/final accessed: "2026-11-03" --- # Le SSO : SAML et OpenID Connect expliqués simplement 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 chacune [1]. 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. ## 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 passe [2][3]. - 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. ## 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'application [1]. Le NIST précise que ce mécanisme dispense de détenir des identifiants séparés pour chaque service [1]. ### 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'application [4]. 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 SAML [1]. ### 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 application [1], 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 facteur [6], et les cookies de session peuvent contourner certains protocoles d'authentification multifacteur [3]. ## Comment ça marche Deux acteurs échangent des informations : le fournisseur d'identité, qui authentifie la personne, et l'application, qui fait confiance à ce qu'il affirme [4]. Le NIST appelle l'application « partie utilisatrice » (relying party) et nomme assertion le message du fournisseur d'identité qui la renseigne sur la personne [1]. 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 signature [4]. 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 jetons [5]. 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 jeton [8]. 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'assertion [1]. La version SP 800-63C-4, datée de juillet 2025, remplace celle du 2 mars 2020 [9] ; ces trois niveaux ne sont donc pas la règle actuelle [1]. ## Ce que vous faites - 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çonnage [3]. - 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ée [3]. Chez Microsoft, la déconnexion met fin à la session de l'utilisateur [5]. - Lisez la fenêtre de demande d'autorisation avant de cliquer. Elle demande à l'utilisateur d'accorder des permissions à une application [5]. - 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 application [2]. ## Les pièges ### 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 site [3]. 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 utilisateur [6]. Volés, ils remplacent le mot de passe : le groupe APT29 utilise des jetons volés pour accéder à des comptes sans mot de passe [2]. Ces accès par API sont difficiles à repérer, même côté fournisseur, car ils ressemblent à un usage normal [6]. Changer son mot de passe peut aussi ne pas suffire à les couper [6]. Les jetons d'actualisation permettent d'en obtenir de nouveaux sans interroger l'utilisateur [2]. ### 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ès [2]. 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 contacts [2][6]. Le groupe APT28 a utilisé des applications déguisées en « Google Defender », « Google Email Protection » et « Google Scanner » pour viser des utilisateurs de Gmail [2]. ### 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 SSO [8]. MITRE cite la compromission de SolarWinds, où le groupe APT29 a créé des jetons avec des certificats de signature SAML compromis [8]. ## Cas réels ### 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 2012 [7]. Parmi ses recommandations figure une validation sûre de la signature numérique [7]. Ce travail revient aux équipes informatiques, pas au salarié. ## 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) --- Source originale : Cyberpedia, l'encyclopédie publique de cybersécurité et d'IA publiée par Brain. Version canonique : https://startbrain.io/cyberpedia/fr/articles/sso-saml-openid-connect/ Vous pouvez reprendre ce texte librement sous licence CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), à condition de citer « Brain, Cyberpedia » avec un lien vers l'adresse ci-dessus.