Single Sign-On (SSO)
Architecture d'authentification où un fournisseur d'identité unique émet les jetons donnant accès à de multiples applications, réduisant la surface d'identifiants mais concentrant le rayon d'impact.
Le Single Sign-On (SSO) est une architecture d’authentification dans laquelle un fournisseur d’identité (IdP) unique — Okta, Microsoft Entra ID, Google Workspace, Ping, JumpCloud — détient les identifiants de l’utilisateur et émet des assertions ou jetons de courte durée vers chaque application aval qu’il consulte. L’utilisateur s’authentifie une fois ; l’IdP atteste de son identité partout ailleurs.
Le SSO repose sur deux standards interopérables :
- SAML 2.0. Assertions XML, omniprésent en SaaS B2B, encore le protocole dominant pour les applications web d’entreprise.
- OpenID Connect (OIDC). Basé JSON/JWT, posé sur OAuth 2.0, défaut moderne pour les nouvelles applications et les flux mobile/SPA.
- Provisionnement just-in-time (JIT). La première connexion crée automatiquement le compte aval à partir des attributs de l’assertion SAML/OIDC.
- SCIM complète usuellement le SSO pour gérer le cycle de vie (création, mise à jour, déprovisionnement) — sans lui, le « SSO » laisse des comptes orphelins au départ d’un collaborateur.
L’argument sécurité du SSO est solide : un seul endroit où imposer la MFA, un seul mot de passe à faire tourner, un seul journal d’audit. Il réduit la surface d’identifiants qui alimente la réutilisation de mots de passe et le credential stuffing.
Mais le SSO concentre le rayon d’impact. Quand l’IdP est compromis — voir l’incident sur le système de support Okta en 2022, puis la brèche du support client Okta en 2023 — l’ensemble du SaaS connecté devient atteignable en un seul saut. Trois motifs que l’équipe sécurité doit surveiller :
- Force du facteur MFA côté IdP. Si l’IdP accepte push ou SMS, tout le parc hérite de cette faiblesse. Migrez l’IdP vers FIDO2 / passkeys avant les applications avales.
- Octrois OAuth depuis la session SSO. Une fois connecté à Google Workspace, l’utilisateur peut accorder à une application tierce des scopes étendus — le phishing OAuth contourne entièrement la MFA.
- Contournement SSO sur les apps héritées. Beaucoup de SaaS gardent une porte dérobée mot-de-passe local. Désactivez-la explicitement, application par application ; les auditeurs vérifient de plus en plus ce point.
Le SSO est nécessaire mais non suffisant. Traitez l’IdP comme infrastructure tier-zéro, instrumentez le flux de connexion, et associez-le à une supervision comportementale des applications avales.
Termes liés
- Authentification multi-facteur (MFA)Schéma d'authentification exigeant au moins deux facteurs indépendants — ce que l'on sait, possède ou est — pour vérifier un utilisateur et renchérir le vol d'identifiants.
- FIDO2 / PasskeysStandards d'authentification ouverts s'appuyant sur la cryptographie asymétrique liée au terminal pour offrir une connexion résistante au phishing — la réponse pratique à la fatigue MFA et au phishing adversary-in-the-middle.
- Octroi OAuthJeton d'accès qu'un utilisateur délivre à une application tierce via OAuth, donnant à cette application un droit permanent de lire ou écrire dans un SaaS — souvent au-delà du MFA, souvent à vie.
- Phishing OAuth / consent phishingAttaque qui amène l'utilisateur à accorder à une application tierce malveillante un accès OAuth persistant à sa messagerie, ses fichiers ou son workspace — contournant entièrement le MFA.
- Credential stuffingAttaque automatisée qui rejoue des paires identifiant/mot de passe issues de fuites tierces contre des services sans rapport, exploitant la réutilisation pour prendre le contrôle de comptes à grande échelle.