Authentification Unique (SSO)

L’authentification unique (SSO) permet aux utilisateurs de s’authentifier une seule fois et d’accéder à plusieurs applications sans ressaisir leurs identifiants. Le SSO améliore à la fois la sécurité (moins de mots de passe, moins de fatigue de connexion) et l’expérience utilisateur (un clic pour accéder aux applications).

Protocoles SSO

SAML 2.0 vs OIDC vs Kerberos

Flux SSO SAML 2.0

Flux initié par le fournisseur de service (SP)

1. Utilisateur tente d'accéder à l'application (SP)
2. SP génère une AuthnRequest SAML
3. SP redirige le navigateur vers l'IdP avec AuthnRequest
4. IdP authentifie l'utilisateur (nom/mot de passe + MFA si requis)
5. IdP génère une assertion SAML (signée, optionnellement chiffrée)
6. IdP redirige le navigateur vers l'ACS (Assertion Consumer Service) du SP
7. SP valide l'assertion (signature, horodatage, audience)
8. SP crée une session locale et donne accès à l'utilisateur

Flux initié par le fournisseur d’identité (IdP)

1. L'utilisateur se connecte d'abord au portail IdP (Okta/Azure AD)
2. IdP affiche les applications disponibles
3. L'utilisateur clique sur une application
4. IdP génère une assertion SAML et la POSTe vers l'ACS du SP
5. SP valide l'assertion et crée une session
6. L'utilisateur accède à l'application

Flux SSO OIDC

1. Application (RP - Relying Party) redirige vers l'IdP (OP - OpenID Provider)
2. OP authentifie l'utilisateur
3. OP redirige vers le RP avec un code d'autorisation
4. RP échange le code contre un ID Token (JWT) et un Access Token
5. RP valide l'ID Token (signature, nonce, aud, exp)
6. RP extrait les claims utilisateur (sub, email, name) de l'ID Token
7. RP crée une session locale

Types de Jetons SSO

Modèles de Déploiement SSO

IdP Cloud comme point central

Architecture la plus courante pour les organisations modernes :

                    ┌──────────────────┐
                    │   IdP Cloud       │
                    │  (Okta/Azure AD)  │
                    └────┬──────┬──────┘
                         │      │
              ┌──────────┘      └──────────┐
              │                             │
         ┌────┴────┐                  ┌────┴────┐
         │  Apps   │                  │  Apps   │
         │  Cloud  │                  │  Sur    │
         │  SaaS   │                  │  Site   │
         └─────────┘                  └─────────┘

SSO pour applications Legacy

Les applications legacy sans support SAML/OIDC nécessitent des adaptateurs :

Risques de Sécurité SSO

Points Clés à Retenir

• Les trois protocoles SSO principaux sont SAML 2.0 (XML, entreprise, fédération B2B), OIDC (JSON/JWT, moderne, mobile, API) et Kerberos (binaire, Windows natif, réseau) — le choix dépend du type d’applications et de l’infrastructure existante
• Les flux SSO SAML 2.0 incluent le flux initié par le SP (l’utilisateur accède d’abord à l’application) et le flux initié par l’IdP (l’utilisateur part du portail IdP) — le flux initié par le SP est le plus courant
• OIDC est le protocole SSO moderne recommandé pour les nouvelles applications — plus simple que SAML, meilleur support mobile et API, et compatible avec les architectures microservices
• Les applications legacy sans support SAML/OIDC nécessitent des proxies d’authentification (PingAccess, Azure AD App Proxy) ou des agents/plugins pour intégrer le SSO
• Le SSO concentre le risque : la compromission de la session IdP donne accès à toutes les applications — la liaison de session, les durées de session courtes et la MFA renforcée sont des mitigations essentielles
• La déconnexion unique (SLO) est notoirement difficile à implémenter correctement — testez rigoureusement tous les scénarios de déconnexion, en particulier dans les architectures SAML complexes avec de multiples SP