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

Comment fonctionne le SSO ?

Le SSO repose sur le concept d'identité fédérée, le partage d'attributs d'identité entre des systèmes autonomes mais de confiance. Lorsqu'un système fait confiance à un utilisateur, tous les autres systèmes dans cette relation de confiance lui font confiance aussi. En pratique, cela signifie créer une relation de confiance entre un fournisseur d'identité (IdP), le système qui crée, stocke et vérifie les identités des utilisateurs, et chaque fournisseur de services (SP), l'application ou le site web auquel l'utilisateur souhaite accéder. Un service SSO ne stocke généralement pas les identités des utilisateurs lui-même. Il agit comme intermédiaire, vérifiant les identifiants d'un utilisateur auprès d'un service de gestion des identités distinct, un peu comme un bibliothécaire qui recherche un livre en votre nom sans avoir tout le catalogue mémorisé.

Le National Institute of Standards and Technology (NIST) structure l'identité numérique sécurisée autour de trois piliers : la vérification d'identité, l'authentification et la fédération. Le SSO s'inscrit directement dans ce cadre : les utilisateurs s'authentifient via une source de confiance, et les applications reçoivent une preuve vérifiée que l'utilisateur est autorisé. Un flux de connexion typique ressemble à ceci :

1. L'utilisateur tente d'accéder à un fournisseur de services (une application ou un site web).
2. Le SP redirige la requête vers le fournisseur d'identité (le système SSO) pour authentification.
3. Si l'utilisateur n'est pas déjà connecté, il est invité à se connecter une seule fois auprès de l'IdP.
4. L'IdP valide les identifiants et émet un jeton d'authentification signé.
5. Le jeton est retourné au SP, et l'accès est accordé à l'utilisateur. Pour chaque autre application connectée, le jeton est vérifié et l'accès est accordé sans connexion supplémentaire.

Comment fonctionnent les jetons d'authentification SSO

Le jeton d'authentification est ce qui rend le SSO possible. Lorsqu'un utilisateur se connecte, le service SSO crée un jeton, une donnée numérique qui atteste que cet utilisateur a été vérifié, et le stocke soit dans le navigateur de l'utilisateur, soit sur les serveurs du service SSO (parfois appelé serveur de service d'authentification central, ou CAS). Chaque fois que l'utilisateur ouvre une autre application, celle-ci vérifie auprès du service SSO, qui transmet le jeton pour confirmer l'identité et laisser l'utilisateur entrer.

Pour que cela soit digne de confiance, le jeton doit être inviolable et parler un langage standard. Les jetons sont signés numériquement afin que l'application destinataire puisse vérifier qu'ils proviennent d'une source légitime, un peu comme le personnel d'un événement qui reconnaît le tampon exact utilisé à l'entrée. Le principal standard de jetons est le Security Assertion Markup Language (SAML) : tout comme les pages web sont écrites en HTML, de nombreux jetons d'authentification SSO sont écrits en SAML. Les flux modernes utilisent également des jetons OIDC et OAuth 2.0, par exemple un JSON Web Token (JWT) signé, pour transporter les informations d'identité entre les domaines, ce qui est nécessaire car les navigateurs appliquent une politique de même origine qui empêche un domaine de lire les données de session d'un autre domaine de lui-même.

Protocoles et standards SSO

Plusieurs protocoles permettent le SSO, chacun adapté à des environnements différents. Le tableau ci-dessous compare les quatre que vous êtes le plus susceptible de rencontrer.

Une distinction utile : OAuth autorise (il accorde l'accès à une ressource) tandis que SAML et OIDC authentifient (ils établissent l'identité de l'utilisateur). Dans les déploiements réels, ces protocoles sont souvent utilisés ensemble. Au-delà des protocoles logiciels, le SSO matériel existe également, comme les cartes à puce qu'un utilisateur insère et déverrouille avec un code PIN, qui sont très sécurisées mais peuvent être perdues et sont plus coûteuses à gérer.

Types de déploiement SSO : Sur site vs. cloud

Les solutions SSO se déclinent généralement en deux modèles de déploiement. Le SSO sur site fonctionne sur du matériel ou des machines virtuelles que l'organisation installe et maintient elle-même. Il offre un contrôle total sur l'environnement, ce qui convient aux organisations ayant des exigences strictes de conformité ou de résidence des données, mais il entraîne des coûts initiaux plus élevés et une maintenance continue. Le SSO basé sur le cloud est délivré en mode Software-as-a-Service, entièrement hébergé par l'éditeur. Il réduit le coût initial, supprime la contrainte matérielle et évolue à la demande, en échange d'un contrôle moins direct sur l'infrastructure. De nombreuses organisations obtiennent l'ensemble de leurs capacités IAM, SSO, MFA adaptatif et annuaires d'utilisateurs, regroupées dans une offre Identity-as-a-Service (IDaaS).

Brève histoire du SSO

Le SSO est né des outils d'identité sur site que les organisations utilisaient à la fin des années 1990 pour connecter leurs ordinateurs, réseaux et serveurs. À l'époque, les identités des utilisateurs étaient gérées via des systèmes comme Active Directory (AD) de Microsoft et le Lightweight Directory Access Protocol (LDAP), avec des accès sécurisés par des outils SSO sur site ou de Web Access Management (WAM) de première génération. À mesure que l'IT a migré vers le cloud, s'est étendu sur de nombreux appareils et a fait face à des menaces plus sophistiquées, ces outils traditionnels ont eu du mal à suivre, ce qui a poussé le SSO vers le modèle cloud et basé sur les standards qui domine aujourd'hui.

Bénéfices du SSO

Les organisations adoptent le SSO pour un mélange de gains de productivité et de sécurité :

• Productivité accrue et meilleure expérience utilisateur : Une seule connexion déverrouille toutes les applications connectées, les utilisateurs passent donc moins de temps à se connecter et à basculer entre les outils.
• Moins de tickets au helpdesk : Avec un seul mot de passe à mémoriser, les demandes de réinitialisation de mot de passe chutent nettement, libérant l'IT pour des travaux à plus forte valeur ajoutée.
• Surface d'attaque réduite : Le SSO limite la fatigue liée aux mots de passe et la réutilisation de mots de passe, deux des principales sources de risque. Il signifie également que les services stockent moins d'identifiants.
• Politique plus solide et appliquée de façon centralisée : Le MFA, les règles de mot de passe et la ré-authentification peuvent être imposés une seule fois en un point unique plutôt qu'application par application.
• Audit simplifié et moins de shadow IT : L'authentification centrale offre une visibilité en temps réel sur qui a accédé à quoi, quand et depuis où, et décourage l'utilisation d'applications non sanctionnées.
• Une fondation pour la suite : Le SSO facilite l'ajout du MFA, de l'authentification basée sur le risque et à terme de l'accès sans mot de passe.

Défis et risques de sécurité du SSO

Le SSO est pratique et, bien mis en œuvre, plus sécurisé, mais il n'est pas sans risque. La préoccupation principale est que le SSO crée un point de défaillance unique : si un attaquant dérobe les identifiants SSO d'un utilisateur, il accède à toutes les applications que cet utilisateur peut atteindre, et si le système SSO lui-même est compromis, tous les services connectés sont exposés. Verizon a rapporté qu'une grande majorité des attaques sur les applications web impliquent des identifiants volés, ce qui est exactement le scénario que le SSO peut soit atténuer soit amplifier selon la façon dont il est sécurisé.

D'autres défis incluent la dépendance à un service tiers pour la disponibilité et la sécurité de l'authentification, les failles d'implémentation comme la mauvaise configuration, la gestion de session insuffisante ou le chiffrement inadéquat, les vulnérabilités connues trouvées dans les implémentations SAML et OAuth, et la compatibilité des applications, car une application sans vrai support SSO devient simplement un mot de passe de plus. La leçon récurrente est que le SSO ne doit jamais reposer sur un mot de passe seul. Il doit toujours être associé au MFA et à une gouvernance des identités solide.

Le SSO est-il sécurisé ?

Le SSO peut être très sécurisé, mais sa sécurité dépend entièrement de son implémentation. La bonne pratique est d'imposer le MFA sur toutes les connexions SSO, de définir des politiques d'accès claires par utilisateur et par groupe, d'appliquer des contrôles granulaires par application, d'exiger des vérifications d'appareil et de localisation, de conserver des journaux d'authentification détaillés, et d'ajouter une authentification basée sur le risque qui élève le niveau d'exigence lorsqu'une connexion paraît inhabituelle. Un prestataire réputé inclura également des outils intégrés pour détecter et bloquer les tentatives de connexion malveillantes. Le SSO seul n'est pas une garantie de sécurité ; le SSO associé au MFA, à une politique solide et à la surveillance l'est.

Comment mettre en œuvre le SSO

Quel que soit le protocole spécifique, un déploiement SSO suit un ensemble cohérent d'étapes :

1. Intégrer le fournisseur d'identité : Configurer l'IdP pour stocker et gérer les identités et identifiants des utilisateurs.
2. Enregistrer chaque fournisseur de services : Connecter chaque application qui utilisera le SSO à l'IdP, en établissant une confiance mutuelle.
3. Configurer le flux d'authentification : Implémenter le protocole choisi (SAML, OIDC, etc.) pour gérer l'échange de jetons et d'assertions.
4. Configurer l'expérience utilisateur : Rediriger les utilisateurs vers l'IdP pour la connexion lorsqu'ils tentent d'accéder à une application connectée.
5. Verrouiller la sécurité et la conformité : Chiffrer et signer les assertions, imposer le MFA et respecter les réglementations applicables.

Commencez avec un groupe pilote pour détecter les problèmes avant un déploiement complet, maintenez la solution à jour et communiquez clairement avec les utilisateurs sur ce qu'ils doivent attendre.

Le rôle du SSO dans l'IAM

Le SSO est une composante de la gestion des identités et des accès, la discipline plus large du contrôle de qui peut accéder à quoi. Il gère la partie authentification, vérifiant l'identité et accordant le niveau d'accès approprié, et doit être intégré avec des outils de contrôle d'accès, des journaux d'activité et des processus de surveillance du comportement des utilisateurs.

SSO vs. MFA

Le SSO et le MFA sont complémentaires, pas concurrents. Le SSO simplifie l'accès en permettant à un jeu d'identifiants de déverrouiller de nombreuses applications, optimisant la commodité. Le MFA renforce la sécurité en exigeant une preuve d'identité supplémentaire (un code, une notification push, une empreinte digitale) avant d'accorder l'accès. Le SSO réduit le nombre de connexions ; le MFA rend chaque connexion plus difficile à falsifier. Utilisés ensemble, ils équilibrent une expérience fluide et une protection solide, c'est pourquoi les équipes de sécurité recommandent de ne jamais déployer le SSO sans MFA.

SSO vs. identité fédérée

Les deux sont liés mais opèrent à des échelles différentes. Le SSO simplifie la connexion au sein d'un seul domaine organisationnel, permettant à un utilisateur d'accéder à de nombreuses applications avec un seul jeu d'identifiants. La gestion des identités fédérées (FIM, Federated Identity Management) étend cette confiance au-delà des frontières organisationnelles, permettant un accès sécurisé aux ressources détenues par différentes entreprises ou services sans identifiants séparés pour chacune, en utilisant des standards comme SAML et OAuth pour établir une confiance inter-domaines. Le SSO se concentre sur la facilité d'accès au sein d'un domaine ; le FIM se concentre sur l'interopérabilité entre les domaines.

SSO vs. MFA en un coup d'œil

Que rechercher dans un prestataire SSO

Lors de l'évaluation de solutions SSO, plusieurs capacités méritent attention :

• Fonctionnalités de sécurité : Intégration du MFA, authentification basée sur le risque et politiques granulaires par application selon le groupe d'utilisateurs, la localisation et la posture de l'appareil.
• Largeur d'intégration : Prise en charge des applications cloud et sur site existantes et des protocoles courants comme SAML et OIDC.
• Facilité d'utilisation : Un tableau de bord clair et personnalisable et un déploiement rapide.
• Scalabilité : Haute disponibilité et accords de niveau de service (SLA) solides.
• Qualité du support : Disponibilité pour le déploiement et le dépannage.
• Souveraineté des données et conformité : Notamment pour les organisations européennes et réglementées, des certifications comme SOC 2 et ISO confirment où et comment les données d'identité sont traitées.

Regard d'expert : le SSO est un contrôle d'accès et un signal de détection de premier ordre

Le SSO est un contrôle d'accès préventif : il décide qui entre. C'est essentiel, mais il concentre aussi les risques dans un seul jeu d'identifiants, et les attaquants le savent. Une part croissante des intrusions est basée sur les identités, utilisant des identifiants SSO valides, le détournement de session ou des attaques par fatigue MFA, ce qui signifie que la connexion paraît légitime au système SSO même quand elle ne l'est pas. La prévention seule ne peut pas détecter cela. La détection et la réponse sur les signaux d'identité le peuvent, et c'est là qu'un déploiement SSO a besoin d'une couche d'opérations de sécurité derrière lui.

Sekoia traite la télémétrie d'identité et de SSO comme une source de détection de premier ordre plutôt qu'une case à cocher. Les journaux SSO et IdP, les échecs de connexion, les événements de déplacement impossible, les comportements de session inhabituels et les anomalies MFA font partie des plus de 300 intégrations alimentant la plateforme SOC unifiée Sekoia.

Au sein de Sekoia Defend, ces événements d'identité sont corrélés avec les données d'endpoints, de réseau et de cloud et mis en correspondance avec près de 1 000 règles de détection mappées sur MITRE ATT&CK, y compris les techniques d'accès aux identifiants et de comptes valides qui correspondent exactement à la façon dont le SSO est abusé. Les détections sont enrichies par la Cyber Threat Intelligence (CTI) native Sekoia Intelligence d'une équipe interne de Threat Detection & Research (TDR) qui suit activement les attaques basées sur les identités, ce qui maintient les faux positifs à un niveau bas.

En tant qu'éditeur européen, Sekoia associe cela à une posture de souveraineté des données que les grands prestataires d'identité américains égalent rarement, et à une réponse automatisée aux incidents capable de désactiver une session compromise en quelques minutes. Déployez le SSO avec le MFA pour contrôler les accès, mais mettez la détection et la réponse derrière lui, car un identifiant SSO volé est une clé pour tout.

‍

Questions fréquentes