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 renseignements 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.

​
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

Vous pouvez vérifier 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.

​
Cas d’utilisation

​
Business to Business

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.