Authentification unique (SSO) : définition et fonctionnement

L'authentification unique (SSO) permet de se connecter une fois pour accéder à plusieurs applications. Fonctionnement, protocoles SAML et OpenID Connect, solutions du marché et erreurs à éviter.

L’authentification unique, ou SSO (Single Sign-On), permet de se connecter une seule fois, avec un seul compte, pour accéder à plusieurs applications sans ressaisir ses identifiants. Un service central, le fournisseur d’identité, vérifie qui vous êtes puis le confirme à chaque application. Le SSO simplifie la vie des utilisateurs et centralise le contrôle des accès, mais il concentre aussi le risque : il doit toujours être protégé par une authentification multifacteur.

Voici comment fonctionne le SSO, les protocoles qui le rendent possible (SAML, OpenID Connect), les solutions du marché, et la manière de l’intégrer dans vos outils ou dans une application que vous faites développer.

Qu’est-ce que l’authentification unique ?
Comment fonctionne le SSO ?
Quels protocoles utilise le SSO ?
Quels sont les avantages et les risques ?
Quelles solutions de SSO existent ?
Comment ajouter le SSO à une application ou un SaaS ?
Quelles erreurs éviter ?
Questions fréquentes
Sources

Qu’est-ce que l’authentification unique ?

Sans SSO, chaque logiciel gère ses propres comptes : un identifiant pour la messagerie, un autre pour le CRM, un autre pour l’outil de paie. Avec le SSO, un seul compte, géré par un fournisseur d’identité (en anglais Identity Provider, ou IdP), ouvre l’accès à toutes les applications qui lui font confiance. Ces applications sont appelées fournisseurs de services (Service Providers, ou SP).

Vous utilisez sans doute déjà le SSO. Le bouton « Se connecter avec Google » ou « Se connecter avec Microsoft » sur un site en est une forme. Côté administration française, FranceConnect permet d’accéder à plus de 1 500 services en ligne avec un compte existant (impots.gouv.fr, ameli.fr, l’Identité Numérique La Poste, France Identité, entre autres).

Trois notions voisines sont souvent confondues :

Utiliser le même mot de passe partout n’est pas du SSO : c’est une mauvaise pratique, car une seule fuite compromet tous les comptes.
Un gestionnaire de mots de passe retient et remplit des mots de passe différents pour chaque site. Il est complémentaire du SSO, pas concurrent (voir notre comparatif des meilleurs gestionnaires de mots de passe).
La fédération d’identité est la relation de confiance entre deux organisations, qui permet par exemple aux salariés d’une entreprise d’accéder à l’application d’un partenaire avec leur propre compte. C’est le socle technique du SSO entre organisations.

Comment fonctionne le SSO ?

Le principe est le même quelle que soit la solution. Microsoft le résume en quatre étapes :

L’utilisateur demande l’accès : il ouvre une application.
Redirection : l’application le renvoie vers le fournisseur d’identité.
Vérification : le fournisseur d’identité contrôle ses identifiants (et son second facteur, si la MFA est activée).
Accès accordé : le fournisseur d’identité confirme l’identité à l’application, sous la forme d’un jeton signé, et l’application ouvre la session.

Lorsque l’utilisateur ouvre ensuite une deuxième application, la redirection a lieu à nouveau, mais comme sa session est déjà ouverte chez le fournisseur d’identité, il n’a rien à ressaisir. L’application ne voit jamais le mot de passe : elle reçoit seulement une confirmation signée, avec quelques informations (identifiant, adresse e-mail, groupes ou rôles).

Quels protocoles utilise le SSO ?

Pour que le fournisseur d’identité et les applications se comprennent, ils s’appuient sur des standards ouverts.

Protocole	Format	Usage typique
SAML 2.0	XML, standard OASIS depuis mars 2005	Applications web d’entreprise, logiciels SaaS professionnels
OpenID Connect (OIDC)	JSON, jetons JWT, bâti sur OAuth 2.0	Applications web modernes, applications mobiles, API, « Se connecter avec… »
OAuth 2.0	RFC 6749 et 6750 de l’IETF (2012)	Autorisation d’accès à des API, pas l’authentification seule
SSO par mot de passe	Identifiants stockés et rejoués par le fournisseur	Anciennes applications qui ne gèrent aucun standard

Pour un nouveau développement, OpenID Connect est en général le plus simple à intégrer avec les frameworks actuels. SAML reste très répandu dans les grandes organisations. Beaucoup d’éditeurs de logiciels proposent les deux pour satisfaire tous leurs clients.

Attention à une confusion fréquente : OAuth 2.0 sert à autoriser une application à accéder à des ressources pour le compte d’un utilisateur. C’est OpenID Connect, construit par-dessus, qui ajoute la vérification d’identité.

Quels sont les avantages et les risques ?

Les avantages

Moins de mots de passe : les utilisateurs ont moins d’identifiants à retenir, donc moins de mots de passe faibles ou réutilisés.
Moins de support : moins de demandes de réinitialisation de mot de passe.
Un contrôle centralisé : quand un salarié quitte l’entreprise, on désactive un seul compte et tous ses accès tombent en même temps.
Des règles homogènes : MFA, restrictions par pays ou par appareil s’appliquent partout, depuis un seul endroit.
Un argument commercial pour les éditeurs : les grandes entreprises exigent souvent le SSO avant d’adopter un logiciel.

Les risques

Un point unique de compromission : si le compte SSO est volé, toutes les applications sont exposées. D’où l’importance de la MFA, que l’ANSSI recommande de privilégier, en favorisant les facteurs de possession (clé de sécurité, application d’authentification).
Un point unique de panne : si le fournisseur d’identité est indisponible, plus personne ne se connecte. Prévoyez des comptes d’urgence et une procédure.
Une configuration délicate : un certificat expiré ou une URL de retour mal réglée bloque l’accès, et une erreur de configuration peut ouvrir une faille.

Quelles solutions de SSO existent ?

Le choix dépend surtout de l’endroit où vivent déjà vos comptes utilisateurs.

Microsoft Entra ID : c’est le nouveau nom d’Azure Active Directory depuis juillet 2023. Si votre entreprise utilise Microsoft 365, vous l’avez déjà. Il gère SAML, OpenID Connect et le SSO par mot de passe, et propose un portail « Mes applications » où l’utilisateur retrouve tous ses outils.
Google Workspace : pour les entreprises dont les comptes sont chez Google, il peut servir de fournisseur d’identité pour d’autres applications.
Les plateformes spécialisées (Okta et d’autres) : pensées pour relier de nombreuses applications, quel que soit l’environnement.
Keycloak : une solution open source à héberger soi-même, qui gère OpenID Connect, OAuth 2.0 et SAML. Keycloak est un projet en incubation à la Cloud Native Computing Foundation.

Et AD FS ? Active Directory Federation Services est la solution de fédération historique de Microsoft, installée sur les serveurs de l’entreprise. Elle permet de partager des identités entre organisations partenaires à l’aide de jetons contenant des « revendications » (claims) sur l’utilisateur. Microsoft publie aujourd’hui une documentation détaillée pour migrer l’authentification des applications d’AD FS vers Microsoft Entra ID, en commençant par celles qui utilisent SAML ou OpenID Connect. Pour un nouveau projet, on part donc plutôt sur une solution cloud.

Comment ajouter le SSO à une application ou un SaaS ?

Deux situations se présentent.

Vous voulez un SSO pour vos propres salariés

Faites l’inventaire des applications utilisées et des protocoles qu’elles acceptent (SAML, OIDC, aucun).
Choisissez le fournisseur d’identité, en général celui où sont déjà vos comptes (Microsoft ou Google).
Activez la MFA pour tous les comptes avant de brancher les applications.
Connectez d’abord une application pilote sur un petit groupe, puis étendez.
Organisez les accès par rôles et par groupes, pas par personne.

Ce dernier point, déjà souligné dans la première version de cet article, reste essentiel : chaque personne ne doit accéder qu’aux données nécessaires à sa fonction, avec des droits distincts en lecture, écriture ou suppression. C’est une bonne pratique de sécurité et une application directe du principe de minimisation du RGPD pour les données personnelles stockées dans un CRM ou un outil RH.

Vous éditez une application utilisée par d’autres entreprises

Si vous vendez un logiciel en ligne à des entreprises, il s’agit en général d’une application multi-locataire : une seule application sert plusieurs clients (les « locataires »), chacun ayant l’impression qu’elle est la sienne, parfois avec son logo et ses couleurs, comme dans un logiciel en marque blanche. Pour l’éditeur, cette architecture mutualise la surveillance, la maintenance et les sauvegardes.

Ajouter le SSO dans ce contexte consiste à permettre à chaque client de brancher son propre fournisseur d’identité. Concrètement :

prévoir OpenID Connect et, pour les grands comptes, SAML ;
associer chaque locataire à son fournisseur d’identité (souvent à partir du domaine de l’adresse e-mail) ;
créer automatiquement le compte utilisateur à la première connexion et lui attribuer un rôle selon les groupes transmis ;
conserver une connexion classique pour les petits clients sans SSO ;
journaliser les connexions pour pouvoir enquêter en cas d’incident.

Il est rarement utile de coder ces protocoles soi-même : on s’appuie sur une bibliothèque éprouvée ou sur un service d’identité. Si vous développez un outil métier ou un portail client et voulez intégrer le SSO dès la conception, ce besoin fait partie de notre offre d’applications web sur mesure. Pour les autres aspects de la sécurité, lisez notre article sur la sécurité des applications web.

Quelles erreurs éviter ?

Déployer le SSO sans MFA : on concentre les accès sans renforcer la porte d’entrée.
Oublier la déconnexion : fermer une application ne ferme pas toujours la session chez le fournisseur d’identité. Vérifiez le comportement de déconnexion et la durée des sessions.
Laisser des comptes locaux actifs : si les anciens identifiants propres à chaque application restent valides, un départ de salarié ne coupe pas tout.
Ne pas surveiller les certificats : les certificats de signature SAML expirent ; notez leurs dates et prévoyez leur renouvellement.
Donner trop de droits par défaut : le SSO dit qui est l’utilisateur, pas ce qu’il a le droit de faire. Les rôles restent à définir dans chaque application.

Questions fréquentes

Quelle est la différence entre SSO et MFA ?

Le SSO réduit le nombre de connexions : un compte pour plusieurs applications. La MFA renforce chaque connexion en demandant une preuve supplémentaire (code, clé, notification). Les deux se combinent, et le SSO sans MFA est déconseillé.

Le SSO est-il plus sûr que des mots de passe séparés ?

Oui, s’il est bien configuré et protégé par la MFA : moins de mots de passe réutilisés, un contrôle centralisé et une révocation immédiate des accès. Mal protégé, il devient au contraire une cible de choix.

« Se connecter avec Google », c’est du SSO ?

Oui, c’est une forme de SSO destinée au grand public, qui repose sur OpenID Connect. Google joue le rôle de fournisseur d’identité pour le site sur lequel vous vous connectez.

Azure AD et Microsoft Entra ID, est-ce la même chose ?

Oui. Microsoft a renommé Azure Active Directory en Microsoft Entra ID en juillet 2023, sans changement de fonctionnalités ni de prix. Active Directory (sur serveur) et AD FS gardent leur nom.

Une PME a-t-elle besoin du SSO ?

Dès qu’une équipe utilise plusieurs outils en ligne, oui, et c’est souvent déjà inclus dans l’abonnement Microsoft 365 ou Google Workspace. Le travail consiste surtout à brancher les applications et à activer la MFA.

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

Qu’est-ce que l’authentification unique ?

Comment fonctionne le SSO ?

Quels protocoles utilise le SSO ?