Passer au contenu principal
(SSO) a lieu 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 la déconnexion unique. Le SSO offre une expérience fluide aux utilisateurs lorsqu’ils utilisent vos applications et services. Au lieu d’avoir à retenir des identifiants différents pour chaque application ou service, les utilisateurs peuvent simplement se connecter une seule fois et accéder à l’ensemble de vos applications. Chaque fois que les 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é sur le domaine d’authentification, il peut être redirigé immédiatement vers le domaine d’origine sans avoir à se reconnecter.

​
Fonctionnement

L’authentification unique (SSO) et la déconnexion unique sont possibles grâce aux sessions. Un utilisateur ayant recours au SSO peut avoir jusqu’à trois sessions différentes :
  • Session locale maintenue par l’application
  • Session du , si le SSO est activé
  • Session du , si l’utilisateur a choisi de se connecter par l’intermédiaire 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 manière dont une session est partagée peut varier selon les protocoles SSO, mais le principe général reste le même. Par exemple, le domaine d’authentification peut générer un JSON Web Token (JWT) signé (chiffré à l’aide de JSON Web Encryption (JWE)), qui contient toute l’information nécessaire pour identifier l’utilisateur auprès de tout autre domaine nécessitant une authentification. Ce jeton est transmis à l’application, mais comme il est signé, l’application ne peut le modifier d’aucune façon. Le jeton peut être transmis 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 de mettre en œuvre l’authentification unique (SSO) avec Auth0 consiste à 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 ce qui suit pour obtenir plus de renseignements sur l’authentification intégrée :
Si vous utilisez Passwordless avec l’authentification unique, les paramètres de connexion sms et email n’utilisent pas la session Auth0 existante, et l’utilisateur devra se connecter.

​
SSO à la première connexion

Pour le SSO avec Auth0, le service central est le d’Auth0. Voici un exemple du 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.
    Écran de connexion d’une application de feuilles de temps
  4. Une fois l’utilisateur connecté, Auth0 définira 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 flux SSO lorsqu’un utilisateur revient sur votre site Web plus tard :
  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 informations sur l’identité de l’utilisateur.

​
Vérifier le statut SSO de l’utilisateur

Vous pouvez vérifier le statut SSO d’un utilisateur depuis une application en appelant la méthode checkSession du SDK auth0.js, qui tentera d’authentifier l’utilisateur en mode silencieux dans une 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 tous deux des protocoles largement utilisés dans les implémentations de 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 peut 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 peut y accéder.

​
OpenID Connect

Connect (OIDC) est un protocole d’authentification couramment utilisé dans les implémentations 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 l’authentifier.
  3. Le fournisseur d’identité vérifie l’utilisateur et, si l’authentification réussit, lui demande d’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 informations sur l’identité de l’utilisateur que l’application peut exploiter.
  5. Le fournisseur d’identité redirige l’utilisateur vers l’application.

​
AD/LDAP

Lightweight Directory Access Protocol (LDAP) est un protocole applicatif utilisé pour accéder à un annuaire d’identifiants pouvant être partagé par plusieurs applications; il est couramment utilisé dans les intranets. Lorsqu’il est associé à Active Directory (AD), LDAP fournit un point centralisé pour l’identité des utilisateurs, et l’application envoie alors une demande 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 est le fournisseur de services SSO (SP). Lorsqu’un utilisateur se connecte à une application :
  1. L’application présente à 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 SP est géré par des 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 de 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 d’une mise en œuvre de SSO initié par l’IdP, vous pouvez choisir d’utiliser la SSO Dashboard Extension, qui vous permet de créer un tableau de bord répertoriant plusieurs applications d’entreprise pouvant être activées pour le SSO. Ce tableau de bord est ensuite présenté à vos utilisateurs pour qu’ils puissent s’y connecter.

​
Cas d’usage

​
Entre entreprises

Dans les scénarios entre entreprises (B2B), le SSO peut simplifier l’adaptation de votre application aux besoins 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 SAML. Cela permet à vos partenaires et à vos clients d’entreprise de se connecter à l’aide des technologies d’identité d’entreprise de leur choix.

​
CIAM Business-to-Consumer

Dans les scénarios Business-to-Consumer (B2C), ou de gestion des identités et des accès des clients (CIAM), l’authentification unique (SSO) peut offrir un accès sans friction à vos applications ou services. Vous pouvez permettre aux clients de s’authentifier au moyen de fournisseurs d’identité populaires de réseaux sociaux, comme Google, Facebook, LinkedIn, X et Microsoft, plutôt que de les obliger à créer un nouveau compte.