Qu'est-ce que Single Sign-On (SSO) ?

Qu'est-ce que Single Sign-On (SSO) ?

Single Sign-On (SSO) est un schéma d'authentification où un utilisateur se connecte une fois avec un seul jeu d'identifiants et accède à plusieurs applications connectées sans avoir à se reconnecter. En coulisses, un identity provider (IdP) — Okta, Microsoft Entra ID, Google Workspace, Auth0 — vérifie l'utilisateur, et un service provider (SP) — Slack, Salesforce, GitHub, votre app interne — accepte le token de vérification de l'IdP au lieu de demander un mot de passe.

SSO domine en entreprise : un employé typique touche 10-30 apps SaaS par jour, et leur demander de se connecter à chacune séparément est un désastre de productivité + un désastre de sécurité de réutilisation de mot de passe. Avec SSO, l'utilisateur se connecte à l'IdP une fois en début de journée ; chaque app connectée accepte cette authentification pour le reste de la session.

Comment SSO fonctionne réellement

Le flux de haut niveau est le même entre protocoles, même si les détails d'implémentation diffèrent :

1. L'utilisateur clique "Se connecter" sur le SP (l'app qu'il veut utiliser).
2. Le SP redirige l'utilisateur vers l'IdP avec une demande : "merci d'authentifier cet utilisateur pour moi".
3. L'IdP authentifie l'utilisateur — vérifie les identifiants, peut aussi imposer MFA, politiques d'accès conditionnel ("uniquement sur appareils gérés"), limites de session.
4. L'IdP émet un token — une assertion signée cryptographiquement qui dit "cet utilisateur est authentifié, et voici son identité (email, nom, appartenances à des groupes)".
5. L'IdP redirige l'utilisateur vers le SP avec le token.
6. Le SP valide la signature du token en utilisant la clé publique de l'IdP, puis fait confiance à ce que l'utilisateur est qui l'IdP dit qu'il est. Le SP crée une session locale.

L'utilisateur vit cela généralement comme une seule redirection navigateur — il clique sur "Se connecter avec Okta", voit brièvement la page IdP (ou pas, s'il est déjà connecté), et atterrit dans l'app déjà authentifié. Temps total écoulé : 1-2 secondes.

Les 3 principaux protocoles SSO (SAML, OIDC, OAuth)

SAML 2.0

Le grand-père du SSO entreprise, ratifié en 2005. SAML utilise des assertions au format XML échangées entre IdP et SP, signées avec des certificats X.509. C'est verbose, complexe à déboguer (XML encodé en base64 multi-ligne dans des paramètres d'URL ou des bodies POST), mais solide comme un roc et omniprésent en entreprise. Si une app SaaS dit "SSO supporté", elle veut presque sûrement dire SAML 2.0. Slack, Salesforce, AWS, Workday — tous SAML.

OpenID Connect (OIDC)

Le successeur moderne, construit sur OAuth 2.0 et JSON Web Tokens (JWTs). OIDC alimente "Se connecter avec Google", "Se connecter avec Apple", "Se connecter avec Microsoft". Basé JSON, plus simple à implémenter, bien supporté dans les bibliothèques d'auth modernes. Les nouveaux produits SaaS commencent avec OIDC et ajoutent SAML plus tard pour les clients entreprise qui insistent.

OAuth 2.0 (techniquement pas SSO)

OAuth est un framework d'autorisation — "cette app peut-elle accéder aux données de cet utilisateur ?" — pas strictement un framework d'authentification. Mais il est couramment confondu avec SSO parce que le même flux basé sur redirection est utilisé. "Se connecter avec GitHub" utilise OAuth : l'app obtient un token pour appeler l'API GitHub en tant qu'utilisateur, et déduit l'identité de cela. OIDC ajoute des claims d'identité standardisés au-dessus d'OAuth, ce qui en fait du vrai SSO.

Service Provider Initiated vs Identity Provider Initiated

Les connexions SSO démarrent à un de deux endroits :

• SP-initié : L'utilisateur va d'abord à https://app.example.com, clique Se connecter, est redirigé vers l'IdP, revient. C'est la grande majorité des flux du monde réel.
• IdP-initié : L'utilisateur démarre dans le lanceur d'app de l'IdP (ex. tableau de bord Okta), clique sur la tuile SP. L'IdP génère une assertion non sollicitée et la POST au SP, qui connecte l'utilisateur directement. Pratique mais plus complexe d'un point de vue sécurité — un SP doit accepter des assertions qu'il n'a pas demandées.

La plupart des apps SaaS SAML supportent les deux. OIDC est essentiellement uniquement SP-initié par conception.

Pourquoi SSO améliore la sécurité (de manière contre-intuitive)

On a l'impression que "un seul login pour tout" devrait rendre le rayon d'explosion d'un identifiant volé plus grand. En pratique, c'est l'inverse :

• Application centralisée du MFA. Appliquer le MFA sur 30 apps individuelles est impossible — certaines apps ne le supportent pas, d'autres ont des implémentations faibles. Avec SSO, vous appliquez un MFA fort à l'IdP, et chaque app connectée en bénéficie.
• Un seul endroit pour révoquer l'accès. Quand un employé part, vous désactivez son compte IdP une fois et il perd immédiatement l'accès à chaque app connectée. Sans SSO, vous supprimeriez des comptes à 30 endroits (et en oubliant certains).
• Plus de réutilisation de mots de passe. Les utilisateurs avec des mots de passe séparés pour 30 apps les réutilisent. SSO élimine le problème de réutilisation à la source — l'utilisateur n'a qu'un seul mot de passe à gérer.
• Piste d'audit en un seul endroit. Activité de connexion, défis MFA, tentatives échouées — tout visible dans les logs de l'IdP. Sans SSO, les données d'audit sont fragmentées entre 30 fournisseurs.

Gotchas SSO courants

• Just-in-time (JIT) provisioning. Beaucoup d'apps SaaS SAML créent des enregistrements utilisateur lors de la première connexion SSO. Si votre IdP inclut les appartenances à des groupes dans l'assertion, le SP peut aussi assigner des rôles automatiquement. Sans JIT, un admin crée chaque utilisateur manuellement avant qu'il puisse se connecter — ok pour les petites équipes, douloureux à l'échelle.
• Mappage de claims de groupe. L'IdP envoie généralement les appartenances à des groupes dans l'assertion. Le SP doit mapper ces groupes à des rôles locaux. Les mappages de groupe mal configurés sont la source #1 de tickets "pourquoi je ne suis pas admin ?" après une migration SSO.
• Décalage d'horloge. Les assertions SAML ont des timestamps de validité NotBefore et NotOnOrAfter. Si les horloges de l'IdP et du SP diffèrent de plus que le skew configuré (généralement 60-300 secondes), l'authentification échoue. Synchronisez tout via NTP.
• Rotation de certificats. SAML signe les assertions avec des certs X.509 qui expirent (généralement tous les 1-3 ans). Oublier de faire tourner les certs avant qu'ils n'expirent fait tomber SSO à 03:00 un mardi. Les rappels calendrier sont obligatoires.
• Logout SP-initié vs single logout. Se déconnecter du SP ne déconnecte pas nécessairement de l'IdP ou des autres SPs connectés. Single Logout (SLO) est désordonné en pratique et beaucoup de fournisseurs ne l'implémentent pas complètement. En entreprise, les utilisateurs ferment souvent simplement le navigateur.
• Désaccords de durée de session. Si l'IdP donne une session de 12 heures mais que le SP impose des sessions d'1 heure, les utilisateurs sont re-promptés constamment même s'ils sont "déjà connectés". Alignez les durées soigneusement.

SSO vs Federated Identity vs OAuth — qui est qui ?

Ces trois termes s'emmêlent. Désambiguïsation rapide :

• SSO (Single Sign-On) : Pattern d'expérience utilisateur — une connexion, plusieurs apps. Ne dit rien de comment c'est implémenté.
• Federated identity : La capacité technique pour un IdP et un SP de se faire confiance mutuellement à travers les frontières organisationnelles. SSO requiert généralement la federated identity ; la federated identity peut aussi permettre d'autres choses (ex. partage d'attributs utilisateur).
• OAuth 2.0 : Un protocole d'autorisation (déléguer l'accès aux données). Utilisé comme bloc de construction pour OIDC, mais seul il n'établit pas d'identité.
• OIDC : Une couche d'authentification au-dessus d'OAuth. Ajoute un ID token avec des claims d'identité standardisés.

FAQ : Single Sign-On (SSO)

Quelle est la différence entre SSO et gestionnaires de mots de passe ?

Un gestionnaire de mots de passe stocke des identifiants séparés pour chaque app et les remplit automatiquement — l'utilisateur a toujours 30 mots de passe différents, juste tapés automatiquement. SSO remplace les 30 mots de passe par une connexion IdP : chaque app fait confiance à la vérification de l'IdP, aucun mot de passe par app n'existe. SSO est plus sécurisé (pas de réutilisation possible) mais requiert que chaque app supporte un protocole SSO.

Les petites équipes peuvent-elles utiliser SSO sans payer des prix entreprise ?

Oui — Google Workspace et Microsoft 365 incluent OIDC SSO pour beaucoup d'apps SaaS sans coût supplémentaire. Auth0 a un palier gratuit pour moins de 7 000 utilisateurs. Beaucoup d'IdPs open source (Keycloak, Authentik) sont gratuits à auto-héberger. Les barrières de coût pour SSO ont chuté drastiquement depuis 2020.

SAML est-il toujours pertinent ou devrais-je utiliser uniquement OIDC ?

Pour les nouvelles intégrations, OIDC si les deux côtés le supportent — plus simple, basé JSON, plus facile à déboguer. Pour SaaS entreprise, SAML est toujours requis car la plupart des IdPs et la plupart des catalogues SaaS entreprise mènent avec SAML. Prévoyez les deux : implémentez OIDC pour les inscriptions self-service et SAML pour les contrats entreprise.

Qu'est-ce que la SSO Tax ?

La "SSO tax" est la pratique des fournisseurs SaaS de facturer significativement plus pour le support SSO — parfois en poussant les clients vers des paliers entreprise uniquement pour obtenir SSO. Il y a un retour de bâton de l'industrie (sso.tax trace les fournisseurs qui font cela). Certains fournisseurs ont répondu en incluant SSO dans des paliers plus bas ; beaucoup non.

Qu'est-ce que SCIM et comment cela se relie-t-il à SSO ?

SCIM (System for Cross-domain Identity Management) automatise le provisioning et déprovisioning d'utilisateurs entre l'IdP et les SPs. SSO gère l'authentification ; SCIM gère "crée cet utilisateur quand il est ajouté à l'IdP, supprime-le quand il est retiré". Ensemble, SSO + SCIM est le standard d'or pour SaaS entreprise géré.

Que se passe-t-il avec SSO si l'IdP tombe ?

Les utilisateurs ne peuvent se connecter à rien. C'est pourquoi la disponibilité de l'IdP est critique. La plupart des IdPs publient des SLAs de 99,99% ; certaines entreprises gèrent un IdP de secours pour failover. Pour les apps super critiques, gardez au moins un compte admin local qui contourne SSO pour un accès d'urgence.

Comment LoadFocus s'intègre avec SSO

LoadFocus supporte SAML 2.0 et OIDC SSO sur ses plans Enterprise. Connectez votre IdP (Okta, Microsoft Entra ID, Google Workspace, Auth0) une fois ; provisionnez les membres d'équipe via les appartenances à des groupes de votre IdP ; révoquez l'accès centralement quand quelqu'un part. Configurez SSO depuis vos paramètres de compte — les instructions par IdP sont dans les docs.