Vos équipes jonglent avec dix mots de passe, en oublient la moitié et multiplient les tickets de réinitialisation. L'authentification unique, ou SSO (Single Sign-On), répond à ce désordre en centralisant l'accès à toutes vos applications derrière une seule identité. Voici comment elle fonctionne vraiment, ce qu'elle change pour la sécurité, et comment l'intégrer à une application métier.

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

Le SSO permet à un utilisateur de se connecter une seule fois pour accéder à plusieurs applications, sans ressaisir ses identifiants à chaque service. Concrètement, l'application ne vérifie plus elle-même le mot de passe : elle délègue cette vérification à un fournisseur d'identité (IdP) central, comme Microsoft Entra ID (ex-Azure AD), Google Workspace ou Keycloak, une brique open source que l'on peut auto-héberger. L'application fait confiance au jeton signé que l'IdP lui renvoie.

Le bénéfice est double : l'utilisateur retient une seule authentification, et l'entreprise reprend la main sur les accès depuis un point unique. Quand un salarié part, on désactive un seul compte et toutes les applications se ferment d'un coup.

Le SSO n'est pas « un seul mot de passe »

C'est la confusion la plus fréquente. Le SSO ne consiste pas à utiliser le même mot de passe partout, ce qui serait un risque majeur. Il s'agit d'une fédération d'identité : le mot de passe n'est connu que du fournisseur d'identité, jamais des applications. Ces dernières ne stockent aucun secret utilisateur. En cas de fuite sur une application, aucun mot de passe n'est exposé, car il n'y en a pas.

Les trois protocoles à connaître

Trois standards se partagent l'essentiel des intégrations, et le bon choix dépend du besoin :

  • SAML 2.0 : historique, très répandu dans les logiciels d'entreprise et les portails web internes.
  • OAuth 2.0 : gère l'autorisation, c'est-à-dire l'accès délégué à des ressources (par exemple une API), plus que l'identité elle-même.
  • OpenID Connect (OIDC) : bâti au-dessus d'OAuth 2.0, il ajoute la couche d'identité. C'est aujourd'hui le choix par défaut pour une nouvelle application web ou mobile.

Pour une application métier moderne, OpenID Connect est le plus simple à mettre en oeuvre et le mieux outillé. SAML reste utile quand l'IdP ou un logiciel tiers ne parle que ce langage.

SSO et sécurité : pourquoi ajouter l'authentification forte

Centraliser l'accès crée un point unique : si le compte central est compromis, toutes les applications le sont. La parade n'est pas d'éviter le SSO, mais de renforcer le fournisseur d'identité avec l'authentification forte (MFA), qui exige un second facteur en plus du mot de passe. L'ANSSI recommande le double facteur sur les accès sensibles, et de nombreux assureurs cyber en font désormais une condition d'indemnisation pour les comptes à privilèges. Coupler SSO et MFA donne le meilleur des deux mondes : moins de mots de passe pour l'utilisateur, une barrière plus haute pour l'attaquant.

Le provisioning : ouvrir et couper les accès automatiquement

Le SSO gère la connexion, mais pas la création des comptes. Pour cela, le standard SCIM synchronise automatiquement les utilisateurs entre votre annuaire et vos applications : une arrivée crée les accès, un départ les révoque partout, sans intervention manuelle. C'est un point souvent négligé qui, seul, justifie souvent le projet : il supprime les comptes orphelins, principale porte d'entrée oubliée après le départ d'un collaborateur.

Intégrer le SSO dans une application métier sur-mesure

Une application développée sur-mesure s'intègre nativement à votre IdP via OpenID Connect, sans dépendre d'un module tiers rigide. On raccorde l'application à Entra ID, Google ou Keycloak, on associe les rôles applicatifs aux groupes de l'annuaire, et l'accès suit automatiquement l'organisation. Pour les services destinés à des citoyens ou usagers du secteur public, l'intégration de FranceConnect repose sur les mêmes principes. Chez Pulsar Forge, nous concevons vos applications métier avec le SSO et la gestion des rôles pensés dès la conception, plutôt qu'ajoutés après coup.

Questions fréquentes

Le SSO est-il moins sécurisé puisqu'un seul accès ouvre tout ?

Non, à condition de protéger le fournisseur d'identité par l'authentification forte (MFA). Le SSO réduit la surface d'attaque en supprimant les mots de passe dispersés et réutilisés, souvent bien plus vulnérables qu'un accès central correctement sécurisé.

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

Un gestionnaire de mots de passe stocke et remplit des identifiants distincts pour chaque site. Le SSO supprime ces identifiants multiples : l'application ne vérifie plus de mot de passe, elle fait confiance à une identité centrale vérifiée par le fournisseur d'identité.

Peut-on ajouter le SSO à une application déjà développée ?

Oui, dès lors que l'application peut intégrer une bibliothèque OpenID Connect ou SAML. Le chantier consiste à déléguer la connexion à l'IdP et à faire correspondre les comptes existants aux identités centrales, sans perdre les données des utilisateurs.

Combien de temps pour intégrer le SSO à une application métier ?

Pour une application prête à recevoir OpenID Connect, comptez souvent de quelques jours à deux semaines, selon la gestion des rôles et le provisioning SCIM. Une application ancienne au modèle d'authentification figé demande davantage de travail préparatoire.

Parlons de votre projet : nous auditons votre parc applicatif et branchons le SSO là où il fait gagner du temps et de la sécurité.