Chapitre 2 — SSO, SAML, OAuth & Fédération d'Identité

L'identité fédérée permet aux utilisateurs de s'authentifier une seule fois pour accéder à de multiples services. Ce module couvre SSO, SAML, OAuth 2.0, OpenID Connect, et les concepts de trust entre organisations.

SSO — Single Sign-On

Mémorisez ! SSO = une authentification, accès à plusieurs services. Avantage : moins de mots de passe à gérer. Risque : compromission du compte SSO = accès à tous les services. Mitiger avec MFA robuste.

Avec SSO, l'utilisateur s'authentifie une seule fois auprès d'un Identity Provider (IdP) et reçoit un token/ticket qui lui donne accès aux différents Service Providers (SP) sans se ré-authentifier.

Avantages : réduction de la fatigue des mots de passe, meilleure expérience utilisateur, gestion centralisée des identités.
Inconvénient : "single point of failure" — si le compte SSO est compromis, tous les services sont compromis. Contre-mesure : MFA obligatoire sur le SSO.

SAML — Security Assertion Markup Language

SAML est un standard XML pour l'échange d'assertions d'authentification et d'autorisation entre un IdP et des SPs. Utilisé principalement pour la fédération B2B et l'accès aux applications d'entreprise.

Flux SAML simplifié

Utilisateur tente d'accéder à une application (SP).
Le SP redirige vers l'IdP avec une SAML AuthnRequest.
L'utilisateur s'authentifie auprès de l'IdP (mot de passe + MFA).
L'IdP génère une assertion SAML signée numériquement.
L'assertion est renvoyée au SP via le navigateur de l'utilisateur.
Le SP vérifie la signature et accorde l'accès.

Exemple : Un employé clique sur Salesforce. Salesforce redirige vers Okta (IdP). L'employé s'authentifie avec son compte d'entreprise + TOTP. Okta envoie une assertion SAML à Salesforce qui accorde l'accès — sans que l'employé ait un compte Salesforce distinct.

OAuth 2.0 & OpenID Connect

Mémorisez ! OAuth 2.0 = autorisation (qu'est-ce que cette app peut faire en mon nom). OpenID Connect (OIDC) = authentification (qui je suis). OIDC est une couche d'identité construite au-dessus d'OAuth 2.0.

OAuth 2.0

Protocole d'autorisation (pas d'authentification). Permet à une application d'accéder à des ressources en votre nom, sans partager votre mot de passe.

Resource Owner : l'utilisateur.
Client : l'application qui demande l'accès.
Authorization Server : délivre les tokens (ex: Google, Microsoft).
Resource Server : l'API/service qui héberge les ressources.
Access Token : preuve d'autorisation, utilisée pour accéder aux ressources.
Refresh Token : permet d'obtenir un nouvel access token sans ré-authentification.

OpenID Connect (OIDC)

Ajoute l'authentification à OAuth 2.0 via un ID Token (JWT) qui contient des claims sur l'identité de l'utilisateur (sub, email, name, etc.).

Usage moderne : "Se connecter avec Google/Microsoft/GitHub" = OIDC. L'application reçoit un ID token prouvant l'identité + un access token pour accéder aux APIs.

Fédération d'Identité & Concepts Clés

Identity Provider (IdP) : organisation qui authentifie les utilisateurs et émet les assertions/tokens. Ex: Okta, Azure AD, Google Identity.
Service Provider (SP) : application ou service qui fait confiance à l'IdP pour l'authentification. Ex: Salesforce, ServiceNow, une app SaaS.
Trust Relationship : accord préalable entre IdP et SP — métadonnées échangées, clés publiques partagées.
Identity Federation : plusieurs organisations se font mutuellement confiance pour leurs assertions d'identité. Ex: un consultant d'une entreprise A accède aux ressources de l'entreprise B.
Transitive Trust : si A fait confiance à B et B fait confiance à C, alors A fait confiance à C. Risque : compromettre B compromet la confiance A→C.
SCIM (System for Cross-domain Identity Management) : protocole pour automatiser le provisionnement/déprovisionnement des comptes dans les SaaS (synchronise l'IdP avec les SPs).

Quiz — SSO, SAML, OAuth

1. Un développeur intègre "Se connecter avec Google" dans son application. L'utilisateur voit ses informations de profil dans l'app sans avoir créé de compte distinct. Quel protocole est principalement utilisé ?

SAML OAuth 2.0 seul OpenID Connect (OIDC) Kerberos

OIDC est utilisé pour l'authentification "Se connecter avec X". OAuth 2.0 gère l'autorisation (accès aux APIs Google). OIDC ajoute l'ID token qui contient les informations de profil de l'utilisateur.

2. Quelle est la différence fondamentale entre OAuth 2.0 et SAML ?

SAML utilise JSON, OAuth utilise XML OAuth est conçu pour l'autorisation d'API, SAML est conçu pour la fédération d'authentification d'entreprise OAuth est plus ancien et moins sécurisé que SAML SAML fonctionne uniquement sur mobile, OAuth uniquement sur desktop

SAML utilise XML et est conçu pour la fédération B2B et SSO d'entreprise. OAuth 2.0 utilise JSON/REST et est conçu pour autoriser l'accès aux APIs. OIDC combine OAuth (autorisation) + authentification. Les deux peuvent coexister.

3. Dans le contexte SSO, quel est le principal risque que le responsable sécurité doit atténuer ?

Trop de sessions simultanées La complexité de configuration des SPs Les utilisateurs oublient leur mot de passe SSO Compromission du compte SSO = accès à tous les services fédérés

SSO crée un "single point of failure" d'authentification. Contre-mesures : MFA fort (phishing-resistant de préférence), détection d'anomalies comportementales (UEBA), accès conditionnel basé sur le risque.

4. Dans le flux SAML, quel rôle joue l'assertion ?

C'est la preuve cryptographique signée par l'IdP affirmant que l'utilisateur est authentifié C'est le mot de passe chiffré de l'utilisateur C'est le token OAuth 2.0 pour accéder aux APIs C'est la requête envoyée par le SP à l'IdP

L'assertion SAML est un document XML signé numériquement par l'IdP, contenant des claims sur l'utilisateur (identité, attributs, permissions). Le SP vérifie la signature pour s'assurer qu'elle vient bien de l'IdP de confiance.

5. SCIM est utilisé pour :

Chiffrer les assertions SAML Analyser les journaux de connexion SSO Automatiser la synchronisation des comptes entre l'IdP et les SaaS (provisionnement/déprovisionnement) Générer des tokens OAuth à partir de Kerberos

SCIM (System for Cross-domain Identity Management) automatise la gestion des identités entre systèmes. Quand un employé rejoint (ou quitte) l'entreprise, SCIM propage automatiquement la création (ou la désactivation) de son compte dans tous les SaaS connectés.

6. Une entreprise A souhaite donner accès à ses ressources aux consultants de l'entreprise B, sans créer de comptes locaux pour eux. Quelle approche décrit cela ?

Account federation locale Fédération d'identité inter-organisations Provisionnement JIT via PAM Délégation de credentials TACACS+

La fédération inter-organisations (cross-organizational federation) permet à l'entreprise A de faire confiance à l'IdP de l'entreprise B. Les consultants s'authentifient avec leurs propres credentials — aucun compte local à gérer.

7. Dans OAuth 2.0, quel est le rôle du "Refresh Token" ?

Réinitialiser le mot de passe de l'utilisateur Authentifier l'utilisateur pour la première fois Chiffrer l'access token pour le transit Obtenir un nouvel access token expiré sans demander à l'utilisateur de se ré-authentifier

L'access token a une courte durée de vie (ex: 1h). Le refresh token (durée plus longue) permet à l'application d'obtenir un nouvel access token sans intervention de l'utilisateur. Si un refresh token est volé, un attaquant peut maintenir l'accès — il faut le révoquer.

8. Quelle est la principale différence entre SAML et OIDC en termes de format de token ?

SAML utilise des assertions XML ; OIDC utilise des JWT (JSON Web Tokens) SAML utilise des JWT ; OIDC utilise des assertions XML Les deux utilisent le même format XML Les deux utilisent uniquement des tokens opaques

SAML = XML (plus verbeux, adapté aux systèmes d'entreprise legacy). OIDC/OAuth = JSON et JWT (compact, adapté aux APIs REST, applications mobiles/SPA). JWT contient des claims en base64 et est signé (JWS) ou chiffré (JWE).

9. Le "transitive trust" dans la fédération d'identité signifie que :

Tous les tokens ont la même durée de validité L'authentification est toujours bidirectionnelle Si A fait confiance à B et B fait confiance à C, A peut hériter de la confiance envers C — avec les risques associés Les tokens sont automatiquement renouvelés entre partenaires

Le transitive trust étend la confiance à travers des chaînes d'organisations. Risque : si B est compromis, la chaîne A→B→C est brisée et C peut subir les conséquences. À gérer avec des politiques d'accès conditionnel et des révisions régulières.

10. Un utilisateur se connecte à son portail d'entreprise le matin et accède ensuite à 8 applications différentes (CRM, ERP, email, etc.) sans jamais redonner son mot de passe. Quelle technologie est derrière cela ?

Kerberos uniquement SSO basé sur SAML ou OIDC avec un IdP centralisé Des mots de passe stockés dans le navigateur VPN qui mémorise les credentials

C'est le SSO en action — l'utilisateur s'authentifie une fois auprès de l'IdP (Okta, Azure AD, etc.) et les 8 applications (SPs) acceptent les assertions/tokens sans demander de ré-authentification. Souvent basé sur SAML pour les apps d'entreprise ou OIDC pour les apps modernes.