Skip to main content
Avec Auth0, vous pouvez offrir aux utilisateurs plusieurs méthodes d’authentification. C’est important pour les applications SaaS ou multi-locataires, où de nombreuses organisations utilisent une seule application. Chaque organisation peut utiliser des systèmes différents, comme LDAP, Active Directory, Google Workspace ou des répertoires de noms d’utilisateur et de mots de passe. Dans Auth0, vous pouvez associer différentes connexions (méthodes d’authentification) à des applications précises, ou directement à un tenant (comme les connexions au niveau du domaine). Lorsqu’un utilisateur se connecte, il faut sélectionner la connexion à utiliser.
Home Realm Discovery dans Lock
La sélection du approprié parmi plusieurs options s’appelle “Home Realm Discovery”. Si vous utilisez au plus une connexion de base de données et aucune ou plusieurs connexions sociales, le processus de sélection est simple. L’utilisateur devra soit :
  • cliquer sur l’un des boutons de fournisseurs d’identité sociaux (p. ex., “Se connecter avec Google”)
  • saisir son adresse courriel et son mot de passe (ce qui signifie “J’utiliserai la connexion de base de données”).
Mais si l’application ou le tenant a d’autres types de connexion activés (comme des connexions d’entreprise ou plusieurs bases de données), le processus de sélection peut être plus complexe. Comment indiquer qu’un utilisateur veut utiliser une connexion de base de données précise si plusieurs sont activées ? Que faire si un utilisateur veut utiliser une connexion d’entreprise pour se connecter au moyen de (SSO) ? Si vous implémentez une interface de connexion personnalisée, vous avez un contrôle total sur le flux d’authentification. Vous pouvez choisir la connexion en fonction du contexte (comme l’adresse courriel fournie) ou en le demandant à l’utilisateur, puis transmettre le paramètre connection à l’une des méthodes de connexion d’Auth0.js.

Lock et plusieurs connexions

Lock comprend une fonctionnalité intégrée de sélection du fournisseur d’identité. Pour les connexions sociales, il affiche les logos de toutes celles qui sont activées pour une application donnée. Il affiche aussi des champs de nom d’utilisateur/adresse courriel et de mot de passe si une connexion de base de données ou une connexion Active Directory est activée. Vous ne verrez un bouton de connexion que s’il s’agit de la seule connexion activée pour l’application (dans l’expérience Classic Universal Login). Sinon, vous devrez utiliser une interface utilisateur personnalisée ou le nouveau Universal Login, qui permet d’avoir un bouton pour chaque connexion sociale et d’entreprise activée.

Utilisation des domaines de courriel avec les connexions d’entreprise

Une fonctionnalité supplémentaire de Lock est l’utilisation des domaines de courriel pour acheminer les requêtes d’authentification. Les connexions d’entreprise dans Auth0 peuvent être mappées à des domains. Par exemple, lors de la configuration d’ADFS ou d’un fournisseur d’identité -P :
Configuration des fournisseurs d’identité ADFS ou SAML-P
Si des domaines sont mappés à une connexion, le champ de saisie du mot de passe est automatiquement désactivé lorsqu’un utilisateur saisit une adresse courriel associée à un domaine mappé.
Écran de connexion avec domaine mappé
Dans l’exemple ci-dessus, le domaine auth0.com a été mappé à une connexion d’entreprise. Notez que vous pouvez associer plusieurs domaines à une seule connexion.

Sélection parmi plusieurs connexions de base de données

Si votre application a plusieurs connexions de base de données activées, Lock doit savoir laquelle utiliser. Vous pouvez fournir une option connectionResolver, à laquelle on passe une fonction qui détermine la connexion à utiliser selon la saisie de l’utilisateur et le contexte. Dans cet exemple, une autre connexion de base de données est utilisée si le domaine du courriel est “auth0.com” :
Vous pouvez utiliser l’option defaultDatabaseConnection pour préciser la connexion de base de données qui sera utilisée par défaut.

Filtrer les connexions disponibles par programmation

L’option allowedConnections dans Lock vous permet d’indiquer lesquelles des connexions disponibles doivent être proposées à l’utilisateur. Vous pouvez ainsi adapter l’expérience en fonction de renseignements supplémentaires ou du contexte (p. ex. « Cliquez ici pour vous connecter en tant qu’étudiant, ou ici pour vous connecter en tant que membre du corps professoral »). Notez que vous pouvez aussi fournir l’option allowedConnections à la méthode lock.show() s’il n’est pas idéal de la fournir lors de l’instanciation pour votre cas d’usage. Veuillez consulter la documentation de l’API de la méthode show pour en savoir plus.

Envoi de l’information de realm à partir de l’application

Il arrive que l’application qui demande une authentification sache d’avance quel realm l’utilisateur compte utiliser. Par exemple, une application multilocataire peut utiliser des URL sous la forme suivante : https://{customer}.yoursite.com ou https://www.yoursite.com/{customer}. Lorsqu’un utilisateur arrive dans votre application au moyen de l’URL personnalisée, vous pouvez récupérer cette valeur tenant et la transmettre comme login_hint dans la requête authorize : https://{yourDomain}/authorize?client_id=[...]&login_hint={customer} login_hint est un indice destiné au (Auth0) pour indiquer ce que l’utilisateur pourrait utiliser pour se connecter. Dans ce cas-ci, selon l’URL où l’utilisateur a abouti, nous traitons « customer » comme le realm. Le code par défaut de la page de connexion hébergée l’utilise pour préremplir le champ de courriel dans Lock, mais nous pouvons modifier le code pour changer la connexion de base de données par défaut à utiliser si un realm est fourni au lieu d’une véritable adresse courriel :
Le code ci-dessus n’est, bien sûr, qu’un exemple. Vous pourriez étendre cette logique pour exclure les connexions sociales, ou pour définir une connexion par défaut à utiliser même si une adresse courriel est fournie dans login_hint. Associer le “client” à un realm est un choix de conception arbitraire pour cet exemple. Mais il est généralement préférable d’isoler les applications du concept concret de “connexion” utilisé dans Auth0 et d’utiliser plutôt le concept plus abstrait de “realm”, en effectuant au besoin un mapping de realm à connexion dans la page de connexion hébergée (où il est plus facile d’apporter des modifications, au besoin).