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

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

L'authentification unique (Single Sign-On, SSO) permet de se connecter une fois et d'utiliser plusieurs applications reliées sans se réauthentifier. Un fournisseur d'identité (IdP), comme Okta, Microsoft Entra ID, Google Workspace ou Auth0, vérifie l'utilisateur. Chaque application, le fournisseur de service (SP), s'appuie sur la confirmation signée de l'IdP au lieu de demander son propre mot de passe. Le SSO est courant en entreprise car il remplace de nombreux mots de passe par une seule connexion gérée.

Comment fonctionne le SSO

Le déroulement est semblable d'un protocole à l'autre :

1. L'utilisateur clique sur « Se connecter » dans l'application.
2. L'application redirige le navigateur vers l'IdP avec une demande d'authentification.
3. L'IdP authentifie l'utilisateur : mot de passe, MFA, règles liées à l'appareil ou au lieu.
4. L'IdP émet un jeton signé (assertion ou ID token) qui indique qui est l'utilisateur, souvent avec e-mail, nom et groupes.
5. Le navigateur revient vers l'application avec le jeton.
6. L'application vérifie la signature avec la clé publique de l'IdP et ouvre sa propre session.

Pour l'utilisateur, ce sont quelques redirections. S'il a déjà une session chez l'IdP, il peut ne voir aucune page de connexion.

Les principaux protocoles SSO : SAML, OIDC et OAuth

SAML 2.0

Un standard fondé sur XML, annoncé par OASIS en mars 2005. Les assertions sont signées avec des certificats X.509. Il est verbeux et plus difficile à déboguer que les options récentes, mais très répandu dans les logiciels d'entreprise. Plus de détails dans qu'est-ce que SAML.

OpenID Connect (OIDC)

Une couche d'identité légère au-dessus d'OAuth 2.0. L'application reçoit un ID token, un JSON Web Token signé portant des informations d'identité. Il repose sur JSON et se met en œuvre plus facilement, d'où son adoption par de nombreux produits récents.

OAuth 2.0

OAuth est un cadre d'autorisation : il répond à « cette application peut-elle accéder à ces données ? », pas à « qui est cet utilisateur ? ». On le confond avec le SSO parce que les redirections se ressemblent. OIDC ajoute la couche d'identité standard qui fait de ce flux une vraie authentification. Les jetons d'accès émis par OAuth sont généralement envoyés comme bearer token.

Connexion initiée par le SP ou par l'IdP

• Initiée par le SP : l'utilisateur ouvre d'abord l'application, est redirigé vers l'IdP, puis revient. C'est le flux le plus courant.
• Initiée par l'IdP : l'utilisateur part du portail d'applications de l'IdP et clique sur la vignette de l'application ; l'IdP envoie une assertion que l'application n'avait pas demandée. C'est pratique, mais cela demande plus de vigilance car l'application doit accepter une assertion non sollicitée.

Pourquoi le SSO peut renforcer la sécurité

• MFA centralisée. L'authentification forte s'impose une fois chez l'IdP plutôt que dans chaque application.
• Un seul endroit pour retirer les accès. Désactiver le compte IdP d'une personne qui part coupe l'accès à toutes les applications reliées.
• Moins de réutilisation de mots de passe. Une connexion gérée remplace de nombreux mots de passe.
• Une seule piste d'audit. Connexions et tentatives échouées apparaissent dans les journaux de l'IdP.

La contrepartie est la concentration : l'IdP devient une dépendance critique et une cible de choix ; protégez-le par la MFA et gardez un accès de secours en dehors du SSO. Le SSO ne décide pas non plus de ce que l'utilisateur a le droit de faire ; c'est l'autorisation, gérée par des rôles dans l'application (voir le contrôle d'accès basé sur les rôles et la gestion des identités et des accès).

Erreurs fréquentes avec le SSO

• Décalage d'horloge. Les assertions SAML portent les horodatages NotBefore et NotOnOrAfter ; si les horloges de l'IdP et du SP dérivent au-delà de la tolérance, la connexion échoue. Synchronisez les deux par NTP.
• Certificats de signature expirés. Les certificats SAML expirent. Surveillez la date et renouvelez-les avant.
• Mauvaise correspondance des groupes. Si les groupes de l'IdP ne sont pas associés à des rôles de l'application, les utilisateurs se retrouvent avec de mauvais droits après une migration.
• Pas de plan de provisionnement. Sans provisionnement à la volée ni SCIM, un administrateur crée chaque utilisateur à la main et les départs gardent des comptes obsolètes.
• Croire que la déconnexion unique fonctionne. Se déconnecter d'une application ne met souvent fin ni à la session de l'IdP ni à celles des autres applications.
• Durées de session différentes. Une longue session IdP face à une courte session applicative provoque des reconnexions constantes.

SSO, identité fédérée et OAuth

• Le SSO est l'expérience utilisateur : une connexion, plusieurs applications. Le terme ne dit rien de la mise en œuvre.
• L'identité fédérée est la relation de confiance qui permet à un IdP et à un SP d'organisations différentes d'accepter mutuellement leurs identités.
• OAuth 2.0 délègue l'accès à des données ; seul, il n'établit pas qui est l'utilisateur.
• OIDC ajoute à OAuth un ID token avec des informations d'identité.

Questions fréquentes sur le Single Sign-On (SSO)

Quelle différence entre SSO et gestionnaire de mots de passe ?

Un gestionnaire de mots de passe stocke un identifiant distinct pour chaque application et le saisit. Le SSO supprime le mot de passe par application : celle-ci s'appuie sur la vérification de l'IdP. Le SSO exige que chaque application le prenne en charge ; un gestionnaire fonctionne avec n'importe quel formulaire.

SAML ou OIDC ?

Pour une nouvelle intégration, OIDC est en général plus simple à construire et à déboguer. De nombreux clients d'entreprise et fournisseurs d'identité exigent encore SAML, c'est pourquoi les produits destinés aux grandes organisations prennent souvent les deux en charge.

Qu'est-ce que la « taxe SSO » ?

C'est la pratique consistant à facturer bien plus cher une offre qui inclut le SSO. Le site sso.tax recense les éditeurs concernés.

Qu'est-ce que SCIM et quel rapport avec le SSO ?

SCIM (System for Cross-domain Identity Management) automatise la création, la mise à jour et la suppression des comptes entre l'IdP et les applications. Le SSO gère la connexion ; SCIM, le cycle de vie des comptes.

Que se passe-t-il si le fournisseur d'identité tombe ?

Les utilisateurs ne peuvent plus se connecter aux applications qui en dépendent, sauf s'ils ont déjà une session valide. Pour les applications critiques, gardez au moins un compte administrateur local de secours hors SSO.

Tester la charge d'une application derrière un SSO

LoadFocus lui-même ne propose pas de SSO SAML ni OIDC : on se connecte avec e-mail et mot de passe ou avec Google, et l'on invite ses collègues avec un accès complet ou en lecture seule. Le SSO compte pour l'application que vous testez. Une vraie connexion SSO passe par des pages du fournisseur d'identité qu'un test de charge ne doit pas saturer. La pratique courante consiste à obtenir un jeton une fois depuis un client de test, par exemple avec le flux OAuth client credentials sur un tenant de test, et à l'envoyer dans l'en-tête Authorization. Voir tests de charge OAuth 2.0 et tester des applications protégées par OAuth avec JMeter ; les tests s'exécutent avec les tests de charge LoadFocus, y compris des scripts JMeter.