SSO
Définition
Single Sign-On. Mécanisme qui permet à un utilisateur de se connecter une seule fois et d'accéder à plusieurs applications. Repose souvent sur SAML ou OpenID Connect en entreprise.
Comment ça marche
SSO (Single Sign-On) permet à un utilisateur de se connecter une seule fois et d'accéder à plusieurs applications sans ressaisir ses identifiants. Le principe : un fournisseur d'identité central (Okta, Azure AD, Google Workspace) valide l'utilisateur, et chaque application délègue la vérification à ce fournisseur. Techniquement, le SSO s'appuie sur des protocoles standardisés : SAML 2.0 pour l'historique entreprise, OpenID Connect (OIDC) pour le moderne, parfois Kerberos en interne. Quand un employé clique sur "Connexion" depuis votre SaaS, il est redirigé vers son IdP, s'authentifie, puis revient connecté chez vous.
À quoi ça sert
Le SSO résout trois problèmes simultanément. La productivité : un employé qui utilise 30 SaaS différents n'a plus à mémoriser 30 mots de passe. La sécurité : un seul système central renforcé (MFA, politique de mots de passe stricte) protège tous les accès. La conformité : quand l'audit IT vérifie qui a accès à quoi, on consulte un seul système, pas trente. Pour une entreprise de 500+ employés, ne pas avoir SSO est un cauchemar opérationnel et un risque sécurité. Pour un SaaS B2B qui vise ce marché, supporter SSO devient une exigence client systématique.
Les protocoles
SAML 2.0 reste le standard entreprise historique, basé sur XML, supporté par tous les IdP majeurs depuis 15 ans. OpenID Connect (OIDC) est l'équivalent moderne, basé sur OAuth 2.0 et JSON, plus simple à implémenter. SCIM (System for Cross-domain Identity Management) complète le tableau pour le provisioning automatique : créer/modifier/supprimer les comptes côté SaaS quand l'IT le fait côté IdP. Pour un SaaS B2B sérieux, on cible SAML + OIDC + SCIM, ce qui couvre 99% des demandes enterprise. Sur un produit moderne, on commence par OIDC, on ajoute SAML quand le marché le demande.
Quand l'utiliser
Le SSO devient indispensable dès qu'on vise des comptes enterprise (500+ employés). Pour les PME et startups, l'OAuth classique (Google, Microsoft) joue déjà le rôle de SSO et suffit largement. Sur un SaaS B2B en phase MVP, on commence par OAuth ; quand le premier prospect enterprise demande SAML SSO, on l'ajoute (typiquement avec WorkOS). Pour un SaaS B2C grand public, le SSO entreprise n'a pas de sens, on reste sur OAuth Google/Apple. Pour un outil interne dans une entreprise, on intègre directement avec l'IdP de l'entreprise dès le départ.
Les fournisseurs
Côté entreprise cliente, les IdP majeurs sont Okta (leader mondial, très technique, populaire chez les scale-ups US), Microsoft Entra ID (anciennement Azure AD, dominant chez les grands comptes Office 365), Google Workspace (PME et grandes entreprises Google), OneLogin et JumpCloud (alternatives plus accessibles). Côté SaaS qui veut supporter le SSO, on utilise WorkOS (premier choix pour les SaaS modernes), BoxyHQ Jackson (open-source), Auth0 Enterprise, Clerk Enterprise. Ces services encapsulent la complexité SAML/OIDC et offrent une API unifiée.
SSO vs MFA
On confond souvent SSO et MFA (Multi-Factor Authentication), mais ce sont deux mécanismes complémentaires. Le SSO réduit le nombre de connexions (un seul login pour tout). Le MFA renforce chaque connexion (mot de passe + code SMS, ou passkey). Idéalement, les deux marchent ensemble : on se connecte une seule fois (SSO) avec une authentification forte (MFA imposé par l'IdP). C'est ce que font les entreprises modernes : SSO Okta + MFA obligatoire au niveau Okta, et tous les SaaS héritent automatiquement de cette sécurité, sans avoir à implémenter MFA eux-mêmes.
Les pièges à éviter
Le piège du "SSO partial" : implémenter SAML mais sans SCIM, ce qui force les admins client à créer chaque compte à la main côté SaaS. On supporte SCIM pour vraiment offrir l'expérience attendue. Le piège du "SSO premium tax" : facturer le SSO comme option payante (souvent +50% du prix) écœure les clients enterprise, qui considèrent que c'est un acquis. On l'inclut dans le plan business standard. Le piège du "SSO lockout" : si l'IdP du client tombe, personne ne peut se connecter, y compris les admins. On garde une porte de secours (compte admin local d'urgence). Et tester SSO avec un seul IdP est insuffisant : Okta, Azure AD, Google Workspace ont des spécificités.