Un collaborateur de banque ouvre sa session le matin et accède, sans ressaisir de mot de passe, à sa messagerie, aux applications métier, à l’intranet et aux outils de reporting. Ce confort quotidien repose sur l’authentification unique, ou SSO (single sign-on), et il a une conséquence directe sur l’architecture de sécurité : tous ces accès dépendent désormais d’un même compte. Un attaquant qui parvient à en prendre le contrôle hérite d’un trousseau complet.
Dans le secteur financier, où chaque utilisateur manipule couramment des dizaines d’applications, le SSO s’est imposé comme un socle de la gestion des accès, et sa sécurisation pèse sur celle de toutes les applications qui s’y raccordent.
Ce que recouvre l’authentification unique
Le SSO sépare l’authentification des applications elles-mêmes. L’utilisateur prouve son identité une seule fois auprès d’un fournisseur d’identité (IdP), qui émet ensuite des jetons ou des assertions attestant de cette authentification auprès des applications dites fédérées. Chaque application accepte ces preuves parce qu’une relation de confiance a été établie au préalable avec le fournisseur d’identité, lui-même adossé au référentiel central de gestion des identités et des accès (IAM).
Deux familles de protocoles dominent le domaine : SAML, très répandu dans les applications d’entreprise, et OpenID Connect, construit sur OAuth 2.0 et privilégié par les services web et mobiles plus récents. Le NIST consacre un volet de ses lignes directrices sur l’identité numérique, la série SP 800-63, aux mécanismes de fédération et d’assertion qui sous-tendent ces échanges.
Des bénéfices qui ne se limitent pas au confort
L’utilisateur n’a plus qu’un mot de passe à retenir, ce qui limite les choix faibles ou réutilisés d’un service à l’autre et allège au passage les demandes de réinitialisation adressées au support.
La centralisation sert surtout les équipes sécurité. Les politiques d’authentification — exigence d’un second facteur, durée de vie des sessions — se définissent en un point unique au lieu d’être déclinées application par application, avec les écarts que cela finit par produire. Le départ d’un collaborateur illustre l’autre gain notable : désactiver son compte auprès du fournisseur d’identité coupe l’accès à l’ensemble des applications fédérées, là où une gestion éclatée laisse régulièrement subsister des comptes orphelins. Ce mécanisme complète la gestion des habilitations, qui doit par ailleurs suivre les mobilités internes et les fins de mission des prestataires.
Un point de concentration que les attaquants ont identifié
Cette centralisation a une contrepartie que les attaquants exploitent : compromettre le compte d’un utilisateur auprès du fournisseur d’identité ouvre d’un coup toutes les applications auxquelles il est habilité. Les campagnes de phishing visant les portails d’authentification d’entreprise recherchent précisément ce point d’entrée, y compris avec des kits capables de relayer en temps réel les codes à usage unique ou de voler des cookies de session. Le harcèlement de notifications MFA poursuit le même objectif en misant sur la lassitude de l’utilisateur.
Le fournisseur d’identité constitue lui-même une cible. Ses consoles d’administration et ses processus de support concentrent un pouvoir considérable : obtenir du service d’assistance la réinitialisation d’un facteur d’authentification en se faisant passer pour un salarié suffit parfois à contourner tout le dispositif. Ce détournement du support interne fonctionne en miroir de l’arnaque au faux support technique, où c’est l’attaquant qui endosse le rôle du dépanneur.
Protéger le fournisseur d’identité en priorité
L’ANSSI publie des recommandations relatives à l’authentification multifacteur et aux mots de passe qui aident à hiérarchiser les mécanismes selon la sensibilité des accès. La CISA, de son côté, a consacré une fiche à la mise en œuvre d’un MFA résistant au phishing, en distinguant les méthodes qu’un kit d’hameçonnage peut relayer de celles qui y résistent par construction. Appliquées au compte SSO, ces publications aboutissent à la même hiérarchie : un compte qui ouvre l’ensemble des applications fédérées justifie une authentification résistante au phishing, de type FIDO ou passkey, plutôt qu’un code à usage unique.
Les accès conditionnels prolongent cette protection. Avant d’émettre un jeton, le fournisseur d’identité peut évaluer le contexte de la demande — conformité du poste, localisation, réseau d’origine, signaux de risque — et refuser ou dégrader l’accès quand la situation sort du cadre attendu. Cette évaluation continue rejoint le modèle zero trust, qui réexamine la légitimité d’un accès au fil de la session au lieu de s’en remettre au seul moment de la connexion.
La surveillance complète ces mesures. Les journaux de l’IdP — authentifications réussies ou refusées, enrôlement de nouveaux facteurs, sessions, modifications de configuration — comptent parmi les sources les plus utiles à faire remonter vers un SIEM, où leur corrélation aide à repérer un enrôlement suspect ou des connexions géographiquement incohérentes.
Habilitations et comptes à privilèges : ce que le SSO ne règle pas
Une fois l’utilisateur authentifié, la question de ses droits reste entière. Le SSO atteste une identité ; ce que cette identité peut consulter ou modifier dans chaque application relève des habilitations, dont la revue périodique demeure indispensable, fédération ou non.
Les comptes d’administration appellent un traitement distinct, à commencer par ceux du fournisseur d’identité. Compte d’administration séparé du compte bureautique, passage par un bastion, coffre à mots de passe, enregistrement des sessions sensibles : ces pratiques relèvent de la gestion des comptes à privilèges (PAM). S’y ajoutent des comptes de secours dits « break glass », volontairement maintenus hors fédération pour reprendre la main si l’IdP est indisponible ou compromis, dont l’usage doit rester exceptionnel et systématiquement tracé.
Le cas particulier des identités machine
Comptes de service, clés d’API, certificats et jetons applicatifs ne passent par aucun écran de connexion : ces identités échappent pour l’essentiel à un SSO conçu pour des humains. OAuth 2.0 couvre certains échanges de machine à machine, mais une part importante des secrets reste stockée dans des fichiers de configuration ou des chaînes d’intégration continue, sans rotation ni propriétaire identifié. Leur prolifération dans les SI bancaires fait des identités machine et de la gestion des secrets un chantier à part entière, qu’un SSO des utilisateurs bien déployé ne dispense pas d’ouvrir.
Questions fréquentes
Le SSO remplace-t-il l’authentification multifacteur ?
Non. L’authentification unique réduit le nombre de connexions à réaliser, sans renforcer pour autant celle qui subsiste. Les deux se combinent : parce qu’une seule authentification ouvre de nombreux accès, l’ANSSI comme la CISA recommandent de lui réserver les mécanismes les plus robustes, à commencer par un facteur résistant au phishing.
Que se passe-t-il si le fournisseur d’identité est indisponible ?
L’accès à toutes les applications fédérées est bloqué, qu’il s’agisse d’une panne, notamment chez un fournisseur cloud, ou d’une attaque. Cette dépendance justifie d’intégrer le fournisseur d’identité aux scénarios de continuité et de reprise de l’établissement, et de prévoir des comptes de secours hors fédération.
Faut-il placer toutes les applications derrière le SSO ?
La couverture la plus large possible est généralement recherchée, car chaque application restée hors fédération conserve sa propre gestion de comptes, avec ses faiblesses et ses comptes oubliés. Deux limites subsistent : les applications anciennes qui ne prennent en charge aucun protocole de fédération, et les accès d’urgence ou d’administration maintenus volontairement à l’écart afin de ne pas dépendre de l’IdP dans les situations où il est lui-même en cause.
