SSO : définition - Single Sign-On expliqué en profondeur

Le Single Sign-On (SSO) est un mécanisme d'authentification qui permet à un utilisateur de s'identifier une seule fois pour accéder à plusieurs applications, services ou systèmes distincts sans ressaisir ses identifiants. Derrière cette définition simple se cachent des standards cryptographiques (SAML 2.0, OIDC, Kerberos), des flux de confiance complexes, des risques spécifiques (Golden SAML, consent phishing) et des choix d'architecture lourds. Ce guide explique ce qu'est vraiment le SSO, comment il fonctionne, et pourquoi il est devenu le socle de toute architecture identité moderne.

1. Définition précise du SSO

1.1 Formulation rigoureuse

Le SSO est un mécanisme d'authentification fédérée qui délègue la vérification d'identité à un composant central (l'Identity Provider, ou IdP) pour le compte de plusieurs services consommateurs (Service Providers, ou SP). Après une authentification réussie auprès de l'IdP, l'utilisateur obtient une assertion d'identité ou un token qu'il présente aux SPs successifs pour prouver qu'il est déjà authentifié.

L'utilisateur voit : une seule page de login, puis toutes les applications qui s'ouvrent sans demander de mot de passe.

L'architecture derrière : un IdP central, N services consommateurs, et une relation de confiance cryptographique entre eux.

1.2 Trois confusions fréquentes à éviter

• SSO ≠ même mot de passe partout. Avec le SSO, il n'y a pas de mot de passe stocké dans les applications cibles. Seul l'IdP connaît et vérifie le mot de passe.
• SSO ≠ Password Manager. Un gestionnaire de mots de passe remplit différents mots de passe sur différents sites. Le SSO élimine le besoin de mots de passe multiples.
• SSO ≠ gestion de session applicative. Le SSO résout l'authentification initiale ; la gestion de session dans chaque application reste indépendante (timeout, révocation).

1.3 Les bénéfices en une phrase

Le SSO permet à une organisation de centraliser la politique d'authentification (qui, quand, comment, avec quelle force), de réduire la fatigue utilisateur, de désactiver l'accès à toutes les apps en un clic, et de produire un journal d'audit unifié. Corollaire : les faiblesses se concentrent aussi en un point, qu'il faut défendre avec le plus grand soin.

2. Histoire et évolution du SSO

2.1 Avant le SSO - l'enfer des logins multiples

Années 1990-2000, typique d'une entreprise :

• Un login Unix pour la station de travail.
• Un login AD pour Windows et le file share.
• Un login mainframe.
• Un login ERP SAP.
• Des logins spécifiques pour chaque application métier.
• Des logins pour l'email, l'intranet, le CRM.

L'utilisateur entre 5 à 15 credentials différents par jour. Les post-its sous le clavier sont la règle. Les helpdesks passent 30 à 40 % de leur temps sur des réinitialisations de mot de passe.

2.2 Les premières tentatives - enterprise SSO

Kerberos (MIT, 1988) est la première réponse sérieuse. Protocole de ticket qui permet à un utilisateur authentifié d'obtenir des tickets pour accéder à divers services sans ressaisir son mot de passe. Adopté par Microsoft en 2000 pour Active Directory. Toujours au cœur de l'authentification Windows en 2026.

Enterprise SSO commercial (années 2000) : des outils comme IBM Tivoli Access Manager, Novell SecureLogin, ou Passlogix qui stockent les credentials des applications dans un coffre local et les rejouent automatiquement. Simulacre de SSO par automation, pas par fédération.

2.3 L'ère SAML - fédération entreprise

SAML 2.0 (OASIS, 2005) est le premier standard d'authentification fédérée basé sur XML. Pensé pour le web, les applications cross-domain, les relations B2B. Massivement adopté par les grandes entreprises et SaaS (Salesforce, Workday, ServiceNow, Office 365, Google Workspace).

2.4 L'ère OAuth + OIDC - fédération moderne

• OAuth 2.0 (IETF RFC 6749, 2012) : framework d'autorisation, pas d'authentification. Permet à une app tierce d'accéder à des ressources au nom d'un utilisateur sans recevoir son mot de passe.
• OpenID Connect (OIDC) (2014) : couche d'authentification construite sur OAuth 2.0, avec un ID token au format JWT. Adopté par Google, Facebook, Apple, Microsoft, et la quasi-totalité des IdP modernes.

En 2026, OIDC est devenu le standard de facto pour les nouvelles intégrations ; SAML reste dominant sur le legacy enterprise. Les deux coexistent durablement.

2.5 Les passkeys et l'avenir

FIDO2/WebAuthn + passkeys (2022+) introduisent une authentification sans mot de passe, utilisable dans les flows SSO. L'IdP authentifie l'utilisateur via passkey synchronisée ; les SPs reçoivent le token OIDC ou l'assertion SAML habituelle. Le SSO survit, mais le mot de passe derrière lui disparaît progressivement.

3. Architecture et composants

3.1 Identity Provider (IdP)

Le serveur central qui détient les comptes utilisateurs, gère l'authentification et émet des assertions/tokens. Exemples :

3.2 Service Provider (SP)

L'application ou service qui s'appuie sur l'IdP pour authentifier ses utilisateurs. Quelques exemples :

• SaaS : Salesforce, ServiceNow, Workday, Slack, GitHub, GitLab, Notion.
• Outils internes : applications métiers custom, GitOps, dashboards.
• Infrastructure : AWS console via SAML, GCP via Workspace, SSH via certificats signés.

Un SP ne stocke pas les mots de passe utilisateurs. Il stocke seulement les identifiants locaux (user ID) et la référence vers l'IdP.

3.3 Relation de confiance

Entre chaque IdP et chaque SP, une relation de confiance est établie par échange de métadonnées :

• Certificats de signature (l'IdP signe les assertions/tokens, le SP vérifie).
• URLs (endpoint de login, endpoint de logout, ACS - Assertion Consumer Service).
• Attributs mappés (email, nom, groupes envoyés par l'IdP au SP).
• Politiques (MFA requis, session lifetime).

Cette relation est unidirectionnelle en général : l'IdP fait autorité pour l'identité, le SP fait confiance à l'IdP.

3.4 Identity Broker (optionnel)

Composant intermédiaire qui agrège plusieurs IdPs pour les présenter comme un seul aux SPs. Utile pour :

• Fédérer des sous-organisations qui ont leur propre IdP.
• Permettre l'authentification sociale (Google, Facebook, Apple) en complément de l'IdP d'entreprise.
• Normaliser les tokens avant transmission.

Exemples : Keycloak, Auth0, Ping Access, Okta comme broker vers Azure AD.

4. Les standards principaux du SSO

4.1 SAML 2.0

Standard XML basé sur signatures cryptographiques. Encore dominant en entreprise.

Deux flows principaux :

• SP-initiated : l'utilisateur va directement sur l'application (SP), qui le redirige vers l'IdP pour authentification. Le plus courant et recommandé.
• IdP-initiated : l'utilisateur se connecte d'abord à un portail IdP, puis choisit une app dans une liste. Moins sécurisé (vulnérable au replay, risque d'IdP-spoofing).

Structure d'une assertion SAML simplifiée :

<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" 
           Version="2.0" 
           IssueInstant="2026-04-24T19:00:00Z">
  <Issuer>https://idp.example.com</Issuer>
  <Subject>
    <NameID>jean.dupont@example.com</NameID>
  </Subject>
  <AuthnStatement AuthnInstant="2026-04-24T18:55:00Z">
    <AuthnContext>
      <AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:MultiFactor
      </AuthnContextClassRef>
    </AuthnContext>
  </AuthnStatement>
  <AttributeStatement>
    <Attribute Name="email">
      <AttributeValue>jean.dupont@example.com</AttributeValue>
    </Attribute>
    <Attribute Name="groups">
      <AttributeValue>engineering</AttributeValue>
      <AttributeValue>admins</AttributeValue>
    </Attribute>
  </AttributeStatement>
  <Signature>...</Signature>
</Assertion>

L'assertion est signée avec la clé privée de l'IdP. Le SP vérifie la signature avec la clé publique (certificat échangé lors du setup).

4.2 OAuth 2.0 + OpenID Connect (OIDC)

Standard JSON + JWT, beaucoup plus léger et adapté au mobile et aux API modernes.

Tokens échangés :

• ID Token (OIDC) : JWT signé, contient l'identité de l'utilisateur. C'est ce qui authentifie.
• Access Token (OAuth 2.0) : permet d'accéder à des APIs au nom de l'utilisateur.
• Refresh Token : permet d'obtenir un nouvel access token sans réauthentifier.

Flow recommandé pour applications web modernes : Authorization Code Flow with PKCE.

1. L'application redirige l'utilisateur vers l'IdP avec un code_challenge.
2. L'utilisateur s'authentifie (password + MFA).
3. L'IdP redirige vers l'application avec un authorization_code.
4. L'application échange le code contre un ID Token + Access Token en envoyant le code_verifier.
5. L'application valide l'ID Token (signature, issuer, audience, exp).

Exemple d'ID Token (JWT décodé) :

{
  "iss": "https://idp.example.com",
  "sub": "jean.dupont@example.com",
  "aud": "app-crm-prod",
  "exp": 1719234000,
  "iat": 1719230400,
  "amr": ["pwd", "mfa"],
  "email": "jean.dupont@example.com",
  "name": "Jean Dupont",
  "groups": ["engineering", "admins"]
}

4.3 Kerberos

Protocole de ticket utilisé principalement dans les environnements Windows Active Directory, mais aussi Linux (MIT Kerberos, Heimdal).

Fonctionnement simplifié :

1. L'utilisateur s'authentifie au KDC (Key Distribution Center) avec son mot de passe.
2. Il reçoit un Ticket-Granting Ticket (TGT).
3. Pour accéder à un service, il présente le TGT au KDC qui lui retourne un Service Ticket pour ce service.
4. Il présente le Service Ticket au service, qui le valide.

Avantages : pas de mot de passe échangé avec les services, tickets à courte durée de vie, authentification mutuelle possible.

Limites : bien intégré en réseau interne AD, complexe hors LAN, vulnérabilités historiques bien documentées (Kerberoasting, Pass-the-Ticket, Golden Ticket, Silver Ticket).

4.4 Autres standards (moins fréquents)

• WS-Federation / WS-Trust : anciens standards Microsoft, sur le déclin.
• CAS (Central Authentication Service) : open source académique, utilisé dans des universités.
• LDAP bind : pas du SSO à proprement parler, mais utilisé comme backend d'authentification.

5. Les variantes de SSO

Toutes les implémentations ne couvrent pas les mêmes besoins.

5.1 Enterprise SSO (workforce)

SSO pour les employés et sous-traitants. Caractéristiques :

• IdP principal = Entra ID, Okta, Google Workspace, Ping.
• Fédération via SAML et OIDC.
• Intégration avec le provisionnement (SCIM) pour Joiner/Mover/Leaver.
• Politique MFA stricte, souvent FIDO2 hardware keys pour admins.
• Durée de session et conditional access.

5.2 Customer IAM (CIAM)

SSO pour les clients finaux d'un produit. Exigences différentes :

• Volumétrie massive (millions d'utilisateurs possibles).
• Self-service : inscription, récupération de mot de passe, gestion du profil.
• Social login (Google, Apple, Facebook, GitHub, etc.) en plus de l'authentification classique.
• RGPD strict sur les données personnelles.
• UX de login optimisée (pas trop de frictions).

Plateformes : Auth0, Amazon Cognito, Okta Customer Identity, Azure AD B2C, ForgeRock, Frontegg, Clerk (startups récentes).

5.3 Social Login

Cas particulier de CIAM : utiliser un compte Google/Facebook/Apple comme IdP pour se connecter à une application tierce. C'est du SSO "inter-organisations". Bien pour réduire la friction, à encadrer pour la privacy.

5.4 SSO mobile

Spécificités mobile : utilisation du navigateur système via AppAuth (iOS/Android) au lieu de WebView (vulnérable au phishing). Intégration avec les gestionnaires de mots de passe et les passkeys.

5.5 SSO machine-to-machine

Authentification entre services sans utilisateur humain :

• OAuth 2.0 Client Credentials grant : client_id + client_secret pour obtenir un token.
• Workload Identity Federation : JWT émis par la plateforme (Kubernetes, GitHub Actions, GitLab CI) échangé contre des credentials cloud.
• mTLS : authentification mutuelle par certificat.

6. Bénéfices du SSO

6.1 Sécurité

• Politique MFA centralisée : on configure MFA une fois sur l'IdP, elle s'applique à tous les SPs fédérés.
• Désactivation en un clic : un leaver perd accès à toutes les applications fédérées instantanément.
• Audit trail unifié : tous les événements d'authentification passent par l'IdP, exportés vers SIEM.
• Politique de mot de passe unique : complexité, rotation, historique gérés au niveau IdP.
• Phishing-resistant possible : FIDO2 sur l'IdP rend impossible le vol de credential même par phishing ciblé.

6.2 Productivité

• Un seul login par journée / session.
• Moins de tickets helpdesk (réinitialisations password).
• Onboarding accéléré : un nouveau salarié a accès à toutes ses apps dès création dans l'IdP.
• Autoservice : l'utilisateur peut voir ses apps, récupérer son compte sans intervention IT.

6.3 Gouvernance

• Access review centralisée : qui a accès à quoi, visible depuis l'IdP.
• Compliance : conformité RGPD, NIS 2, DORA, HDS facilitée par la centralisation.
• Certifications : SOC 2, ISO 27001 valorisent un IAM mature.

7. Risques et attaques spécifiques au SSO

7.1 Single point of failure

Si l'IdP tombe, toutes les applications fédérées deviennent inaccessibles. La disponibilité de l'IdP est critique :

• SLA 99,99 % minimum pour un IdP SaaS.
• Plan de continuité avec fallback local pour applications critiques (break-glass accounts).
• Multi-region deployment.

7.2 Compromission de l'IdP = compromission totale

Exemples historiques :

• Golden SAML (UCI, 2017) : un attaquant qui obtient la clé privée de signature SAML de l'IdP peut forger des assertions pour n'importe quel utilisateur, n'importe quel SP. Utilisé dans SolarWinds/SUNBURST (2020).
• Okta 2022 et 2023 : compromission du support et du sous-traitant exposant des tokens clients.
• Microsoft Storm-0558 (2023) : compromission d'une clé MSA signant des tokens OAuth, forge de tokens pour Exchange Online.

Mitigation : rotation régulière des clés, HSM (Hardware Security Module) pour clés critiques, monitoring des signatures produites.

7.3 Consent phishing

Attaque où un utilisateur est trompé pour autoriser une application OAuth malveillante à accéder à ses données. Le consentement est légitime techniquement (OAuth 2.0 consent flow), mais accordé à un mauvais acteur.

Mitigation : admin consent obligatoire sur les scopes sensibles, alertes sur nouvelles apps OAuth enregistrées, revue des apps accordées aux utilisateurs.

7.4 Session hijacking post-SSO

Une fois l'utilisateur authentifié, les cookies ou tokens de session sont des credentials de facto. Un attaquant qui les vole (infostealer, XSS, proxy man-in-the-middle) peut rejouer la session sans passer par MFA.

Mitigation : cookies Secure, HttpOnly, SameSite=Strict, durée courte, binding au device via token binding / DPoP.

7.5 SAML Response tampering

Si la vérification de signature SAML est mal implémentée côté SP, un attaquant peut modifier l'assertion (attribut email, groupes) avant qu'elle atteigne le SP. Historique de vulnérabilités : CVE-2018-1000620 (SSO libraries), CVE-2023-35116 (Jackson).

Mitigation : bibliothèques matures, validation stricte, canonicalisation XML correcte.

7.6 Open redirect post-SSO

Paramètre RelayState (SAML) ou redirect_uri (OAuth) mal contrôlé permet de rediriger l'utilisateur après login vers une URL attaquant, menant à phishing ou vol de token.

Mitigation : allowlist stricte des redirect_uri, validation côté IdP et SP.

7.7 MFA fatigue sur l'IdP

Attaque Uber 2022 : bombardement de notifications MFA push jusqu'à acceptation par l'utilisateur. L'IdP est le nouveau goulot.

Mitigation : number matching, auth methods policies, rate limiting, alertes.

8. Implémentation - checklist opérationnelle

8.1 Choix de l'IdP

Questions à trancher :

• Workforce, customer IAM, ou les deux ? Outils différents.
• Cloud, on-prem, hybrid ? Entra ID, Okta pour cloud ; Keycloak, PingFederate pour on-prem/hybrid ; Auth0, Cognito, Auth0 pour customer.
• Budget : Keycloak ou Authentik sont gratuits ; Okta et Entra peuvent coûter 6 à 15 EUR par utilisateur par mois.
• Écosystème existant : si Microsoft 365, Entra ID est naturel ; si Google Workspace, Workspace + Cloud Identity.
• Compliance : vérifier les certifications (SOC 2 Type II, ISO 27001, FedRAMP, HDS).

8.2 Intégration des applications

• Privilégier OIDC pour les nouvelles applications.
• SAML pour le legacy ou exigence partenaire.
• Toujours SP-initiated, jamais IdP-initiated si possible.
• Vérifier les attributs mappés : groupes, rôles, email, département.
• Tester le logout : SLO (Single Logout) fonctionne-t-il côté SP ?
• Tester les scénarios d'erreur : IdP down, certificate expired, utilisateur désactivé.

8.3 Provisioning via SCIM

System for Cross-domain Identity Management : standard de provisionnement automatique.

• Création automatique du compte dans l'app quand l'utilisateur est ajouté au groupe IdP.
• Mise à jour automatique lors des changements (département, rôle).
• Désactivation automatique à la sortie.

Sans SCIM, les comptes fantômes s'accumulent dans les SaaS.

8.4 Monitoring et audit

• Logs IdP exportés vers SIEM avec rétention minimum 1 an.
• Alertes sur : login impossible (géolocalisation), nouvelle OAuth app consentie, changement de groupe admin, MFA method changed, nouveau device enregistré.
• Dashboard de coverage : pourcentage d'apps en SSO vs local, pourcentage d'users en MFA.

8.5 Break-glass accounts

Un ou deux comptes d'urgence hors IdP, stockés physiquement en coffre, pour accéder aux systèmes critiques si l'IdP tombe. Audit strict de leur usage.

9. Anti-patterns fréquents

9.1 SSO sans MFA

Activer SSO sans imposer MFA sur l'IdP crée un single point of failure sans défense en profondeur. Inacceptable.

9.2 Laisser des logins locaux en parallèle

Apps configurées avec SSO et login local activé. Les attaquants contournent le SSO en utilisant le login local. Désactiver strictement les comptes locaux dans chaque SP après migration.

9.3 SCIM non configuré

SSO activé mais provisioning manuel : création de comptes oubliée, désactivation qui traîne, privilèges obsolètes.

9.4 Trop d'apps sans SSO

"On migrera plus tard." Plus tard ne vient jamais. Objectif : 100 % des applications critiques en SSO dans les 6 mois qui suivent la mise en place de l'IdP.

9.5 Certificats SAML expirés

Les certificats de signature SAML expirent (typiquement 1-3 ans). Sans rotation planifiée, les intégrations cassent brutalement. Mitigation : calendrier de rotation, alertes 90 jours avant expiration.

9.6 OAuth apps sans revue

Des utilisateurs consentent à toutes sortes d'applications tierces au fil du temps. Sans revue, la surface d'attaque grandit silencieusement. Mitigation : inventaire trimestriel, révocation des apps inutilisées.

10. Mesurer la maturité SSO

Indicateurs pertinents :

11. Parcours d'implémentation SSO - 6 mois

Mois 1 - choix et setup

• Inventaire des applications (critiques, non critiques).
• Choix de l'IdP.
• Setup initial : tenant, politiques MFA, groupes.
• Pilote sur 2-3 applications.

Mois 2-3 - première vague

• Migration des 10-15 applications les plus utilisées.
• Activation SCIM.
• Documentation, formation des admins.
• Ajustement des politiques selon le feedback.

Mois 4-5 - élargissement

• Migration des applications restantes.
• Désactivation des logins locaux dans les SPs migrés.
• Mise en place du monitoring SIEM.
• Break-glass accounts configurés.

Mois 6 - consolidation

• Audit complet : applications manquantes, comptes orphelins, OAuth apps.
• Passage à MFA phishing-resistant (FIDO2) sur admins.
• Politique conditional access mature.
• Mesure des métriques de maturité.

12. Le futur du SSO

12.1 Passwordless

Mouvement fort depuis 2022. L'IdP authentifie via passkeys FIDO2 ; le mot de passe disparaît. Bénéfices : résistance phishing totale, fin de la fatigue utilisateur, moins de charge helpdesk.

12.2 Continuous authentication

Au-delà du login initial, l'IdP (ou un agent endpoint) évalue en continu le risque de la session : changement de comportement, device compromis détecté par EDR, géolocalisation incohérente. Déclenche re-authentification ou coupure.

12.3 Decentralized identity

Standards W3C Verifiable Credentials et DIDs (Decentralized Identifiers). L'utilisateur porte ses credentials vérifiables sans IdP central. Early stage en 2026, adoption limitée aux cas gouvernementaux et identité citoyenne (e-ID EU).

12.4 ITDR intégré

Les IdP modernes intègrent de plus en plus de capacités de détection (Okta ITP, Microsoft Defender for Identity, Crowdstrike Falcon Identity Protection). La frontière entre IdP et SIEM s'estompe.

13. Verdict et posture Zeroday

Le SSO n'est plus un luxe ni un projet d'amélioration : c'est une brique fondamentale de toute architecture sécurité moderne. Sans SSO, aucune posture Zero Trust n'est possible ; chaque application reste un silo avec ses propres faiblesses.

Pour un ingénieur qui se forme : maîtriser OIDC, SAML, SCIM, et un IdP principal (Okta, Entra, Keycloak) est une compétence directement monétisable. Les profils IAM/SSO sont rares et bien payés, la demande croît plus vite que l'offre.

Pour une organisation : investir dans un IdP et y migrer toutes les applications est le projet sécurité au meilleur ratio coût/impact. 90 % des bénéfices de Zero Trust s'appuient sur un SSO mature. Le reste (micro-segmentation, ITDR, CIEM) ne compense jamais un IAM faible.

Pour approfondir : pourquoi l'identité est centrale en cybersécurité pour le contexte stratégique, IAM expliqué simplement pour le volet cloud, qu'est-ce qu'un ingénieur IAM pour le parcours métier, gestion de session sécurisée pour la couche applicative qui consomme les tokens SSO.