Skip to main content
(SSO) se produit lorsqu’un utilisateur se connecte à une application, puis est automatiquement connecté à d’autres applications, peu importe la plateforme, la technologie ou le domaine utilisé. L’utilisateur ne se connecte qu’une seule fois, d’où le nom de cette fonctionnalité (authentification unique). Par exemple, si vous vous connectez à un service Google comme Gmail, vous êtes automatiquement authentifié sur YouTube, AdSense, Google Analytics et d’autres applications Google. De même, si vous vous déconnectez de Gmail ou d’autres applications Google, vous êtes automatiquement déconnecté de toutes les applications; c’est ce qu’on appelle le Single Logout. Le SSO offre une expérience fluide aux utilisateurs de vos applications et services. Au lieu d’avoir à mémoriser des information d’authentification distincts pour chaque application ou service, les utilisateurs peuvent simplement se connecter une seule fois et accéder à l’ensemble de votre suite d’applications. Chaque fois que des utilisateurs accèdent à un domaine qui exige une authentification, ils sont redirigés vers le domaine d’authentification, où il peut leur être demandé de se connecter. Si l’utilisateur est déjà connecté au domaine d’authentification, il peut être redirigé immédiatement vers le domaine d’origine sans avoir à se reconnecter.

​
Avantages

Pourquoi utiliser le SSO d’Auth0 ?
  • Accès unifié : Les utilisateurs s’authentifient une seule fois pour accéder à toutes les applications indépendantes et connexes sans avoir à saisir de nouveau leur information d’authentification.
  • Session centralisée : Auth0 utilise un domaine central et des cookies de navigateur pour partager l’état d’authentification entre plusieurs applications.
  • Universal Login : L’utilisation d’Universal Login d’Auth0 est une façon sécurisée de mettre en œuvre le SSO sur toutes les plateformes.

​
Fonctionnement

L’authentification unique et le Single Logout sont possibles grâce à l’utilisation de sessions. Un utilisateur peut avoir jusqu’à trois sessions différentes avec le SSO :
  • Session locale maintenue par l’application
  • Session de l’, si le SSO est activé
  • Session de l’, si l’utilisateur a choisi de se connecter par l’entremise d’un (comme Google, Facebook ou un fournisseur d’identité d’entreprise)
Avec le SSO, un domaine central effectue l’authentification, puis partage la session avec d’autres domaines. La façon dont une session est partagée peut varier selon les protocoles SSO, mais le concept général reste le même. Par exemple, le domaine d’authentification peut générer un JSON Web Token (JWT) signé (chiffré au moyen de JSON Web Encryption (JWE)), qui contient tous les renseignements nécessaires pour identifier l’utilisateur auprès de tout autre domaine exigeant une authentification. Ce jeton est transmis au client, mais comme il est signé, le client ne peut le modifier d’aucune façon. Le jeton peut être renvoyé au domaine d’origine au moyen d’une redirection, puis utilisé par le domaine d’authentification et tout autre domaine pour identifier l’utilisateur.

​
SSO avec Universal Login

La façon la plus simple et la plus sécuritaire d’implémenter l’authentification unique (SSO) avec Auth0 est d’utiliser Universal Login pour l’authentification. En fait, à l’heure actuelle, le SSO n’est possible sur les plateformes natives (comme iOS ou Android) que si l’application utilise . Les guides de démarrage rapide Swift et Android fournissent quelques exemples d’utilisation d’Universal Login. Si vous ne pouvez pas utiliser Universal Login avec votre application, consultez les ressources suivantes pour obtenir plus de renseignements sur l’authentification intégrée :
Si vous utilisez Passwordless avec l’authentification unique, les paramètres de connection sms et email n’utilisent pas la session Auth0 existante, et l’utilisateur sera invité à se connecter.

​
SSO lors de la première connexion

Pour le SSO avec Auth0, le service central est le d’Auth0. Examinons un exemple de flux SSO lorsqu’un utilisateur se connecte pour la première fois :
  1. Votre application redirige l’utilisateur vers la page de connexion.
  2. Auth0 vérifie s’il existe déjà un cookie SSO.
  3. Comme c’est la première fois que l’utilisateur visite la page de connexion et qu’aucun cookie SSO n’est présent, l’utilisateur devra se connecter à l’aide de l’une des connexions que vous avez configurées.
    Exemple d’écran de connexion de l’application Timesheets
  4. Une fois que l’utilisateur s’est connecté, Auth0 créera un cookie SSO et redirigera l’utilisateur vers votre application, en renvoyant un ID Token contenant les renseignements d’identité de l’utilisateur.

​
SSO lors des connexions ultérieures

Examinons un exemple du processus SSO lorsqu’un utilisateur revient sur votre site Web pour une visite ultérieure :
  1. Votre application redirige l’utilisateur vers la page de connexion.
  2. Auth0 vérifie s’il existe déjà un cookie SSO.
  3. Auth0 trouve le cookie SSO et, au besoin, le met à jour. Aucun écran de connexion n’est affiché.
  4. Auth0 redirige l’utilisateur vers votre application en renvoyant un ID Token qui contient des renseignements sur l’identité de l’utilisateur.

​
Vérifier l’état SSO d’un utilisateur

Vérifiez l’état SSO d’un utilisateur depuis une application en appelant la méthode checkSession du SDK auth0.js, qui tentera d’authentifier silencieusement l’utilisateur dans un iframe. Le succès ou l’échec de l’authentification indique si l’utilisateur a un cookie SSO actif.

​
Protocoles

​
SAML et WS-Federation

Security Assertion Markup Language (SAML) et Web Services Federation () sont deux protocoles largement utilisés dans les mises en œuvre du SSO. SAML et WS-Fed échangent tous deux des données d’autorisation et d’authentification au format XML; les principaux éléments de cet échange sont l’utilisateur, le fournisseur d’identité et le fournisseur de services. Avec SAML ou WS-Fed :
  1. Un utilisateur demande une ressource au fournisseur de services.
  2. Le fournisseur de services vérifie auprès du fournisseur d’identité si l’utilisateur est autorisé à accéder à la ressource.
  3. Le fournisseur d’identité vérifie l’identité de l’utilisateur et, si elle est valide, confirme au fournisseur de services que l’utilisateur est autorisé à accéder à la ressource.

​
OpenID Connect

Connect (OIDC) est un protocole d’authentification couramment utilisé dans les mises en œuvre de SSO destinées au grand public. Le protocole OIDC gère l’authentification au moyen de et d’un fournisseur d’identité central. Avec OIDC :
  1. Un utilisateur demande à accéder à une application.
  2. L’application redirige l’utilisateur vers le fournisseur d’identité pour s’authentifier.
  3. Le fournisseur d’identité vérifie l’identité de l’utilisateur et, si l’authentification réussit, l’invite à autoriser l’application à accéder aux données.
  4. Si l’accès est accordé, le fournisseur d’identité génère un ID Token, qui contient des renseignements sur l’identité de l’utilisateur que l’application peut exploiter.
  5. Le fournisseur d’identité renvoie l’utilisateur vers l’application.

​
AD/LDAP

Lightweight Directory Access Protocol (LDAP) est un protocole d’application utilisé pour accéder à un annuaire d’informations d’authentification pouvant être partagé par plusieurs applications; il est couramment utilisé dans les intranets. Lorsqu’il est associé à Active Directory (AD), LDAP fournit un emplacement centralisé pour l’identité de l’utilisateur, de sorte que l’application envoie une requête d’authentification au serveur LDAP/AD. Le protocole LDAP échange des informations au format LDAP Data Interchange Format (LDIF).

​
SSO initié par le fournisseur de services

Pour le SSO initié par le fournisseur de services, Auth0 agit comme fournisseur de services (SP) du SSO. Lorsqu’un utilisateur se connecte à une application :
  1. L’application propose à l’utilisateur un ou plusieurs fournisseurs d’identité externes.
  2. L’utilisateur sélectionne un fournisseur d’identité pour s’authentifier, puis se connecte.
  3. Une fois l’authentification réussie, l’utilisateur est redirigé vers l’application.
Dans Auth0, le SSO initié par le fournisseur de services est géré par les connexions.

​
SSO initié par le fournisseur d’identité

Pour le SSO initié par le fournisseur d’identité, un fournisseur d’identité (IdP) tiers agit comme fournisseur SSO. Lorsqu’un utilisateur se connecte à une application :
  1. L’application redirige l’utilisateur vers un fournisseur d’identité.
  2. Le fournisseur d’identité tiers effectue l’authentification et l’autorisation.
  3. Une fois l’authentification réussie, l’utilisateur est redirigé vers l’application.
Lors de la planification de la mise en œuvre d’un SSO initié par l’IdP, vous pouvez choisir d’utiliser la SSO Dashboard Extension d’Auth0, qui vous permet de créer un tableau de bord présentant plusieurs applications d’entreprise pouvant être activées pour le SSO. Ce tableau de bord est ensuite présenté à vos utilisateurs afin qu’ils puissent se connecter.

​
SSO initié par le fournisseur de services ou par le fournisseur d’identité

Le choix entre le SSO initié par le fournisseur de services et celui initié par le fournisseur d’identité dépend principalement du point de départ souhaité pour le parcours utilisateur et du niveau de sécurité requis. Nous recommandons le SSO initié par le fournisseur de services lorsque vous avez besoin d’authentification dans les cas suivants :
  • Accès direct : Utilisez cette option lorsque les utilisateurs ajoutent généralement la page de connexion de votre application à leurs favoris ou y accèdent directement.
    • Sécurité renforcée : Cette option est plus sécurisée, car elle utilise un « ID de requête » précis pour établir une corrélation entre la requête de connexion et la réponse, ce qui protège contre la falsification de requêtes intersites (CSRF) et les attaques par rejeu.
    • Liens profonds : Utilisez cette option si vous devez rediriger les utilisateurs vers une page précise de votre application après leur connexion.
Le SSO initié par le fournisseur d’identité est courant dans de nombreuses entreprises et est souvent utilisé dans les cas suivants :
  • Portails d’entreprise : Utilisez cette option si vos utilisateurs commencent leur journée dans un tableau de bord centralisé (comme Okta, Microsoft 365 ou un intranet d’entreprise) et sélectionnent une icône pour lancer votre application.
    • Simplification de l’expérience utilisateur : Cette option évite à l’utilisateur final de devoir d’abord visiter la page de connexion de votre application ; les utilisateurs finaux accèdent ainsi à votre application déjà authentifiés.
    • Systèmes existants : Cette option est souvent utilisée lors de l’intégration à des systèmes d’entreprise plus anciens basés sur SAML qui ne prennent pas en charge les fonctionnalités de redirection modernes.

​
Cas d’utilisation

​
Business to Business SSO

Dans les scénarios Business to Business (B2B), le SSO peut faciliter la commercialisation de votre application auprès des entreprises. Avec Auth0, vos applications peuvent prendre en charge des scénarios courants de fédération d’entreprise, comme Active Directory (AD), Lightweight Directory Access Protocol (LDAP), Ping ou Security Assertion Markup Language (SAML). Cela permet à vos partenaires et à vos clients d’entreprise de se connecter à l’aide des technologies d’identité d’entreprise de leur choix.

​
Business to Consumer CIAM

Pour les scénarios Business to Consumer (B2C) ou de Customer Identity Access Management (CIAM), le SSO peut offrir un accès fluide à vos applications ou services. Vous pouvez permettre aux clients de s’authentifier au moyen de fournisseurs d’identité sociaux populaires, comme Google, Facebook, LinkedIn, X et Microsoft, plutôt que de les obliger à créer un nouveau compte.