Authentification unique

L’authentification unique (SSO) se produit lorsque l’utilisateur se connecte à une application et est ensuite automatiquement connecté à d’autres applications, indépendamment de la plateforme, de la technologie ou du domaine utilisés par l’utilisateur. L’utilisateur se connecte une seule fois, d’où le nom de la fonctionnalité (authentification unique).

Par exemple, si vous vous connectez à un service Google tel que Gmail, vous êtes automatiquement authentifié sur YouTube, AdSense, Google Analytics et d’autres applications Google. De même, si vous vous déconnectez de votre application Gmail ou d’autres applications Google, la déconnexion s’effectue sur toutes les applications. Cette opération est connue sous le nom de Déconnexion unique.

L’authentification unique (SSO) offre une expérience transparente aux utilisateurs lorsqu’ils utilisent vos applications et services. Au lieu de devoir se souvenir d’identifiants distincts pour chaque application ou service, les utilisateurs peuvent simplement se connecter une fois et accéder à l’ensemble de vos applications.

Lorsque les utilisateurs accèdent à un domaine qui nécessite une authentification, ils sont redirigés vers le domaine d’authentification où ils peuvent être invités à se connecter. Si l’utilisateur est déjà connecté sur le domaine d’authentification, il peut être immédiatement redirigé vers le domaine d’origine sans avoir à se connecter à nouveau.

L’authentification unique et la déconnexion unique sont possibles grâce à l’utilisation de sessions. Il peut y avoir jusqu’à trois sessions différentes pour un utilisateur avec la SSO :

• Session locale maintenue par l’application,

• Serveur d’autorisations :, si l’authentification unique (SSO) est activée

• Fournisseur d’identité (IdP), si l’utilisateur choisit de se connecter via un fournisseur d’identité (tel que Google, Facebook ou un fournisseur d’identité SAML d’entreprise)

Avec l’authentification unique (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 différer entre les protocoles SSO, mais le concept général reste le même.

Par exemple, le domaine d’authentification peut générer un jeton Web JSON (JWT) signé (chiffré à l’aide du chiffrement Web JSON [JWE]), qui contient toutes les informations nécessaires pour identifier l’utilisateur pour tout autre domaine nécessitant une authentification. Ce jeton est transmis au client, mais parce qu’il est signé, il ne peut être modifié d’aucune manière par le client. Le jeton peut être transmis au domaine d’origine par une redirection et utilisé par le domaine d’authentification et tout autre domaine pour identifier l’utilisateur.

La manière la plus simple et la plus sécurisée pour implémenter l’authentification unique (SSO) avec Auth0 est d’utiliser la connexion universelle pour l’authentification. Actuellement, la SSO n’est possible que sur les plateformes natives (comme iOS ou Android) si l’application utilise la connexion universelle. Les démarrages rapides Swift et Android fournissent quelques exemples d’utilisation de la connexion universelle.

Si vous ne pouvez pas utiliser la connexion universelle avec votre application, consultez ce qui suit pour plus d’informations sur l’authentification intégrée :

• Lock

• Auth0.js

Pour l’authentification unique (SSO) avec Auth0, le Service central est le serveur d’autorisation 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 pour voir s’il existe un témoin SSO.

3. Parce qu’il s’agit de la première fois que l’utilisateur visite la page de connexion et que le témoin SSO est présent, il sera demandé à l’utilisateur de se connecter en utilisant l’une des connexions que vous avez configurées.

   

4. Une fois que l’utilisateur est connecté, Auth0 va définir un témoin SSO et rediriger l’utilisateur vers votre application, renvoyant un jeton d’ID contenant des informations sur l’identité de l’utilisateur.

Examinons un exemple du flux SSO lorsque qu’un utilisateur retourne sur votre site Web pour une visite ultérieure :

1. Votre application redirige l’utilisateur vers la page de connexion.

2. Auth0 vérifie pour voir s’il existe un témoin SSO.

3. Auth0 trouve le témoin SSO et, si nécessaire, le met à jour. Aucun écran de connexion ne s’affiche.

4. Auth0 redirige l’utilisateur vers votre application en renvoyant un jeton d’ID qui contient des informations sur l’identité de l’utilisateur.

Vous pouvez vérifier l’état SSO d’un utilisateur depuis une application faisant appel à la méthode checkSession de la trousse SDK auth0.js qui tentera d’authentifier silencieusement l’utilisateur dans un iframe. Que l’authentification soit réussie ou non indique si l’utilisateur a un témoin SSO actif.

Le Security Assertion Markup Language (SAML) et le Web Services Federation (WS-Fed) sont deux 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 principales parties de cet échange sont l’utilisateur, le fournisseur d’identité et le fournisseur de services.

Avec SAML et WS-Fed :

1. Un utilisateur demande une ressource auprès du fournisseur de services.

2. Le fournisseur de services vérifie auprès du fournisseur d’identité si l’utilisateur devrait avoir accès à la ressource.

3. Le fournisseur d’identité vérifie l’identité de l’utilisateur, et si elle est valide, il l’affirme au fournisseur de services que l’utilisateur devrait avoir accès.

OpenID Connect (OIDC) est un protocole d’authentification couramment utilisé dans les implémentations d’authentification unique (SSO) orientées vers le consommateur. Le protocole OIDC gère l’authentification via des jetons Web JSON (JWT) et un fournisseur d’identité central.

Avec OIDC :

1. Un utilisateur demande l’accès à une application.

2. L’application redirige l’utilisateur au fournisseur d’identité pour l’authentification.

3. Le fournisseur d’identité vérifie l’utilisateur. Si la vérification est réussie, il invite ce dernier à accorder l’accès aux données de l’application.

4. Si l’accès est accordé, le fournisseur d’identité génère un jeton d’ID qui contient les informations d’identité de l’utilisateur que l’application peut consommer.

5. Le fournisseur d’identité redirige l’utilisateur vers l’application.

Le protocole d’accès au répertoire léger (LDAP) est un protocole d’application utilisé pour accéder à un répertoire de références pouvant être partagé par plusieurs applications : il est couramment utilisé par 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 demande d’authentification au serveur LDAP/AD. Le protocole LDAP échange des informations dans le format d’échange de données LDAP (LDIF).

En ce qui concerne la SSO initiée par le fournisseur de services, Auth0 est le fournisseur de services de la SSO.

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é avec lequel s’authentifier et se connecte.

3. Lorsqu’une connexion est réussie, l’utilisateur est renvoyé à l’application.

L’authentification unique (SSO) initiée par le fournisseur de services (SP) dans Auth0 est gérée par les connexions.

En ce qui concerne la SSO initiée par le fournisseur d’identité, un fournisseur d’identité tiers (IdP) est le fournisseur de la 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. Lorsqu’une connexion est réussie, l’utilisateur est renvoyé à l’application.

Lors de la planification d’une implémentation SSO initiée par le fournisseur d’identité (IdP), vous pouvez choisir d’utiliser l’extension Dashboard à authentification unique, qui vous permet de créer un tableau de bord répertoriant plusieurs applications d’entreprise qui peuvent être activées pour la SSO. Ce tableau de bord est ensuite présenté à vos utilisateurs pour qu’ils puissent se connecter.

Pour les scénarios de commerce interentreprises (C3E), l'authentification unique (SSO) peut simplifier l'intégration de votre application pour une utilisation en entreprise. Avec Auth0, vos applications peuvent prendre en charge des scénarios de fédération d’entreprise courants, tels que Active Directory (AD), Lightweight Directory Access Protocol (LDAP), Ping ou Security Assertion Markup Language (SAML). Cela permet à vos partenaires et clients Enterprise de se connecter avec leurs technologies d’identité d’entreprise préférées.

• Étude de cas : O’Reilly

Pour les scénarios entreprises à consommateur (C3E) ou de gestion de l’identité 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 via des fournisseurs d’identité sociale populaires tels que Google, Facebook, LinkedIn, X et Microsoft, au lieu de leur demander de créer un autre compte.

• Étude de cas : Giving Compass

• Authentification unique initiée par le fournisseur de services
• Authentification unique initiée par le fournisseur d’identité
• Points de terminaison d’API pour l’authentification unique
• Dépanner des configurations SAML
• Vérifier les connexions