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

Ce qu’il faut retenir du SSO : 

• Le Single Sign-On (SSO) est un mécanisme d’authentification fédérée. Il permet à un utilisateur de se connecter une seule fois pour accéder à plusieurs applications ou sites web de confiance.
• Le SSO s’appuie sur SAML, OAuth 2.0/OIDC ou Kerberos pour fédérer les identités et les accès via un annuaire central (AD/LDAP ou cloud).
• 25 % à 40 % de réduction des appels au help desk liés aux mots de passe oubliés génèrent jusqu’à 1,9 M $ d’économies annuelles pour 500 utilisateurs. Ce gain libère les équipes IT pour des tâches à plus forte valeur ajoutée.
• Il permet d’hybrider les applications legacy et d’automatiser le provisioning (SCIM) pour optimiser le cycle de vie des comptes. Elle réduit les risques de compromission et facilite la détection d’accès anormaux.
• Le point de défaillance unique nécessite une haute disponibilité, un plan de secours (comptes d’urgence, fournisseur d’identité secondaire) et une surveillance active des journaux. Il faut aussi maintenir les correctifs à jour et former les utilisateurs au phishing.

L’authentification unique, souvent désignée par l’acronyme SSO (Single Sign-On) est une méthode d’authentification qui permet aux utilisateurs d’accéder de façon sécurisée à plusieurs applications et services en utilisant un seul identifiant et un seul mot de passe. 

En d’autres termes, un utilisateur saisit ses identifiants (nom d’utilisateur et mot de passe) une seule fois sur un portail de connexion centralisé, puis obtient l’accès à une multitude de services sans avoir à se reconnecter à chaque fois. Cette simplification du processus de connexion est aujourd’hui importante pour les entreprises comme pour les particuliers : chacun de nous aurait en moyenne près de 170 mots de passe à gérer pour ses comptes personnels en 2024, et 80 à 90 mots de passe supplémentaires liés à son travail. Face à cette profusion d’identifiants à retenir, le SSO apparaît comme une solution pour réduire les mots de passe à mémoriser et accéder de façon sécurisée aux outils en ligne, sans compromis sur la sécurité.

Nous vivons à l’ère du « tout-numérique » où chaque service de messagerie, applications SaaS professionnelles, réseaux sociaux, services cloud, exige une authentification. Cela conduit les utilisateurs à jongler avec des dizaines (voire des centaines) de mots de passe, ce qui engendre une fatigue des mots de passe et des pratiques risquées (post-it sur l’écran, réutilisation d’un même mot de passe, partage d’identifiants par email…). 

En entreprise, les conséquences sont tangibles : 25 à 40 % des appels au support technique (help desk) concernent des problèmes de mots de passe (oubli, réinitialisation) selon Forrester, représentant un coût de support informatique non négligeable.

À l’échelle d’une organisation, les soucis de mots de passe feraient perdre environ 345€ de productivité par employé et par an. C’est dans ce contexte qu’intervient l’authentification unique, dont l’objectif est de centraliser les accès et d’alléger la charge liée aux multiples connexions. 

Une solution SSO offre un portail de connexion unifié (une authentification “carrefour” en quelque sorte) où l’utilisateur s’authentifie une seule fois pour accéder ensuite à l’ensemble des applications autorisées. Nous allons voir comment fonctionne le SSO, quels en sont les avantages (mais aussi les limites et risques de sécurité à connaître), les différents types d’implémentation du SSO, ainsi que des conseils pour mettre en place cette technologie dans une organisation.

Qu’est-ce que le Single Sign-On (authentification unique) ?

Le Single Sign-On (SSO), ou authentification unique, est un mécanisme d’authentification fédérée dans lequel un utilisateur n’a besoin de se connecter qu’une seule fois pour obtenir l’accès à plusieurs applications ou sites web de confiance. Lorsqu’une session SSO est initiée, l’utilisateur fournit ses informations d’identification (identifiant unique et mot de passe unique) sur une interface centrale. Une fois cette identité vérifiée, le SSO va propager cette authentification aux autres services sans exiger de nouvelle saisie du mot de passe. Cela est possible grâce à une relation de confiance préétablie entre le service d’authentification central (souvent appelé fournisseur d’identité) et les applications cibles. Ainsi, si votre entreprise utilise un SSO, vous pourriez par exemple vous connecter une seule fois le matin et avoir ensuite un accès instantané à votre messagerie, votre intranet RH, votre outil CRM, vos applications cloud et autres services, sans ressaisir vos identifiants pour chacun.

Cette méthode repose sur la fédération d’identité : votre identité numérique (vos attributs d’utilisateur) est partagée de façon sécurisée entre différents systèmes ayant instauré une relation de confiance. 

Si un système A (le fournisseur d’identité) a authentifié l’utilisateur, il en informe les systèmes B, C, etc. (les applications) qui acceptent cette authentification provenant de A. L’authentification unique devient alors un carrefour qui unifie vos accès aux services. 

Cela améliore non seulement l’expérience utilisateur (plus besoin de retenir une multitude de mots de passe ni de perdre du temps à répéter les connexions), mais aussi la sécurité des mots de passe : l’utilisateur étant moins tenté de réutiliser des mots de passe faciles ou de les noter partout, le SSO contribue à une meilleure hygiène de sécurité.

Bon à savoir : Un exemple courant de SSO est l’utilisation d’un compte central (par ex. votre compte Google ou Microsoft Azure AD) pour accéder à diverses applications professionnelles. Vous saisissez vos identifiants Google une fois, et derrière, grâce au SSO, des applications comme Salesforce, Slack ou Asana vérifient auprès de Google que vous êtes bien authentifié et vous laissent entrer sans vous demander de mot de passe supplémentaire. Du point de vue de l’utilisateur, c’est transparent et fluide. Du point de vue des applications, c’est sécurisé car elles délèguent la vérification de l’identité à un service d’authentification central, généralement robuste et bien protégé.

Comment fonctionne l’authentification SSO ?

Le fonctionnement technique du SSO peut être décrit en plusieurs étapes d’authentification unique, depuis la saisie initiale du mot de passe jusqu’à l’accès aux applications. Voici les grandes lignes du processus :

Authentification initiale auprès du fournisseur d’identité (IdP)

L’utilisateur accède à une page de login centralisée (fournie par le fournisseur d’identité, par ex. Azure AD, Okta, Auth0, etc.) et y entre son nom d’utilisateur et son mot de passe une seule fois. Le fournisseur d’identité vérifie ces identifiants (par exemple en les comparant à un annuaire interne ou une base de données d’utilisateurs). Si les informations sont correctes, l’utilisateur est alors authentifié auprès de ce service central.

Création d’un jeton d’authentification

Une fois l’utilisateur identifié, le système SSO génère un jeton d’authentification (un objet numérique, souvent un fichier ou un code chiffré) qui atteste que « l’utilisateur X a été authentifié avec succès à telle heure ». Ce jeton, qui contient des informations d’identification sécurisées (souvent un identifiant d’utilisateur et une signature numérique), est soit stocké dans le navigateur de l’utilisateur (par exemple sous forme de cookie de session), soit conservé côté serveur SSO. Le jeton a généralement une durée de validité limitée et ne contient pas le mot de passe lui-même, mais une preuve d’authentification.

Accès aux applications partenaires 

Lorsque l’utilisateur tente d’accéder à une application ou un service partenaire (par ex. votre application de CRM), au lieu d’afficher un écran de login propre, l’application détecte que le SSO est en place et redirige (en arrière-plan) l’utilisateur vers le fournisseur d’identité pour vérification. Grâce au jeton, le fournisseur d’identité constate que l’utilisateur s’est déjà connecté et est toujours authentifié. Il n’y a donc pas besoin de demander à nouveau le mot de passe.

Validation du jeton et ouverture de session

Le fournisseur d’identité envoie à l’application cible une confirmation d’identité (souvent via un nouveau jeton spécifique à cette appli, ou un message chiffré) pour lui signaler que l’utilisateur a été authentifié et peut obtenir l’accès. L’application valide cette attestation de confiance (en vérifiant la signature du jeton par exemple) et, si tout est en ordre, ouvre une session utilisateur normalement, mais sans demander de mot de passe à l’utilisateur. Aux yeux de l’utilisateur, il est entré dans l’application de manière transparente.

Continuité de session

Tant que la session SSO de l’utilisateur est active (le jeton n’est pas expiré), il peut continuer à naviguer d’un service à l’autre sans interruption. S’il se déconnecte explicitement du SSO ou si le jeton expire (par mesure de sécurité au bout d’un certain temps d’inactivité, par exemple), le fournisseur d’identité invalide le jeton et il faudra alors se reconnecter une nouvelle fois pour obtenir un nouveau jeton.

Ce mécanisme repose sur des protocoles standards d’échange de données d’authentification entre le fournisseur d’identité et les applications. Parmi les principaux protocoles d’authentification utilisés pour le SSO, on retrouve :

• SAML (Security Assertion Markup Language) : Standard ouvert basé sur XML, très utilisé dans les entreprises. SAML 2.0 est optimisé pour les applications web : il permet au fournisseur d’identité de transmettre une assertion (une affirmation signée numériquement) à l’application cible contenant les informations d’identité de l’utilisateur.
  
• OAuth 2.0 : Protocole ouvert d’autorisation (plus que d’authentification) qui permet à un utilisateur de consentir à ce qu’une application obtienne un jeton d’accès limité pour agir en son nom. OAuth est souvent associé au SSO pour permettre à des applications d’accéder à des ressources sans demander de mot de passe. 
• OpenID Connect (OIDC) : Extension d’OAuth 2.0 qui ajoute justement une couche d’authentification (et non plus seulement d’autorisation). OIDC permet à une application de vérifier l’identité de l’utilisateur en obtenant un jeton OpenID auprès du fournisseur (appelé Identity Provider). En d’autres termes, OpenID Connect fournit un moyen standard pour le SSO de gérer la connexion d’un utilisateur à plusieurs applications en une seule session. Par exemple, l’authentification via un compte Google ou Facebook sur un site tiers utilise OpenID Connect : un utilisateur peut se connecter à un service en utilisant son compte Facebook/Google existant, au lieu de créer de nouveaux identifiants.
  
• Kerberos : Protocole d’authentification réseau (développé au MIT) basé sur un mécanisme de tickets et des clés symétriques. Kerberos est utilisé en environnement Microsoft Active Directory notamment. Il permet à un utilisateur de s’authentifier une fois auprès d’un serveur central (le Key Distribution Center) et d’obtenir des tickets qui seront présentés aux autres services du réseau pour accéder à ceux-ci sans ressaisir de mot de passe.

En pratique, les solutions SSO modernes supportent souvent plusieurs de ces protocoles afin de s’intégrer avec toutes sortes d’applications (anciennes ou récentes, cloud ou on-premise). Par exemple, une solution SSO d’entreprise pourra utiliser Kerberos pour les anciennes applications Windows internes, SAML pour les applications web métier, et OpenID Connect/OAuth pour intégrer des applications SaaS et des services cloud récents.

Quels sont les avantages du SSO ?

La mise en place d’une authentification unique apporte de nombreux bénéfices tant pour les utilisateurs que pour l’entreprise et son équipe IT. Voici les principaux avantages du SSO :

Simplification de l’expérience utilisateur et gain de temps

Avec le SSO, les utilisateurs ne saisissent plus qu’un seul mot de passe au début de la journée pour accéder à tous leurs outils. Fini de jongler entre des dizaines de logins : la réduction du nombre de mots de passe à retenir allège la charge cognitive et le temps de connexion est réduit drastiquement. 

Par exemple, Okta estime qu’au lieu de taper une dizaine de mots de passe par jour, un employé avec SSO n’en saisit qu’un seul, sans perte de sécurité. Moins de mots de passe à entrer signifie aussi moins de frictions pour utiliser les applications, donc une productivité accrue. Un employé perd en moyenne 10 heures par an à réinitialiser ou rentrer des mots de passe oubliés : le SSO permet de récupérer une bonne partie de ce temps.

Réduction de la fatigue et des erreurs liées aux mots de passe

L’authentification unique élimine la fameuse “password fatigue” (lassitude face aux trop nombreux mots de passe). Les utilisateurs sont moins enclins à adopter de mauvaises habitudes comme réutiliser le même mot de passe partout ou utiliser des mots de passe faibles. Cela se traduit par une meilleure sécurité des mots de passe pour l’organisation. 

En effet, 62 % des employés avouent partager des mots de passe professionnels par email ou SMS. Une pratique risquée que le SSO peut rendre obsolète en supprimant le besoin de communiquer des identifiants pour accéder aux outils. De plus, avec un SSO, si un employé quitte l’entreprise, on désactive son compte SSO unique et tous ses accès sont révoqués d’un coup, évitant les oublis de suppression d’un compte isolé sur une application.

Renforcement de la sécurité des accès

Cela peut sembler paradoxal car on se dit « un seul mot de passe pour tout, n’est-ce pas dangereux ? ». En réalité, le SSO renforce la sécurité à plusieurs égards. D’abord, en réduisant le nombre de mots de passe, on incite l’utilisateur à choisir un mot de passe unique plus fort (voire à utiliser une authentification multifacteur en complément, cf. section sécurité). 

Ensuite, l’architecture SSO permet un contrôle centralisé : l’équipe gestion des accès peut surveiller, tracer et analyser toutes les connexions via le fournisseur d’identité unique, ce qui facilite la détection d’accès inhabituels. De plus, les politiques de sécurité (longueur/minimum des mots de passe, durée de session, etc.) peuvent être appliquées uniformément via le SSO sur toutes les applications. 

Enfin, le SSO permet d’implémenter facilement des mesures globales comme le MFA (authentification forte à facteurs multiples) sur la connexion unique, protégeant ainsi l’accès à toutes les ressources derrière. Accès sécurisé et centralisation des accès vont de pair : le SSO devient le point de contrôle unique à bien protéger, et en échange, on obtient une sécurité cohérente et renforcée sur l’ensemble des applications connectées.

Productivité et efficacité accrue dans l’entreprise

Moins de temps perdu à se connecter et à récupérer des comptes, c’est plus de temps pour travailler. Des estimations montrent qu’en éliminant les problèmes de mots de passe (résolution d’oubli, reset), une organisation peut gagner l’équivalent de $1,9 million par an pour 500 utilisateurs en productivité retrouvée.

À une échelle individuelle, on parle de plusieurs centaines d’euros économisés par employé et par an grâce à l’authentification unique (moins d’interruptions, moins d’appels au support). 

Par ailleurs, l’IT supportant moins de tickets “mot de passe oublié”, l’équipe support peut se consacrer à des tâches à plus forte valeur ajoutée. Le SSO simplifie aussi l’onboarding : lorsqu’un nouveau collaborateur arrive, on crée un seul compte SSO et il obtient ses accès à tout en une fois (et inversement lors d’un départ, un compte à couper). Tout ceci améliore le coût de support informatique et le ROI global des opérations IT.

Amélioration de la conformité et de la traçabilité

Le SSO s’intègre souvent dans une stratégie plus large de gestion des identités et des accès (IAM). En centralisant les authentifications, il devient plus facile de démontrer la conformité aux normes (par exemple la traçabilité de qui a accédé à quoi et quand, utile pour ISO 27001, RGPD, PCI-DSS, etc.). 

On peut tester la conformité de l’ensemble du système d’accès via un point central. De plus, en cas d’audit de sécurité, on a un journal unique des connexions. Cette visibilité accrue réduit les risques liés aux comptes dormants ou aux anciens accès non révoqués.

Expérience utilisateur optimisée = utilisateurs satisfaits

Les employés apprécient de ne plus se souvenir que d’un seul mot de passe et de ne plus perdre de temps sur les écrans de login. Une navigation fluide entre les applications sans rupture améliore leur expérience et leur efficacité, ce qui peut se traduire par une meilleure adoption des outils numériques mis à disposition. Indirectement, cela renforce la sécurité car des utilisateurs satisfaits ont moins tendance à chercher des contournements (comme noter les mots de passe sur un carnet parce qu’ils en ont trop). 

À l’externe, pour des clients ou partenaires, proposer un SSO (par ex. via l’authentification sociale ou via un compte client unique) peut aussi améliorer la fidélité en diminuant les frictions lors de l’accès aux services.

Astuce : Sensibiliser les utilisateurs reste important : Un employé ne doit jamais divulguer son mot de passe SSO, même à un collègue alors qu’en pratique 57 % des employés écrivent leurs mots de passe sur des post-it et 62 % les partagent par messagerie, il faut absolument éviter ces comportements avec un compte SSO.

Centralisation = administration simplifiée pour l’IT.

Pour les administrateurs systèmes, un SSO signifie une console centrale pour gérer qui a accès à quelles applications (souvent couplée avec un annuaire d’entreprise type Active Directory ou un annuaire cloud). On peut déléguer plus facilement l’administration des accès, définir des groupes d’utilisateurs et leurs droits sur les applis en un seul endroit. Cela facilite la gestion des identités au quotidien. 

Par exemple, si un employé change d’équipe, un administrateur modifie ses groupes dans le SSO et automatiquement ses accès aux applications correspondantes sont ajustés, au lieu d’avoir à intervenir individuellement sur chaque application.

Le SSO apporte une simplification du processus de connexion pour l’utilisateur tout en donnant à l’organisation un meilleur contrôle de la gestion des accès. C’est un équilibre « gagnant-gagnant » entre expérience utilisateur améliorée et renforcement de la sécurité. 

Chiffres clés : Des études montrent que les entreprises qui investissent dans des solutions de sécurité centrées sur l’utilisateur (comme le SSO couplé au MFA) observent jusqu’à 20 % d’augmentation de la confiance de leurs clients envers la marque.

Le SSO comporte-t-il des risques ? 

Malgré ses avantages, il est important de comprendre que le SSO n’est pas une panacée sans risques. Il comporte quelques inconvénients et défis à adresser, principalement du point de vue de la sécurité. Passons en revue les risques de sécurité et limites liés à l’authentification unique, ainsi que les parades recommandées :

Point de défaillance unique

La critique la plus fréquente est la suivante : avec le SSO, si le compte principal est compromis, c’est toutes les applications reliées qui sont exposées. En effet, l’accès centralisé fait que le compte SSO devient un « sésame » potentiellement très puissant. 

Un attaquant qui parvient à dérober l’identifiant unique et le mot de passe principal d’un employé peut accéder à l’ensemble des ressources de celui-ci , ce qui est plus grave que de compromettre un seul compte applicatif isolé. 

Le SSO est-il sûr ? Oui, à condition de reconnaître ce risque et de le mitiger activement. Cela signifie qu’il faut protéger d’autant plus fortement le compte SSO que sans SSO. En pratique, cela passe par l’adoption systématique de l’authentification multifacteur (MFA) sur la connexion SSO, de politiques de mots de passe robustes (longueur, complexité, renouvellement si nécessaire) et d’un monitoring des connexions (voir ci-dessous). 

Avec ces mesures, un compte SSO compromis devient beaucoup moins probable, et même si l’identifiant unique et son mot de passe étaient volés, le second facteur (par ex. code unique ou authentification biométrique) empêcherait l’attaquant de se connecter.

Nécessité d’une haute disponibilité et d’un plan B

Si le service SSO tombe en panne ou devient indisponible, les utilisateurs ne peuvent plus accéder à aucune application liée. Cela pourrait paralyser l’entreprise. Il faut donc s’assurer que la solution SSO est hautement disponible (clustering, redondance) et prévoir un plan de secours (par ex. un mode dégradé où les applis peuvent temporairement accepter des logins locaux, ou un système de secours d’authentification). 

De même, il est recommandé de tester régulièrement le plan de continuité en cas d’indisponibilité du SSO. Certaines entreprises gardent un petit nombre de comptes d’urgence sur les applications critiques pour pouvoir se connecter localement si le SSO est hors-service (mais ces comptes doivent être très sécurisés et surveillés).

Attaques ciblées sur le SSO

Étant donné que le SSO concentre les accès, il devient une cible de choix pour les attaquants. Ceux-ci pourraient tenter des attaques par phishing très personnalisées pour dérober le mot de passe SSO d’un administrateur, ou chercher des vulnérabilités dans le protocole d’authentification. 

On a vu par exemple des attaques sur SAML où un attaquant essaie de rejouer un jeton d’authentification déjà utilisé. Il est donc important de maintenir la solution SSO à jour (correctifs de sécurité), de former les utilisateurs à déjouer les tentatives de phishing (puisque voler le mot de passe SSO devient la « clé du royaume » pour un pirate), et de mettre en place des alertes en cas de connexion anormale (par ex. alerte si un utilisateur SSO se connecte depuis un pays inhabituel ou à une heure improbable).

Point d’entrée unique mais surveillance nécessaire

Le SSO facilite la surveillance car tout passe par un point central, mais cela implique de bien configurer les journaux d’audit et de les consulter. Une faille potentielle est de croire que tout est sécurisé d’office : il faut paramétrer des règles d’authentification forte (par ex. exiger la MFA pour des accès sensibles ou distants), éventuellement recourir à de l’authentification adaptative (ex. renforcer les contrôles si la connexion vient d’un nouvel appareil) pour compenser ce point de défaillance unique. 

De plus, l’authentification forte (MFA) doit être imposée à tous les utilisateurs du SSO, faute de quoi le vol d’un seul mot de passe suffirait à tout compromettre. Beaucoup d’incidents de sécurité sont évités grâce à la MFA : 83 % des grandes entreprises utilisent la MFA et cela a fortement réduit les intrusions liées aux mots de passe volés.

Limitations sur les applications non compatibles

Il faut noter que toutes les applications ne supportent pas nativement le SSO ou les protocoles standard. Des systèmes anciens (applications « legacy ») peuvent nécessiter des approches SSO centralisées spécifiques, par exemple via un agent qui rejoue un mot de passe (ce qu’on appelle parfois un enterprise SSO old-school). Si une application ne peut pas être intégrée, les utilisateurs devront continuer à avoir un mot de passe séparé pour celle-ci, ce qui crée une exception dans l’expérience unifiée. 

On parle alors de stratégies hybrides où le SSO cohabite avec un gestionnaire de mots de passe pour les applications non fédérables. Dans l’idéal, on cherche à remplacer les applis non compatibles par des solutions modernes prenant en charge SAML/OAuth/protocoles standards du SSO. Sinon, il faudra outiller les utilisateurs pour ces exceptions.

Montée en charge et performance

Un point technique à surveiller est la capacité du SSO à gérer la charge (authentifier tous les utilisateurs sans ralentissement). Si des milliers de personnes se connectent à 9h du matin via le SSO, il doit encaisser ces pics. En outre, la latence d’authentification doit rester faible pour ne pas allonger les temps de connexion aux services. Les solutions SSO d’entreprise sont en général prévues pour ça, mais il convient de respecter les prérequis d’infrastructure (serveurs suffisamment dimensionnés, etc.).

Bon à savoir : Le SSO est sûr à condition d’être déployé avec les bonnes pratiques : MFA obligatoire, renforcement du mot de passe maître (voire usage d’une authentification biométrique ou de certificats pour ce login), surveillance active des logs de connexion, et plan de secours. 

Il faut voir le SSO comme une pièce maîtresse d’une stratégie de sécurité plus globale, qui doit être complétée par d’autres éléments de l’authentification forte (MFA, gestion du cycle de vie des comptes, etc.).

Notons que les avantages surpassent largement les risques si le SSO est bien géré. En réalité, l’absence de SSO entraîne souvent bien plus de risques cachés (post-it, Excel de mots de passe, comptes non supprimés, etc.). Avec un SSO sécurisé, on améliore la posture de sécurité globale tout en bénéficiant des gains d’usage.

SSO et gestion des identités : comment ça s’intègre ?

Le SSO ne vit généralement pas isolé : il fait partie d’un système de gestion des identités et des accès (IAM pour Identity and Access Management). Dans une architecture IAM moderne, on trouve souvent les composantes suivantes qui interagissent :

• Un annuaire d’utilisateurs central (par ex. Active Directory ou un cloud directory) qui stocke les identités, leurs attributs (nom, email, service, rôle…) et éventuellement leurs authentifiants (mots de passe, certificats, clés publiques).
  
• Un ou plusieurs fournisseurs d’identité (IdP) souvent couplés à l’annuaire qui assurent le service d’authentification unique. Le fournisseur d’identité est l’élément qui va délivrer les jetons d’authentification SSO.
  
• Des fournisseurs de services (SP) : ce sont les applications elles-mêmes qui consomment l’authentification fédérée. Elles dépendent du fournisseur d’identité pour vérifier les connexions. Chacune est configurée pour « faire confiance » aux assertions du IdP (via certificats, échanges de clés).

Le SSO fédéré implique une vraie fédération d’identité : un cercle de confiance se crée entre l’IdP et les SP. Cela s’appuie souvent sur des normes comme SAML (notion de circle of trust) ou OIDC. En interne, on peut parler de fédération d’identité entre un annuaire central et des applis SaaS : plutôt que d’avoir des comptes séparés, on fédère l’authentification via le SSO.

Par ailleurs, il est utile de distinguer SSO de quelques autres concepts souvent confondus :

SSO vs Gestionnaire de mots de passe

Une solution SSO fédère l’authentification, c’est-à-dire qu’elle n’authentifie qu’une fois et répète ce contexte de confiance. Elle ne communique pas les mots de passe aux applications, elle communique un jeton. À l’inverse, un gestionnaire de mots de passe stocke en mémoire sécurisée vos multiples mots de passe et peut les auto-remplir dans chaque application (c’est une approche centralisée, mais pas fédérée). En pratique, les deux approches peuvent coexister : SSO pour toutes les applications compatibles, et un gestionnaire de mots de passe pour les quelques applications ne pouvant pas s’intégrer au SSO (voir section précédente).

Attention : le social login n’est pas adapté à tous les contextes (notamment pas aux données sensibles d’entreprise) et nécessite quand même de faire confiance au fournisseur d’identité externe.

Authentification unique vs authentification via les réseaux sociaux

Se connecter à un site web avec « Login with Facebook » ou « Se connecter avec Google » est une forme particulière de SSO qu’on appelle parfois social login. Ici, le fournisseur d’identité est un réseau social ou un géant du web (Facebook, Google, Apple…). Du point de vue de l’utilisateur, c’est bien du SSO (il utilise une identité existante pour plusieurs services). La différence, c’est qu’on confie l’authentification à un tiers public, et non à son entreprise. 

Bon à savoir : Des sites de e-commerce proposent aux clients de s’authentifier via Google : cela leur évite de créer un nouveau compte et mot de passe local pour ce site. C’est un usage courant en B2C, reposant sur OAuth/OIDC (Google ou Facebook fournissent un jeton d’identité). Dans une entreprise, on parle plutôt de SSO « privé » avec un IdP maîtrisé par l’organisation, mais certaines entreprises autorisent aussi le social login pour intégrer, par exemple, l’identification LinkedIn des partenaires. 

SSO vs LDAP/Active Directory

On entend parfois « SSO LDAP » dans le sens où un utilisateur peut accéder à plusieurs applications on-premise s’il est déjà connecté à son domaine Windows (c’est le cas typique en entreprise Windows : on ouvre sa session Windows le matin et ensuite les applications liées à l’Active Directory nous reconnaissent). 

Ici, c’est une forme de SSO intégrée au système d’exploitation, fournie par Kerberos/LDAP. L’évolution moderne est d’étendre ce concept au cloud et aux applications web via des solutions SSO plus universelles. Ainsi, on peut considérer le SSO comme une extension du concept d’annuaire central : l’annuaire (AD ou cloud directory) sert de base, et le SSO (ADFS, etc.) offre la fédération vers toutes sortes d’applis.

En termes d’intégration, lors de la mise en œuvre du SSO, on veillera donc à bien définir le rôle de chaque composant IAM. Souvent, l’IdP SSO est lui-même une solution intégrée : par exemple, Azure AD peut stocker les utilisateurs et en même temps servir de fournisseur SSO pour Office 365 et d’autres applications. D’autres fois, on a un AD on-premise + un outil de fédération (PingFederate, Okta, etc.) qui connecte cet AD aux applis cloud.

Enjeux IAM liés au SSO

L’authentification unique s’inscrit dans la stratégie zero trust actuelle (ne jamais faire confiance par défaut, toujours vérifier) paradoxalement, le SSO peut paraître comme « faisons confiance après un seul login », mais couplé à la MFA et à des contrôles contextuels (appareil connu, localisation) c’est un pilier de zero trust car il centralise la vérification. 

Quels sont les différents types de Single Sign-On ?

Toutes les implémentations de SSO ne se ressemblent pas. On peut distinguer plusieurs approches du SSO, notamment :

SSO d’entreprise “centralisé” (eSSO)

C’est l’approche historique où un logiciel interne sert de coffre-fort de mots de passe et/ou utilise des agents locaux pour gérer les connexions. Des solutions existent qui interceptent les écrans de connexion des applications Windows et y injectent les identifiants de l’utilisateur (stockés de manière chiffrée) lorsqu’il est connecté à sa session Windows. C’est du SSO dans l’expérience (l’utilisateur n’a pas à resaisir), mais techniquement ça repose encore sur les mots de passe individuels en coulisse. 

Bon à savoir : On trouve ce genre d’approche dans certains environnements où les applis ne supportent pas SAML/OAuth. C’est une approche centralisée du SSO : un outil prend en charge toutes les authentifications aux applis en réutilisant une identité centrale. Par exemple, Evidian Enterprise SSO fonctionnait ainsi, en rejouant les mots de passe pour différentes applis dès lors que l’utilisateur avait ouvert sa session maître.

SSO « fédéré » basé sur les protocoles standards

Il s’agit du SSO moderne que nous avons décrit plus haut, impliquant fédération d’identité et échange de jetons. Ici, plus besoin de retenir x mots de passe ou de faire du remplissage automatique : c’est une approche fédérative du SSO où les applications font confiance aux assertions du fournisseur d’identité. Cette approche est hautement sécurisée car aucun mot de passe n’est transmis aux applications, seulement des certificats ou tokens temporaires. C’est le modèle préféré pour les services cloud et applications web actuelles. On parle parfois de SSO Web ou de SSO basé sur SAML/OIDC. 

Exemple : un employé en entreprise clique sur « Se connecter via SSO » sur Salesforce, il est redirigé vers le login de l’entreprise (IdP), se connecte, puis revient sur Salesforce connecté. 

SSO grand public et connexion unifiée

On peut mentionner le cas du SSO social (connexion avec Google, Facebook comme IdP) dont on a parlé, qui est une déclinaison B2C du modèle fédéré (OpenID Connect). 

Bon à savoir : par extension, certaines grandes suites grand public offrent un SSO entre leurs services : un compte Apple unique pour accéder à iCloud, Apple Music, Apple Store etc., c’est du SSO intra-organisation (l’organisation étant Apple ici). De même, les écosystèmes Google ou Microsoft offrent un SSO entre leurs propres applications. Cela montre que le concept s’applique partout, pas qu’en entreprise.

Variantes spécifiques

On voit apparaître des notions comme SSO adaptatif, où l’authentification unique est couplée à du contexte adaptatif (ex. si le risque est évalué comme élevé, on redemande une authentification forte malgré le SSO). Également, la fédération inter-organisations : par exemple, le standard Cross-domain Identity Management ou des accords de fédération permettent à une entreprise A de faire confiance au SSO de l’entreprise B (utile dans des partenariats B2B). C’est une extension du SSO où plusieurs domaines se font confiance – un peu comme si votre compte d’entreprise vous permettait aussi de vous connecter en SSO sur le portail de votre fournisseur, sans créer de compte chez lui, grâce à une fédération entre vos identités.

En pratique, la plupart des solutions actuelles combinent un peu tout : elles proposent du SAML/OIDC pour les apps fédérables, et parfois un module Password Vaulting pour les apps anciennes (où le SSO stocke le mot de passe de l’utilisateur et le remplit automatiquement). L’utilisateur ne voit pas la différence : il clique sur l’appli et ça “s’ouvre tout seul”. Mais l’architecture sous-jacente peut varier.

Astuce : Idéalement, privilégiez toujours la fédération standard (SAML/OAuth/OIDC) car elle élimine les mots de passe des flux d’authentification et s’appuie sur des standards robustes. Les approches eSSO “coffre-fort” ne doivent être que transitoires pour les applis qui ne peuvent vraiment pas faire autrement. 

Le SSO fédéré est plus adapté aux environnements cloud et mobiles. Par exemple, pour des applications SaaS comme Office 365, Google Workspace, Salesforce, Workday, etc., le SSO fédéré est pris en charge nativement et offre la meilleure expérience (accès direct via un identifiant unique). Tandis que pour une vieille application client-serveur, on se rabattra sur un agent local type Kerberos ou un plug-in.

Comment mettre en place un SSO dans votre organisation ?

Implémenter le SSO nécessite de suivre quelques étapes et bonnes pratiques. Voici un guide pratique pour déployer une authentification unique en entreprise de façon sécurisée et efficace :

Définir le périmètre et choisir la solution SSO

Commencez par lister les applications que vous souhaitez intégrer au SSO (applications internes, SaaS, etc.) et identifier leurs capacités (supportent-elles SAML, OAuth ? Ont-elles un connecteur existant avec des solutions SSO du marché ?). Sur cette base, choisissez une solution SSO adaptée à vos besoins. Il existe des solutions cloud reconnues (Okta, Azure AD/Entra ID, OneLogin, Ping Identity, JumpCloud, etc.) et des solutions open source (Keycloak, Shibboleth) ou on-premise (ADFS de Microsoft, IBM Security Access Manager, etc.). 

Votre choix dépendra de vos contraintes : par exemple, Azure AD s’intègre bien si vous êtes déjà sous Microsoft 365, Okta est neutre et multi-environnements, Keycloak peut être préféré si vous voulez du sur-mesure open source, etc. Assurez-vous que la solution gère bien les protocoles standards dont vous avez besoin (SAML 2.0, OAuth2/OIDC, LDAP si connecteur AD, etc.), et qu’elle offre une authentification multifacteur intégrée ou via des partenaires.

Intégrer le SSO avec votre annuaire d’identités

Si vous avez un annuaire d’entreprise (Active Directory ou autre), la solution SSO devra s’y connecter pour récupérer les comptes utilisateurs et éventuellement valider les mots de passe (dans le cas d’une fédération AD par exemple). Souvent, on configure un connecteur LDAP ou on synchronise les identités vers le cloud SSO. 

Par exemple, Okta ou JumpCloud peuvent synchroniser les comptes depuis AD grâce à un agent. Le but est que vos utilisateurs du SSO soient à jour (quand on crée ou supprime un compte dans l’annuaire principal, le SSO le reflète). 

Cette étape implique de penser à la gouvernance des identités : quels attributs d’utilisateur seront envoyés aux applications via le SSO (prénom, nom, email, rôle… ?), utilise-t-on des groupes pour gérer les droits, etc. C’est là qu’on planifie l’architecture IAM dans son ensemble.

Configurer les applications dans le SSO

Pour chaque application cible, on réalise une configuration de fédération. Typiquement, pour une application SaaS supportant SAML, on crée un connecteur SAML dans le SSO : on renseigne l’URL de l’application, on échange des certificats ou clés, et on décide quels attributs envoyer (par ex. l’app attend un attribut “email” ou “EmployeeID” pour reconnaitre l’utilisateur).

La plupart des fournisseurs SSO proposent des catalogues d’applications préconfigurées où beaucoup de paramètres sont déjà prêts. 

Pour les applications internes, on peut devoir ajuster manuellement ou mettre en place un proxy SSO. C’est une phase technique qui requiert de tester chaque application pour vérifier que le SSO fonctionne bien (l’utilisateur doit pouvoir se connecter via le SSO et aussi ne plus pouvoir se connecter en direct avec un mot de passe local, si on veut tout forcer via SSO).

Mettre en place les politiques de sécurité

Une fois le SSO opérationnel, définissez les règles d’authentification forte. Par exemple : MFA obligatoire à la première connexion ou dès que la connexion se fait hors réseau interne ; durée de session SSO (combien de temps une session reste valable avant de redemander une authentification) ; règles d’accès conditionnel (ex : bloquer l’accès SSO depuis certains pays ou exiger une re-authentification pour une application critique même en SSO). Ces politiques sont importantes pour aligner la sécurité sur vos exigences de conformité. Configurez également les logs du SSO pour qu’ils soient envoyés à votre SIEM ou archivés, afin de pouvoir auditer en cas d’incident.

Tester et déployer progressivement

Il est recommandé de faire un projet pilote. Intégrer d’abord quelques applications non critiques et un petit groupe d’utilisateurs volontaires. Collectez leurs retours, affinez la configuration (certains attributs d’identité manquants, etc.). Testez la procédure de secours. Quand tout est stable, étendez à d’autres applications par vagues. C’est aussi l’occasion de vérifier que les anciennes méthodes d’accès sont bien désactivées pour éviter les contournements.

Former et communiquer auprès des utilisateurs

Le déploiement du SSO va changer légèrement les habitudes : il faut donc accompagner les utilisateurs. Expliquez-leur comment se connecter via le nouveau portail (montrer l’écran de login, rassurez sur le fait que c’est la même identité mais en mieux). Insistez sur l’importance du mot de passe maître du SSO et sur la nécessité de ne pas le divulguer. Si vous introduisez la MFA en même temps, prévoyez un support.

Surveillance et maintenance

Une fois en production, administrez le SSO comme une brique critique. Mettez à jour régulièrement la solution (les éditeurs sortent des patchs notamment pour suivre les évolutions de sécurité des protocoles). Surveillez les connexions suspectes (beaucoup de solutions SSO offrent des tableaux de bord sur l’activité, voire de la détection d’anomalies). Continuez d’intégrer les nouvelles applications dans le SSO plutôt que de créer de nouveaux silos de mots de passe. 

Astuce : Impliquez tôt les équipes de sécurité informatique dans le projet SSO, afin qu’elles valident l’architecture (notamment l’aspect “point unique” et les contre-mesures MFA, etc.). Sauvegardez la configuration de votre IdP, et documentez une procédure d’urgence en cas d’indisponibilité. Pensez aussi aux particularités comme les comptes de service (s’ils existent, vont-ils passer par le SSO ou garder une authentification séparée ? souvent on les traite à part).

Pour rentabiliser au maximum votre SSO, envisagez d’y coupler un outil de provisioning automatique (SCIM) pour que créer un utilisateur dans l’annuaire crée aussi son compte dans chaque appli via le SSO cela automatise l’ensemble du cycle de vie des identités.

Le SSO remplace-t-il l’authentification multifacteur (MFA) ?

Le SSO et la MFA adressent des besoins complémentaires. Le SSO simplifie l’accès en évitant de multiples authentifications, tandis que la MFA augmente le niveau de sécurité en exigeant une preuve supplémentaire (code unique, biométrie, etc.) en plus du mot de passe. Idéalement, on doit utiliser SSO + MFA ensemble : l’utilisateur se connecte une fois via le SSO et valide son identité avec un deuxième facteur. 

On obtient à la fois la simplification du processus de connexion et une authentification forte. La MFA est recommandée surtout parce que si le compte SSO principal est compromis, le MFA empêche l’attaquant d’en profiter. En pratique, beaucoup de solutions SSO intègrent la MFA ou s’interfacent avec (par ex. envoi d’un code SMS, notification push sur smartphone, usage d’une clé physique U2F, etc.)

Le SSO peut-il fonctionner pour des applications mobiles et sur site ?

Pour les applications web classiques, le SSO s’active via les redirections navigateur (SAML, OAuth). Pour les applications mobiles, c’est également supporté : par exemple, une appli mobile d’entreprise peut intégrer un SDK qui la redirige vers l’appli d’IdP ou le navigateur pour authentification puis la reprend. Des protocoles comme OIDC sont conçus pour le mobile. 

Sur site (applications desktop), le SSO peut passer par des mécanismes comme Kerberos (si l’appli supporte l’authentification Windows intégrée) ou via des connecteurs spécialisés. On voit aussi se développer la notion de Passwordless SSO où sur mobile l’utilisateur utilise un facteur biométrique pour le SSO (ex: FaceID déclenche un token SSO). Donc, que ce soit pour des sites web, des logiciels SaaS, des apps mobiles ou même des systèmes legacy, on trouve généralement un moyen d’intégrer le SSO, quitte à utiliser plusieurs méthodes selon les cas.

Que se passe-t-il si la solution SSO a une panne ?

Si le fournisseur d’identité (SSO) tombe, les utilisateurs risquent de ne plus pouvoir se connecter aux services reliés. C’est le revers du “tout en un”. Pour se prémunir, il est essentiel de choisir une solution SSO fiable et de la configurer en haute disponibilité (plusieurs serveurs redondants, ou service cloud éprouvé). Il faut également définir un plan de continuité : par exemple, prévoir des comptes d’administrateurs locaux sur les applications critiques permettant une connexion d’urgence sans SSO, ou avoir une procédure pour basculer sur un IdP de secours. 

Certains systèmes proposent un mode dégradé (cache des sessions actives si l’IdP est indisponible temporairement). Dans tous les cas, c’est une réflexion à mener en amont lors du projet SSO. Pensez aussi aux tests de conformité et de résilience : tester la coupure du SSO et voir comment récupérer.

Le SSO m’oblige-t-il à tout mettre chez un seul fournisseur ?

Le SSO est là pour unifier des services hétérogènes. Vous pouvez très bien utiliser un SSO “agnostique” comme Okta, Ping ou Keycloak pour fédérer à la fois vos applications Microsoft, Google, Salesforce, etc. Si vous êtes très centré sur un écosystème (par ex. full Microsoft), utiliser Azure AD comme SSO est logique. Mais si vous avez un mix, des solutions tierces neutres sont adaptées. Le SSO s’inscrit dans une approche d’interopérabilité via les protocoles standard : un IdP peut faire confiance à un autre (fédération inter-domaine).

Faut-il quand même changer régulièrement le mot de passe principal SSO ?

Les politiques de changement périodique des mots de passe font débat. Les bonnes pratiques modernes (NIST, ANSSI) suggèrent de ne pas imposer de changement fréquent sauf suspicion de compromission, car cela pousse les utilisateurs à choisir des mots de passe plus faibles à force de les changer. 

Pour le compte SSO, l’idéal est d’avoir un mot de passe très fort (long, aléatoire) et de le changer rarement, mais en le protégeant par MFA. Si votre politique impose un roulement (tous les 90 jours par ex.), assurez-vous que l’utilisateur puisse changer son mot de passe SSO facilement via un portail sécurisé. 

Aussi, ayez un mécanisme de réinitialisation en libre-service (avec vérification, question de sécurité ou code par email) pour le compte SSO, sinon le support va être submergé. Notez qu’avec un SSO bien déployé, la sécurité des mots de passe s’améliore et vous pouvez vous permettre d’allonger la durée de validité d’un mot de passe vu qu’il n’est tapé qu’une fois par jour (limite les expositions).

C’est là qu’intervient un gestionnaire de mots de passe complémentaire : malgré un SSO efficace, il restera peut-être quelques accès non fédérés ou des partages de mots de passe à réaliser en interne (comptes techniques, etc.). U‑Cyber 360°,intègre une solution de gestion de mot de passe qui repose sur un chiffrement de type Zero Knowledge (algorithmes Argon 2 et RSA, protocole HKDF et chiffrement AES‑256) pour garantir la confidentialité totale des données. Notre solution centralise, génère, protège et partage les mots de passe de façon sécurisée sur une plateforme unique. Couplée à une authentification unique tierce, elle permet de gérer les exceptions et les secrets en offrant un coffre-fort chiffré, une synergie idéale avec un SSO et des fonctionnalités avancées (partage de mots de passe chiffrés en équipe, audit des identifiants compromis, auto-remplissage, etc.).