L’authentification unique (SSO, Single Sign-On) permet aux utilisateurs de s’authentifier une seule fois auprès d’un fournisseur d’identité (IdP) centralisé et d’accéder à plusieurs applications sans avoir à saisir à nouveau leurs identifiants. Le SSO élimine le manque de rigueur en matière de mots de passe en transférant la responsabilité de l’authentification des applications individuelles à une autorité centrale qui maintient l’état d’authentification.

Lorsque vous vous authentifiez sur votre réseau d’entreprise et que vous accédez immédiatement à Slack, à GitHub ou à une base de connaissance interne sans avoir à saisir à nouveau les mots de passe pour chaque application, le SSO fonctionne exactement comme prévu.

L’implémentation du SSO offre des avantages immédiats et mesurables aux équipes sécurité et développement en centralisant le contrôle et en standardisant l’expérience d’authentification.

Centralisation de la sécurité et de la conformité

• Réduction de la surface d’attaque : la centralisation de l’authentification en un seul événement d’authentification principal réduit le nombre d’identifiants que les utilisateurs gèrent activement dans l’écosystème, ce qui contribue à réduire la surface d’attaque globale et le potentiel de compromission.
• Application de politiques cohérentes : le SSO permet d’appliquer des politiques d’authentification fortes, y compris l’authentification multifacteur (MFA), au niveau de l’IdP. Il n’est donc plus nécessaire d’implémenter des mesures redondantes sur des dizaines de systèmes.
• Auditabilité simplifiée : les journaux d’authentification centralisés simplifient la création de pistes d’audit et de reporting de conformité, offrant aux équipes sécurité une source fiable pour l’accès des utilisateurs dans l’ensemble de l’écosystème d’applications.

Amélioration de la vélocité et de l’expérience utilisateur

• Élimination de la redondance : pour les équipes de développement, le SSO élimine la nécessité d’implémenter et de maintenir la logique d’authentification dans chaque nouvelle application, ce qui permet aux développeurs de se concentrer sur les fonctionnalités essentielles.
• Réduction de la charge de support : l’adoption du SSO minimise le nombre de tickets adressés au service d’assistance pour les réinitialisations de mots de passe et les verrouillages de comptes, ce qui permet aux équipes de support de se concentrer sur des problèmes de plus grande valeur.
• Provisioning accéléré : l’onboarding et le déprovisioning des utilisateurs sont simplifiés, car l’accès à plusieurs systèmes est accordé ou révoqué par une seule action au sein du système d’identité central.

Le SSO fonctionne par le biais d’une série de redirections sécurisées, basées sur une session et fondées sur une relation de confiance cryptographique entre une application (le fournisseur de services) et l’IdP.

Le flux SSO de base

1. Demande initiale : un utilisateur tente d’accéder à une application protégée (fournisseur de services). Cette dernière, reconnaissant la demande non authentifiée, redirige le navigateur de l’utilisateur vers l’endpoint de connexion de l’IdP.
2. Authentification et session IdP : l’utilisateur s’authentifie auprès de l’IdP à l’aide de la méthode choisie (comme un mot de passe, une passkey ou un code biométrique). L’IdP valide l’identité, établit une session authentifiée et stocke un identifiant de session sécurisé (généralement dans un cookie HttpOnly avec attributs Secure et SameSite).
3. Émission de token : l’IdP redirige l’utilisateur vers le fournisseur de services avec un artefact de sécurité adapté à cette application.

• Pour le langage SAML (Security Assertion Markup Language) 2.0, spécifié par OASIS, cet artefact est une assertion XML signée contenant les revendications d’identité de l’utilisateur.
• Pour OpenID Connect (OIDC), tel que spécifié par l’OpenID Foundation, cela implique l’échange d’un code d’autorisation contre un token d’identification et un token d’accès, ainsi qu’un token d’actualisation facultatif, en fonction du type de client et de la configuration du champ d’application. Pour en savoir plus sur cette distinction, consultez Authentification ou autorisation.

4. Accès accordé : le fournisseur de services valide l’assertion ou le token en vérifiant sa signature, son expiration (exp), son caractère non antérieur (nbf), son émetteur (iss) et son audience (aud), et établit une session locale pour l’utilisateur.

Accès fluide ultérieur

Lorsque le même utilisateur, au cours de la même session de navigation, accède à une deuxième application qui fait confiance au même IdP :

1. La seconde application détecte la demande non authentifiée et redirige l’utilisateur vers l’IdP.
2. L’IdP détecte immédiatement la session authentifiée existante via son cookie de session.
3. L’IdP émet un nouveau token de sécurité spécifique à l’application sans demander à l’utilisateur de s’authentifier à nouveau.
4. L’utilisateur bénéficie d’un accès fluide à la seconde application.

Cette réutilisation de l’événement d’authentification central est le fondement technique du SSO.

Le SSO moderne repose sur des protocoles standardisés qui régissent l’échange de données d’identité et d’autorisation. Le choix du bon protocole (ou souvent la prise en charge des deux) est nécessaire pour assurer la flexibilité de l’intégration.

Protocole	Format de token	Cas d’usage principal	Complexité
SAML 2.0	Assertions XML	Fédération B2B d’entreprise, systèmes hérités	Plus verbeux ; nécessite la gestion de certificats X.509 pour la vérification de la signature et le chiffrement optionnel, y compris la rotation des certificats et la surveillance de l’expiration
OIDC	JSON Web Token (JWT)	Applications web, mobiles et pilotées par API modernes	Plus simple, RESTful et plus convivial pour les développeurs

• OIDC est la couche d’identité fonctionnant par-dessus OAuth 2.0. OIDC utilise des JWT signés pour les revendications d’identité dans les tokens d’identification et s’aligne nativement sur les architectures d’API. Pour les nouvelles applications mobiles ou accessibles via Internet, OIDC avec le flux de code d’autorisation et PKCE est la bonne pratique actuelle en matière de sécurité OAuth 2.0.
• SAML 2.0 reste prédominant pour la fédération B2B, en particulier lors de l’intégration avec l’infrastructure d’identités du client, comme les services de fédération Active Directory (AD FS), car il s’agit souvent d’une exigence obligatoire pour les grandes entreprises.

Dans un contexte SaaS B2B, l’application doit souvent prendre en charge les deux protocoles, car c’est l’IdP du client qui dicte les exigences d’intégration.

Dans le cadre du SaaS B2B, le SSO multitenant nécessite qu’une application (le fournisseur de services) se fédère avec l’IdP indépendant de chaque organisation cliente.

• Configuration spécifique au tenant : une application doit stocker et gérer en toute sécurité des métadonnées de configuration IdP uniques (telles que les certificats de signature SAML ou les secrets clients OIDC) pour chaque client.
• Home Realm Discovery (HRD) : l’application doit déterminer l’IdP du client à utiliser pour acheminer la demande d’authentification. Pour ce faire, l’application se base généralement sur le domaine de messagerie de l’utilisateur ou sur un identifiant d’organisation saisi avant la connexion.
• Provisioning JIT (Just in Time) : le processus crée automatiquement le compte local de l’utilisateur dans l’application pendant le flux d’authentification SSO initial, sur la base des revendications reçues de l’IdP. Cela élimine le provisionnement manuel des comptes d’utilisateurs pour les entreprises.
• Autorisation post-authentification : après une authentification SSO réussie, une application doit appliquer des politiques d’autorisation, telles que le contrôle d’accès basé sur les rôles (RBAC), afin de déterminer les ressources auxquelles l’utilisateur peut accéder. Le SSO confirme l’identité et la couche d’autorisation de l’application contrôle les autorisations.

Si le SSO centralise l’authentification, il consolide aussi les risques. Les développeurs doivent s’assurer que le fournisseur de services est renforcé contre les vulnérabilités liées aux tokens.

• Validation non négociable des tokens : chaque API endpoint protégée doit effectuer une validation JWT complète. Cela inclut la vérification de l’intégrité de la signature, le contrôle de la revendication exp, ainsi que la confirmation des revendications iss et aud afin de garantir que le token est authentique et destiné à votre application.
• Stockage sécurisé : évitez de stocker des tokens d’accès sensibles ou des tokens d’actualisation dans localStorage ou sessionStorage, car cela présente un risque élevé d’attaque XSS (Cross-Site Scripting). Pour les applications monopages, utilisez un stockage en mémoire avec rafraîchissement automatique. Pour les applications web traditionnelles, utilisez des cookies avec des attributs HttpOnly, Secure et SameSite.
• PKCE pour OIDC : utilisez toujours le flux de code d’autorisation avec PKCE (Proof Key for Code Exchange) pour toutes les applications basées sur OIDC, y compris les applications mobiles et web, afin de neutraliser les attaques d’interception de code d’autorisation.
• Tokens de courte durée : utilisez des tokens d’accès de courte durée (15 à 60 minutes maximum) et mettez en place une rotation des tokens d’actualisation. Chaque opération d’actualisation émet un nouveau token d’actualisation et invalide le précédent, ce qui permet de détecter immédiatement le vol de tokens.
• Prévention de la fixation de session : après avoir validé le token de l’IdP, le fournisseur de services doit régénérer immédiatement son identifiant de session local afin de prévenir les attaques par fixation de session. Cette responsabilité incombe au fournisseur de services (et non à l’IdP).

Manque de sécurisation de la session du fournisseur de services

Les fournisseurs de services valident souvent correctement le token de l’IdP, mais ne parviennent pas à sécuriser leur propre session d’application. Après l’authentification SSO, le fournisseur de services doit établir une session sécurisée avec un délai d’attente approprié, une protection CSRF et des attributs sécurisés de cookie.

Politiques inadéquates en matière de durée de vie des tokens

Accepter des sessions IdP de longue durée (plus de 24 heures) sans réauthentification crée un risque. Implémentez des délais de session appropriés et demandez une réauthentification avant les actions à haut risque en utilisant l’authentification renforcée.

Manque d’attention pour la complexité de la déconnexion

La déconnexion SSO nécessite une coordination entre l’IdP et tous les fournisseurs de services actifs. Des implémentations incomplètes laissent des sessions actives dans certaines applications après la déconnexion, ce qui crée un faux sentiment de sécurité. Mettez en place une déconnexion centralisée (Single Logout/SLO) ou une communication claire sur le comportement de la session.

Confiance dans les assertions de l’IdP sans validation

Les fournisseurs de services doivent valider chaque signature de token, chaque expiration, chaque audience et chaque revendication de l’émetteur. Sauter l’étape de validation parce que l’assertion « provient de notre IdP » est une vulnérabilité que les attaquants peuvent exploiter par la falsification de token ou des attaques par relecture.

Comment fonctionne le SSO avec les applications mobiles ?

Le SSO mobile utilise le protocole OIDC avec le flux de code d’autorisation et PKCE. Il exige le navigateur système (ASWebAuthenticationSession sur iOS, Custom Tabs sur Android) plutôt que des webviews intégrées. Le navigateur système partage le cookie de session de l’IdP entre les applications utilisant le même domaine d’authentification, ce qui permet un véritable SSO. Cependant, le comportement de partage de session varie en fonction de la plateforme et des paramètres de confidentialité. ASWebAuthenticationSession sur iOS crée des sessions éphémères par défaut, ce qui oblige les utilisateurs à activer la persistance de la session. Les webviews intégrées ne peuvent pas accéder au magasin de cookies du système et perturbent l’expérience SSO.

Le SSO est-il un substitut à l’authentification multifacteur (MFA) ?

Non. Le SSO détermine l’endroit où l’authentification a lieu (au niveau d’un IdP central). Le MFA détermine la force de l’authentification. Les entreprises doivent combiner les deux : appliquer le MFA au niveau de l’IdP central de sorte qu’une seule authentification forte protège l’accès à toutes les applications connectées.

Quand le SSO n’est-il pas le bon choix ?

La complexité du SSO et les exigences en matière d’infrastructure l’emportent souvent sur les avantages qu’il présente pour les petites applications grand public ou pour les sites de contenu simples. Le SSO offre en revanche une valeur maximale dans les environnements d’entreprise avec une gestion IT centralisée, où les utilisateurs ont besoin d’un accès cohérent à de multiples ressources sécurisées.

L’implémentation d’un SSO à partir de zéro, en particulier en prenant en charge à la fois SAML et OIDC, est une initiative complexe. L’utilisation d’une plateforme d’identité dédiée comme Auth0 peut aider à gérer la complexité du protocole, la gestion des sessions et le renforcement de la sécurité, ce qui permet aux développeurs de se concentrer sur les fonctions essentielles de l’application.

Explorez notre série d’articles « Introduction à l’IAM » pour en savoir plus sur la gestion des identités et des accès.

En savoir plus