Fournisseur d’identité unique : Authentification

Découvrez l’authentification des utilisateurs par l’intermédiaire d’Organizations pour les architectures multilocataires.

Dans nos scénarios d’architecture, nous proposons des recommandations d’ordre général sur l’authentification B2B, y compris l’utilisation de Universal Login comme pratique exemplaire recommandée. Nous vous conseillons de les consulter en parallèle avec les recommandations présentées ici.

Pratique exemplaire

Bien que de nombreux flux de travail d’authentification soient pris en charge dans Auth0, les flux de travail qui utilisent Auth0 Universal Login sont considérés comme une pratique exemplaire, tant dans l’industrie que chez Auth0, puisqu’ils offrent une fonctionnalité et une sécurité optimales. Plus précisément, Universal Login offre l’authentification unique (SSO) prête à l’emploi et aide à atténuer des attaques comme l’hameçonnage et la bucket brigade ; pour cette raison, il devrait être privilégié partout où un utilisateur fournit des identifiants de mot de passe. Surtout, la nouvelle expérience Universal Login est aussi le seul mécanisme pris en charge lors de l’utilisation de la fonctionnalité Auth0 Organizations.

L’authentification des utilisateurs exige le traitement des informations d’identification du premier facteur. Que cela soit effectué par Auth0 ou par un fournisseur d’identité (IdP) tiers, lorsque vous utilisez la fonctionnalité Auth0 Organizations, vous devez aussi utiliser l’expérience Universal Login d’Auth0.

Auth0 ne prend en charge qu’un seul contexte d’utilisateur authentifié par tenant Auth0; les tenants ne peuvent pas passer sélectivement d’un contexte d’utilisateur authentifié à un autre. Un changement de contexte utilisateur a une incidence sur toute session SSO active, et cela s’applique aussi à la fonctionnalité Auth0 Organizations. Si des contextes par organisation sont absolument nécessaires, plusieurs tenants Auth0 devront alors être déployés en production. Comme l’utilisation de plusieurs tenants a des répercussions sur l’authentification unique (SSO), la gestion du profil utilisateur, entre autres, vous devriez y réfléchir soigneusement avant d’emprunter cette voie.

​

Connexion de base de données

Reprenons l’exemple de Hoekstra & Associates pour voir comment cette mise en œuvre de l’authentification peut se dérouler lorsqu’un utilisateur est authentifié au moyen d’une connexion de base de données Auth0; la plus grande partie du processus décrit est généralement prise en charge par le SDK Auth0 pertinent ou par la bibliothèque associée à votre pile technologique :

1. Jennifer, de Hoekstra & Associates, ouvre son navigateur et accède à l’instance de Travel0 Corporate Booking de Hoekstra & Associates.

   1. Si Jennifer a déjà un cookie de session avec l’instance de Travel0 Corporate Booking de Hoekstra & Associates, elle sera généralement déjà connectée au système, et nous nous arrêterons là. Pour en savoir plus, consultez Authentification unique.

2. L’instance Travel0 Corporate Booking de Hoekstra & Associates redirige vers le tenant Auth0 de Travel0 au moyen du flux de code d’autorisation (avec ou sans PKCE) en appelant le point de terminaison /authorize et en y transmettant des paramètres, généralement au moyen d’un Auth0 SDK ou d’une bibliothèque tierce :

   1. redirect_uri : https://hoekstra.corp.travel0.net/login/callback

   2. response_type : code

   3. state : paramètre state unique généré pour cette session

   4. scope : openid profile …

   5. tout scope OIDC supplémentaire nécessaire, selon les renseignements requis sur l’utilisateur.

   6. client_id : ID client associé à l’application créée dans le tenant Auth0 de Travel0 pour l’instance de Travel0 Corporate Booking de Hoekstra & Associates.

   7. organization : Auth0 Organization à utiliser. Lorsque l’organisation est connue à l’avance, une requête à /authorize peut inclure ce paramètre, qui est spécifié sous la forme organization=organization_id, où organization_id correspond à l’identifiant associé à la définition Auth0 Organization correspondante dans votre tenant Auth0. Vous pouvez aussi omettre le paramètre organization de la requête à /authorize et configurer votre tenant Auth0 pour inviter l’utilisateur à sélectionner l’organisation appropriée dans le cadre du premier facteur d’authentification. Pour en savoir plus, consultez Define Organization Behavior.

      Si le paramètre organization est inclus dans une requête vers le endpoint /authorize, il doit être utilisé de façon cohérente pendant toute la durée de la session avec Auth0. La fonctionnalité Organizations n’associe aucune organisation sélectionnée à la session SSO Auth0; par conséquent, si le paramètre est omis, l’utilisateur sera toujours invité à sélectionner l’organisation souhaitée.

3. Le tenant Auth0 Travel0 redirige vers /login pour recueillir les informations d’authentification de l’utilisateur. Si Jennifer a déjà une session Database avec Hoekstra & Associates, les étapes 3a et 4 seront ignorées. Pour en savoir plus, consultez l’authentification unique.

   1. La page Universal Login, que vous pouvez configurer pour y inclure des éléments d’image de marque propres à l’organisation, comme décrit dans Branding, s’affiche.

4. L’utilisateur saisit ses identifiants et clique sur login.

5. Le tenant Auth0 Travel0 vérifie les identifiants de l’utilisateur; s’ils sont valides, le pipeline Rules s’exécute. Les Rules peuvent être utilisées pour gérer le contrôle d’accès, comme décrit dans Authorization. Si les identifiants de l’utilisateur sont invalides, l’utilisateur sera invité à les saisir à nouveau.

   L’appartenance sera attribuée automatiquement si cette option est spécifiée. Pour en savoir plus, consultez Accorder une appartenance juste-à-temps à une connexion d’organisation. Pour une appartenance attribuée manuellement, la validation échouera si l’utilisateur n’est pas déjà membre de l’organisation.

6. Après l’authentification réussie du premier facteur et l’exécution des Rules, l’utilisateur est redirigé vers le redirect_uri (https://hoekstra.corp.travel0.net/login/callback) avec le state transmis à l’étape 2, ainsi qu’un code.

7. L’instance de Travel0 Corporate Booking de Hoekstra & Associates valide le state, puis envoie une requête au tenant Auth0 de Travel0 à l’adresse https://auth.travel0.net/oauth/token, en transmettant le code ainsi que son client id et son client secret en échange de l’ID Token. L’ID Token est ensuite utilisé pour générer une session pour https://hoekstra.corp.travel0.net.

8. L’instance de Travel0 Corporate Booking de Hoekstra & Associates affiche ensuite la page appropriée à l’utilisateur.

​

Connexion d’entreprise

L’authentification au moyen d’une Connexion d’entreprise suit un processus très semblable. En reprenant notre exemple de MetaHexa Bank, voyons comment cette mise en œuvre de l’authentification peut se dérouler pour un utilisateur authentifié au moyen de la Connexion d’entreprise de MetaHexa Bank. Encore une fois, la majeure partie du flux de travail décrit est généralement prise en charge par l’Auth0 SDK pertinent ou la bibliothèque associée à votre pile technologique.

1. Amintha de MetaHexa Bank ouvre son navigateur et accède à l’instance de Travel0 Corporate Booking de MetaHexa Bank.

   1. Si Amintha a déjà un témoin de session avec l’instance de Travel0 Corporate Booking de MetaHexa Bank, elle sera généralement déjà connectée au système, et nous nous arrêterons ici. Pour en savoir plus, consultez Authentification unique.

2. L’instance de Travel0 Corporate Booking de MetaHexa Bank redirige vers le tenant Auth0 de Travel0 à l’aide du flux Authorization Code (avec ou sans PKCE) en appelant le endpoint /authorize et en transmettant des paramètres, généralement au moyen d’un Auth0 SDK ou d’une bibliothèque tierce :

   1. redirect_uri : https://metahexa.corp.travel0.net/login/callback

   2. response_type : code

   3. state : state unique généré pour cette session

   4. scope : openid profile …

   5. tout scope OIDC supplémentaire nécessaire, selon les renseignements requis au sujet de l’utilisateur.

   6. client_id : ID client associé à l’application créée dans le tenant Auth0 de Travel0 pour l’instance de Travel0 Corporate Booking de MetaHexa Bank.

   7. organization : Auth0 organisation à utiliser. Lorsque l’organisation est connue à l’avance, une requête à /authorize peut inclure ce paramètre, qui est indiqué sous la forme organization=organization_id, où organization_id correspond à l’identifiant associé à la définition Auth0 organisation correspondante dans votre tenant Auth0. Sinon, vous pouvez omettre le paramètre organization de la requête à /authorize et configurer votre tenant Auth0 pour inviter l’utilisateur à sélectionner l’organisation appropriée dans le cadre de l’authentification du premier facteur. Pour en savoir plus, consultez Définir le comportement des organisations.

      Si le paramètre organization est inclus dans une requête au endpoint /authorize, il doit être utilisé de façon cohérente pendant toute session avec Auth0. La fonctionnalité Organizations n’associe aucune organisation sélectionnée à la session SSO Auth0; si le paramètre est omis, l’utilisateur sera donc toujours invité à sélectionner l’organisation souhaitée.

   8. connection : Nom de la Connexion d’entreprise Auth0 configurée pour MetaHexa Bank.

      Bonne pratique

      Fournissez toujours le paramètre connection. S’il n’est pas fourni, l’utilisateur est invité à sélectionner la Connexion d’entreprise associée au fournisseur d’identité en amont (IdP), ce qui ajoute une étape du point de vue de l’expérience utilisateur.

3. Le tenant Auth0 de Travel0 redirige vers l’IdP de MetaHexa pour authentifier les informations d’identification du premier facteur.

   1. La page de connexion s’affiche, et l’utilisateur saisit ses informations d’identification. Si Amintha a déjà une session avec l’IdP de MetaHexa, les étapes 3a et 4 seront ignorées. Pour en savoir plus, consultez Authentification unique (SSO).

4. L’utilisateur saisit ses informations d’identification et clique sur login.

5. Une fois l’authentification du premier facteur réussie, le pipeline Rules s’exécute. Les Rules peuvent être utilisées pour gérer le contrôle d’accès comme décrit dans Authorization. Si les informations d’identification de l’utilisateur ne sont pas valides, l’utilisateur sera invité à les saisir de nouveau.

L’appartenance sera attribuée automatiquement si cette option a été spécifiée. Pour en savoir plus, consultez Accorder une appartenance juste-à-temps à une connexion d’organisation. Pour une appartenance attribuée manuellement, la validation échouera si l’utilisateur n’est pas déjà membre de l’organisation.

Les étapes 6 à 8 correspondront à celles décrites dans le scénario de la connexion de base de données, sauf qu’Amintha sera l’utilisatrice au lieu de Jennifer, et que MetaHexa Bank (metahexa.corp.travel0.net) sera utilisée à la place de Hoekstra & Associates.

​

Connexion sociale

L’authentification par une connexion sociale suit un modèle semblable à celui d’une Connexion d’entreprise, sauf que l’IdP en amont est associé au fournisseur social plutôt qu’à une organisation en particulier.

Les connexions sociales Auth0 sont définies au niveau du tenant. En règle générale, une seule connexion sociale est configurée par fournisseur social dans un tenant Auth0, puisqu’elle s’applique à l’ensemble du tenant Auth0. Par conséquent, tout consentement accordé par un utilisateur s’appliquera à toutes les organisations Auth0 définies dans un tenant Auth0, et non à une organisation particulière.

Avec les connexions sociales, l’isolation des utilisateurs ne peut pas être modélisée de manière cohérente pour chaque organisation. Même s’il peut être tentant de modéliser l’isolation des utilisateurs en créant plusieurs connexions pour un fournisseur social, par exemple au moyen de connexions sociales personnalisées, vous devriez éviter de le faire; une telle stratégie peut entraîner la création du même ID utilisateur dans plusieurs définitions de connexion, ce qui finira inévitablement par causer des problèmes.