SSO

01 — DéfinitionQu'est-ce que le SSO ?

Le SSO, pour Single Sign-On, est un mécanisme qui permet à un utilisateur de s'authentifier une seule fois auprès d'un fournisseur d'identité central, puis d'accéder à toutes ses applications autorisées sans avoir à se reconnecter à chacune.

Le principe repose sur une architecture à trois acteurs :

• L'utilisateur qui cherche à accéder à une application.
• Le fournisseur d'identité (IdP, Identity Provider) qui authentifie l'utilisateur et atteste de son identité. Exemples : Microsoft Entra ID, Google Workspace, Okta.
• L'application (SP, Service Provider, ou Relying Party) qui fait confiance à l'IdP pour valider l'identité. Exemples : Salesforce, Slack, GitHub, votre ERP interne.

Quand un utilisateur tente d'accéder à une application, celle-ci le redirige vers l'IdP. Si l'utilisateur n'est pas déjà authentifié, il saisit ses identifiants une fois. L'IdP renvoie ensuite à l'application une assertion — un jeton cryptographique qui atteste de l'identité et, éventuellement, des droits associés. L'application accepte cette assertion et ouvre la session. Les applications suivantes bénéficient de la session IdP existante, sans saisie supplémentaire.

Le SSO n'est pas de la « sauvegarde de mot de passe ». C'est une architecture de confiance entre un fournisseur d'identité central et les applications qui acceptent ses jetons. La différence est essentielle pour la sécurité.

02 — MécaniqueLe déroulement d'une connexion SSO

Voici ce qui se passe concrètement quand un utilisateur se connecte à une application tierce via SSO.

1. L'utilisateur navigue vers app.example.com.
2. L'application détecte qu'aucune session n'est active et redirige vers l'IdP (login.entreprise.fr par exemple).
3. L'IdP vérifie s'il a une session active pour cet utilisateur.
   • Pas de session — l'IdP affiche la page de connexion. L'utilisateur saisit ses identifiants, éventuellement complétés par la MFA (TOTP, push, FIDO2). L'IdP crée une session.
   • Session active — l'IdP passe directement à l'étape suivante, sans saisie utilisateur.
4. L'IdP génère une assertion (un jeton signé cryptographiquement) contenant l'identité de l'utilisateur et des métadonnées (groupes, attributs).
5. Le navigateur est redirigé vers l'application avec l'assertion.
6. L'application vérifie la signature de l'assertion (elle fait confiance à la clé publique de l'IdP déjà connue).
7. L'application crée sa propre session utilisateur et affiche le contenu authentifié.

Quand l'utilisateur ouvre ensuite une autre application fédérée, les étapes 3 et suivantes se répètent mais sans saisie, puisque la session IdP est déjà active. C'est cette continuité qui donne l'impression d'un accès « automatique » après la première connexion.

03 — ProtocolesSAML, OIDC, OAuth

SAML 2.0 — le classique

Security Assertion Markup Language, standardisé en 2005. Basé sur XML, échange d'assertions signées entre IdP et SP. Très présent dans le monde de l'entreprise historique. Particulièrement adapté aux applications web traditionnelles. Points forts : très mature, bien outillé, excellente intégration dans les environnements Active Directory. Points faibles : XML verbeux, moins pratique pour les applications mobiles et les API modernes.

OpenID Connect (OIDC) — le moderne

Standardisé en 2014, construit au-dessus d'OAuth 2.0. Utilise JSON (JWT pour les tokens) et des flux adaptés au web moderne, aux applications mobiles et aux API. Devenu le standard de facto pour les nouvelles applications. Points forts : léger, flexible, excellent support mobile. Points faibles : écosystème d'implémentations variable en qualité, plus complexe à sécuriser correctement que SAML dans certains cas.

OAuth 2.0 — autorisation, pas authentification

OAuth 2.0 est un protocole d'autorisation, pas d'authentification. Il permet à une application d'accéder à des ressources au nom d'un utilisateur (lire vos contacts Google, publier sur LinkedIn). OIDC rajoute une couche d'authentification par-dessus OAuth 2.0. Confusion fréquente : OAuth seul n'est pas du SSO.

SCIM — provisioning complémentaire

System for Cross-domain Identity Management. Protocole pour synchroniser automatiquement les utilisateurs, groupes et attributs entre l'IdP et les applications. Essentiel pour l'onboarding et surtout l'offboarding propre des collaborateurs. Sans SCIM, les comptes obsolètes traînent dans les applications bien après le départ d'un salarié.

Kerberos et Active Directory — l'héritage

Pendant des décennies, le SSO interne en entreprise reposait sur Kerberos, utilisé dans Active Directory Windows. Toujours très présent sur les réseaux internes, complémentaire des protocoles web modernes. La fédération vers les applications cloud passe typiquement par un pont vers SAML ou OIDC (via ADFS, Entra ID Connect).

04 — AvantagesPourquoi déployer du SSO

Expérience utilisateur

• Une seule saisie de mot de passe par jour typiquement, au lieu d'une par application.
• Pas de fatigue d'authentification sur 30 applications SaaS différentes.
• Pas de réinitialisations multiples en cas d'oubli.
• Passage quasi invisible entre applications.

Sécurité globale

• Un seul point d'authentification à renforcer (MFA, FIDO2, Conditional Access) — au lieu de répliquer la sécurité sur chaque application.
• Suppression des mots de passe multiples qui sont typiquement réutilisés et faibles.
• Politique de mots de passe uniforme et appliquée systématiquement.
• Journalisation centralisée de toutes les authentifications — précieux pour le SOC.
• Offboarding fiable : désactiver l'identité centrale coupe l'accès à tout, immédiatement.
• Détection de comportements anormaux centralisée (Conditional Access, Risk-based Authentication).

Gouvernance et conformité

• Revue d'accès simplifiée — vue unique de qui accède à quoi.
• Attribution des droits par groupe ou rôle, synchronisé partout via SCIM.
• Logs centralisés et conformes aux exigences réglementaires (NIS2, DORA, ISO 27001).
• Audit facilité en cas d'incident.

Coût et support

• Réduction drastique des tickets « j'ai oublié mon mot de passe ».
• Moins de temps passé en onboarding/offboarding.
• Potentielle rationalisation des licences (vision unifiée des utilisateurs).

05 — RisquesLes faiblesses à connaître

Le SSO n'est pas une solution magique. Il concentre l'authentification sur un point unique, ce qui concentre aussi le risque.

Le compte IdP devient la clé universelle

Un compte IdP compromis ouvre accès à toutes les applications fédérées. C'est la faille conceptuelle majeure. La parade : protection maximale du compte IdP : authentification FIDO2 obligatoire, supervision renforcée, politique d'alerte sur tout signal inhabituel.

Golden SAML et assertions forgées

Si un attaquant obtient la clé privée signature de l'IdP (via compromission d'Active Directory, ADFS ou Entra ID), il peut forger des assertions SAML valides pour n'importe quel utilisateur et n'importe quelle application. C'est l'attaque dite « Golden SAML », documentée dans SolarWinds. Défense : protection extrême des clés IdP (HSM), rotation, surveillance des signatures inhabituelles.

Mauvaise implémentation côté application

Le SSO mal intégré côté application peut introduire des failles : vérification de signature incomplète, injection de header, acceptation d'assertions expirées. Les CVE sur des implémentations SAML et OIDC incorrectes sont régulières. Choisir des bibliothèques maintenues et tenues à jour est essentiel.

Pas de MFA côté application

Dans une architecture SSO, l'application fait confiance à l'IdP pour la force d'authentification. Si l'utilisateur a une MFA faible côté IdP, toutes les applications en héritent. Le pattern optimal est d'exiger FIDO2 côté IdP, avec Conditional Access qui impose une réauthentification forte pour les applications sensibles.

SSO partiel

Beaucoup d'environnements laissent cohabiter SSO et comptes locaux sur certaines applications. Résultat : l'offboarding ne coupe pas tous les accès, les mots de passe locaux restent réutilisés, la posture globale se dégrade. L'idéal est un SSO couvrant toutes les applications critiques, avec désactivation des comptes locaux.

Dépendance à l'IdP

Si l'IdP est hors ligne, plus personne ne peut se connecter à rien. Les grands IdP cloud (Entra ID, Okta, Google) sont très disponibles, mais des incidents existent (panne Okta 2022, incident Microsoft MFA 2021). Prévoir des procédures d'urgence : comptes break-glass, documentation accessible hors ligne, bascule de secours.

06 — MarchéLes principaux fournisseurs d'identité

Leaders cloud généralistes

• Microsoft Entra ID (ex-Azure AD) — domine largement le marché entreprise, intégration native Microsoft 365.
• Google Workspace — leader dans les entreprises centrées Google, bonne intégration SaaS.
• Okta — indépendant, apprécié pour sa neutralité et sa large bibliothèque d'intégrations.

Alternatives entreprise

• Ping Identity — orienté grands comptes, forte tradition SAML.
• OneLogin — racheté par One Identity, niche grandes entreprises.
• JumpCloud — plus orienté PME, cloud-native.
• ForgeRock — IAM complète, intégrée dans Ping Identity depuis 2023.

Open source

• Keycloak — référence open source, soutenu par Red Hat. Très complet, support SAML et OIDC, extensible.
• Authentik — alternative moderne, bonne UX, bonne documentation.
• Authelia — plus léger, souvent utilisé pour protéger des applications internes derrière un proxy inverse.

Niche et spécialisés

• Auth0 (Okta) — orienté développeurs et intégration applicative.
• Clerk, FusionAuth, Stytch — orientés applications SaaS, B2C et B2B2C.
• WSO2 Identity Server — open source et enterprise, bon support SAML/OIDC.

07 — DéploiementMettre en place le SSO en entreprise

08 — FAQQuestions fréquentes

Le SSO fonctionne-t-il avec des applications sur site ?

Oui. Les IdP modernes supportent la plupart des applications, qu'elles soient cloud, hybrides ou strictement on-premise. Les applications sur site peuvent utiliser SAML, OIDC, Kerberos, ou des passerelles comme les application proxies d'Entra ID. Les applications les plus anciennes peuvent nécessiter un reverse proxy qui ajoute la couche SSO.

SSO et passkey peuvent-ils coexister ?

Mieux que coexister : ils sont complémentaires. Le pattern optimal en 2026 est : passkey ou FIDO2 pour s'authentifier une fois auprès de l'IdP, puis SSO pour accéder à toutes les applications. La passkey protège l'authentification initiale (la porte d'entrée), le SSO optimise l'expérience sur tout l'écosystème applicatif.

Le SSO est-il obligatoire pour la conformité ?

Pas directement, mais de nombreuses réglementations et référentiels le recommandent fortement. NIS2 exige une gestion rigoureuse des identités et accès, ce qui en pratique impose une architecture SSO/IAM. ISO 27001 Annex A A.9 suit la même logique. Pour les grands comptes, le SSO est devenu un prérequis de facto.

Combien coûte le SSO ?

Varie largement. Entra ID est inclus dans les licences Microsoft 365 Business ou Enterprise à partir de certains plans. Google Workspace inclut son SSO. Okta facture à l'utilisateur et à la fonctionnalité (entre 2 et 15 €/mois/utilisateur selon les options). Les solutions open source (Keycloak, Authentik) sont gratuites mais demandent des ressources d'exploitation.

Certaines applications refusent-elles le SSO ?

Oui. Problème connu sous le nom de « SSO tax » : certains éditeurs SaaS réservent le support SSO à leurs plans les plus chers, parfois à un surcoût disproportionné. Le site sso.tax documente publiquement ces pratiques. Négocier l'inclusion du SSO dans les plans de base devient un argument contractuel important.