Concevez l’authentification de votre application SaaS B2B Auth0 à l’aide d’Universal Login, de la découverte du domaine d’origine dans les Organizations, des connexions d’entreprise et de la MFA afin d’identifier de façon sécurisée les utilisateurs issus de plusieurs locataires clients.
Pour offrir des services à vos utilisateurs, vous devez être en mesure de les identifier. Ce processus s’appelle l’authentification des utilisateurs. Il existe plusieurs façons d’authentifier un utilisateur — via des comptes de médias sociaux, un nom d’utilisateur et mot de passe, — et il est souvent recommandé d’aller au-delà d’un premier facteur en activant l’ (MFA).
Il est important de tenir compte à la fois de la sécurité et de l’expérience utilisateur lors de la conception de votre méthode d’authentification. Proposer plusieurs facteurs principaux et/ou exiger plus d’un facteur lors de l’authentification sont des façons d’assurer les deux à la fois.
Plusieurs aspects méritent d’être pris en compte lorsque vous examinez les fonctionnalités et le workflow :
Où les utilisateurs saisiront-ils leurs identifiants ?
Comment protégerez-vous les identifiants des utilisateurs ?
Comment maintiendrez-vous votre système d’authentification ?
Comment pouvez-vous offrir une authentification par mot de passe à vos utilisateurs ?
Comment pouvez-vous empêcher des pirates informatiques de tenter de se connecter en tant que vos utilisateurs ?
Comment allez-vous implémenter l’authentification dans différents types d’applications ?
Comment faciliter la connexion pour vos utilisateurs qui proviennent de différents contextes linguistiques ?
Comment offrirez-vous une bonne expérience utilisateur lors de la migration depuis un système d’authentification existant ?
Que devez-vous prendre en compte lors de l’intégration d’applications avec Auth0 ?
Avez-vous besoin de mettre en place une authentification multifacteur ?
Que faire si vous avez un service qui ne permet pas à l’utilisateur de se connecter au préalable ?
Pouvez-vous transmettre le même d’une API à une autre ?
Que faire si vous devez isoler les utilisateurs par organisation ?
Comment gérerez-vous l’identification de l’organisation à laquelle appartiennent les utilisateurs ?
Quel est l’avantage de fournir des connexions d’entreprise pour vos organisations ?
Auth0 Universal Login offre aux utilisateurs une expérience sûre et sécurisée — que vous choisissiez de permettre la connexion par ID utilisateur/mot de passe ou d’autoriser les scénarios dits Bring Your Own Identity via la connexion sociale. La centralisation de l’expérience de connexion avec présente également des avantages sur le plan de la reconnaissance de l’image de marque, même si vous estimez avoir des exigences d’image de marque propres à chaque produit. Les widgets d’interface utilisateur Auth0 généralement utilisés avec Universal Login offrent aussi une prise en charge prête à l’emploi de l’internationalisation pour les utilisateurs ayant des besoins linguistiques variés, et la prise en charge intégrée des fonctionnalités Auth0 telles que la MFA et la protection contre les attaques vous permet de mettre en place des barrières pour empêcher les pirates d’accéder aux comptes de vos utilisateurs.Permettre aux utilisateurs de se connecter au moyen d’identifiants ID utilisateur/mot de passe signifie qu’ils ne dépendent pas du statut de fournisseurs d’identité pour accéder à votre système. Vous disposez également des moyens d’exiger que les identifiants utilisés respectent vos politiques d’entreprise. Auth0 vous aide à cet égard en vous offrant plusieurs options pour prendre en charge les connexions par ID utilisateur/mot de passe, et les directives fournies vous aideront à comprendre comment tirer parti de ces options. L’ajout d’une prise en charge sociale à un moment donné, comme facteur d’authentification principal supplémentaire, vous donne plus de flexibilité et peut vous aider à mieux comprendre vos utilisateurs sans avoir à leur poser d’autres questions, en tirant parti des renseignements déjà stockés par les différents fournisseurs de connexion sociale providers.Si vous disposez déjà d’un legacy identity store, vous voudrez aussi consulter User Migration. Cette section présente les avantages de migrer vers le identity storage géré par Auth0 sur le plan de la sûreté et de la sécurité.Pour les applications destinées aux clients, Connect (OIDC) est le protocole standard de l’industrie le plus couramment utilisé, et OIDC bénéficie d’une prise en charge de premier ordre dans Auth0. Auth0 offre du soutien pour différentes approches d’intégration de différentes applications; vous voudrez donc consulter la section sur l’intégration d’application pour obtenir l’information nécessaire afin de faire un choix éclairé.Lorsqu’on appelle une API à partir d’une autre API, ou dans toute situation où il n’y a pas de context d’utilisateur authentifié — par exemple, un ou plusieurs cron jobs, des générateurs de rapports ou des systèmes d’intégration/livraison continues —, vous aurez besoin d’un moyen d’autoriser l’application plutôt qu’un utilisateur. Il s’agit d’un processus en une seule étape où l’application est authentifiée (à l’aide d’un et d’un secret), puis autorisée en une seule requête. Vous pouvez en apprendre davantage à ce sujet dans notre flux de travail d’autorisation sous l’autorisation machine-to-machine (m2m).Les entreprises ont souvent besoin de séparer leurs utilisateurs par organisation, et il arrive parfois que certains utilisateurs aient accès à plus d’une organisation. Savoir lequel de ces scénarios s’applique à votre entreprise vous aidera à déterminer dans quelle connexion un utilisateur existe : si vous devez le faire, quand vous devez le faire et comment y parvenir. Consultez Home Realm Discovery pour déterminer si cela s’applique à votre entreprise.
Avez-vous, ou aurez-vous, plus d’une application dans votre système ? Si la réponse est oui, vous aurez avantage à offrir une expérience de connexion centralisée. Pour offrir une expérience fluide de (SSO) entre plusieurs applications, il est essentiel d’avoir un point centralisé vers lequel rediriger vos utilisateurs pour l’authentification. Cela vous permet d’offrir une expérience cohérente à vos utilisateurs si vous ajoutez plus tard l’authentification sociale, des applications tierces à votre système, ou l’authentification multifacteur comme option (ou exigence) pour vos utilisateurs — tout en vous permettant aussi de profiter de nouvelles fonctionnalités pour améliorer leur expérience avec peu, voire aucun, effort de développement supplémentaire.
Si vous avez plus d’une application, la bonne pratique consiste à rediriger l’utilisateur vers un emplacement centralisé pour l’authentifier. Avec Auth0, cela signifie tirer parti de Universal Login, qui offre de nombreux avantages en matière de sécurité et d’expérience utilisateur dès le départ, y compris le SSO.
Auth0 Universal Login fait de l’authentification des utilisateurs un processus simple et rapide, réalisable en trois étapes faciles (tous nos Quickstarts le démontrent, et nos SDKs en masquent aussi la complexité) :
Home Realm Discovery (HRD) est le processus qui consiste à déterminer à quel fournisseur d’identité (ou à quelle connexion dans Auth0) l’utilisateur appartient avant de l’authentifier. Il existe deux façons pour que la HRD se produise :
Prévoir un moyen de prendre la décision au niveau de l’application
Faire en sorte que Home Realm Discovery se produise sur la page de connexion Universal Login
Votre système peut devoir utiliser l’une ou l’autre de ces méthodes, ou les deux. Il est donc important de bien comprendre toutes les approches de la HRD afin de pouvoir appliquer celle(s) qui conviennent le mieux à vos applications.
Une façon courante de déterminer à quel realm un utilisateur appartient consiste à utiliser une application adaptée à l’image de marque de chaque organisation. Dans ce contexte, une organisation dispose généralement de sa propre instance de l’application, à laquelle on accède habituellement par une URL différente. Cette copie ou instance peut être isolée physiquement (en s’exécutant sur un ensemble distinct de serveurs) ou virtuellement (en s’exécutant sur des serveurs partagés), et est généralement indiquée soit par un nom d’hôte personnalisé (companyA.application1.yourcompany.com), soit par un chemin (application1.yourcompany.com/companyA).
Si votre application connaît déjà la connexion (IdP) précise requise, vous pouvez aussi la transmettre lorsque vous redirigez l’utilisateur vers /authorize, au moyen du paramètre de requête connection.
Si c’est le cas pour votre ou vos applications, la Home Realm Discovery consiste simplement à stocker le org_id dans la configuration de l’application propre à l’organisation et à l’envoyer comme paramètre organization lorsque vous redirigez l’utilisateur vers Universal Login. Cela limitera l’utilisateur à cette organisation précise et à l’ensemble de ses connexions configurées.
Si une organisation a besoin de plus d’un IdP, vous devrez peut-être effectuer une deuxième étape de Home Realm Discovery (une fois l’organisation identifiée). Auth0 gérera généralement cela pour vous si vous utilisez la fonctionnalité Organizations.
Si l’utilisateur est partagé entre plusieurs organisations à l’aide d’une seule identité, vous devez prendre en charge Home Realm Discovery sur la page Universal Login. Cela permettra à Universal Login d’identifier d’abord l’utilisateur, puis de présenter les realms appropriés pour cet utilisateur, ce qui offrira une meilleure expérience utilisateur.L’envoi des paramètres organization et/ou connection peut se faire en les ajoutant comme paramètres de requête lorsque vous redirigez l’utilisateur vers le point de terminaison /authorize. Pour en savoir plus, consultez la documentation de l’Authentication API. Toutefois, vous le ferez généralement à l’aide du SDK du langage dans lequel votre application est écrite.
Il existe trois grandes approches de Home Realm Discovery :
Découvrir le realm à partir du sous-domaine de l’adresse courriel de l’utilisateur.
Découvrir le realm en recherchant un identifiant utilisateur dans une table de correspondance entre identifiants et realms.
Permettre à l’utilisateur de choisir ou de saisir son realm (ou son organisation).
Dans les deux premiers cas, vous pouvez envisager d’utiliser « Identifier First Login ». Cela signifie que vous présentez d’abord uniquement un champ pour saisir un identifiant. Ensuite, vous recueillez l’identifiant de l’utilisateur et, en fonction de celui-ci, soit vous redirigez automatiquement l’utilisateur, soit vous lui permettez de saisir son mot de passe si aucune redirection n’est nécessaire. Auth0 fournit une mise en œuvre prête à l’emploi pour gérer tout cela grâce à Universal Login.
Bien qu’il soit possible d’implémenter Identifier First Login ou de permettre à un utilisateur de sélectionner son organisation dans l’application plutôt que sur la Universal Login Page, cela peut ajouter de la complexité sur le plan de l’authentification unique, ainsi que de la complexité liée à la reproduction de ce comportement dans toutes vos applications. Auth0 recommande plutôt d’implémenter une forme de HRD par Universal Login.
HRD par l’entremise de Universal Login à l’aide du sous-domaine de l’adresse courriel
La façon la plus simple d’implémenter la découverte du domaine d’origine sur la page Universal Login consiste à utiliser le sous-domaine de l’adresse courriel de l’identifiant de l’utilisateur pour le mapper à son fournisseur d’identité. Cela, bien sûr, ne fonctionne que lorsque le sous-domaine de l’adresse courriel correspond en 1:1 à une organisation ou, à tout le moins, à un fournisseur d’identité.Le widget Lock d’Auth0 ou Universal Login peut le faire pour vous si vous utilisez la correspondance de domaines dans une connexion d’entreprise; toutefois, si vous voulez le créer vous-même, c’est possible, mais vous devrez établir une correspondance entre le sous-domaine de l’adresse courriel et la connexion.De plus, lorsque vous utilisez l’expérience Universal Login, la fonctionnalité Organizations vous sera utile de deux façons :
Si vous n’avez pas transmis d’org_id à /authorize lorsque vous avez lancé la requête de connexion, Auth0 présentera à l’utilisateur une invite lui demandant de saisir l’organisation à laquelle il appartient.
Si l’organisation a plus d’un IdP qui lui est associé, Auth0 présentera à l’utilisateur des boutons pour choisir l’organisation ou un formulaire pour saisir un nom d’utilisateur et mot de passe.
HRD par Universal Login à l’aide du mappage des identifiants vers le realm
Une deuxième approche, plus complexe, consiste à stocker une correspondance entre les identifiants et l’IdP, puis à fournir un endpoint public pour accéder à cette information. Ensuite, sur la page Universal Login, vous pouvez trouver la connexion et rediriger vers /authorize avec cette connexion. Les principaux inconvénients de cette approche sont la latence et, plus important encore, les enjeux de sécurité liés à la découverte d’identifiants : si vous utilisez des adresses courriel, il devient beaucoup plus facile pour une personne malveillante de déterminer si une adresse courriel donnée correspond à l’un de vos utilisateurs.
Tout endpoint public devrait faire l’objet d’une limitation du taux de requêtes afin d’empêcher des pirates de l’utiliser pour découvrir des informations et pour prévenir les attaques par déni de service.
HRD par l’intermédiaire de Universal Login avec choix de l’utilisateur
L’autre possibilité consiste à permettre à vos utilisateurs de choisir dans une liste, si le fait de rendre publique la liste des organisations qui utilisent votre produit ne vous dérange pas, ou à leur permettre de saisir explicitement le nom de leur organisation. Cela se fait généralement avant de rediriger l’utilisateur vers Universal Login. Une fois que l’utilisateur vous a indiqué à quelle organisation il appartient, vous pouvez le rediriger vers Auth0 en précisant la connexion de cette organisation, ou laisser Auth0 lui demander simplement son nom d’utilisateur et mot de passe si la connexion est une connexion de base de données.
Authentification par nom d’utilisateur et mot de passe
Presque toutes les applications B2C permettent à leurs clients de créer un nouvel ensemble d’identifiants. Il s’agit d’une forme courante d’authentification que tous les utilisateurs connaissent bien.Chez Auth0, l’authentification par nom d’utilisateur et mot de passe se décline en plusieurs options. Si votre application part de zéro et ne compte aucun utilisateur existant, une simple Connexion de base de données prête à l’emploi d’Auth0 vous fournira tout ce qu’il faut pour commencer à authentifier vos utilisateurs. En revanche, si vous disposez d’un ancien répertoire d’utilisateurs (comme votre propre base de données d’utilisateurs ou un système LDAP existant), plusieurs options s’offrent à vous pour migrer vos utilisateurs, comme expliqué dans nos recommandations sur la migration des utilisateurs.Peu importe la façon dont vous provisionnez les utilisateurs pour votre connexion de base de données, leur authentification reste essentiellement la même. Vous devez leur présenter un formulaire dans lequel ils saisissent leur nom d’utilisateur et leur mot de passe. Comme il est indiqué dans les recommandations concernant Universal Login, la façon la plus simple et la plus sûre d’authentifier les utilisateurs avec un nom d’utilisateur et un mot de passe consiste à les rediriger vers une page de connexion centralisée, puis à y recueillir leur nom d’utilisateur et leur mot de passe. Auth0 peut ainsi déterminer s’ils se sont déjà authentifiés et ignorer complètement le formulaire de connexion lorsqu’il n’est pas nécessaire.
Le fait de recueillir les identifiants uniquement sur la page de connexion centralisée réduit les risques de fuite potentielle des secrets des utilisateurs. Cela permet également d’éviter de recueillir des identifiants inutilement. Consultez Universal Login pour en savoir plus.
Une fois que vous avez déterminé comment vous voulez authentifier vos utilisateurs, l’étape suivante consiste à définir comment cette authentification sera lancée. Chaque application aura généralement son propre point de départ.
Les applications mobiles natives (et les applications de bureau) devraient utiliser le navigateur système pour l’authentification, faute de quoi elles s’exposent à des risques de sécurité supplémentaires. Consultez Native Login pour en savoir plus.
Comme nous l’avons mentionné, nous avons constaté que la plupart de nos clients utilisent OpenID Connect (OIDC) comme protocole standard de l’industrie pour leurs applications destinées aux clients. Déterminer quel flux OIDC utiliser est votre première tâche, et vous voudrez commencer par consulter nos indications sur la correspondance des types d’autorisation.Si vous souhaitez permettre aux utilisateurs anonymes d’accéder à une partie de votre application, vous devez déterminer si vous allez les rediriger immédiatement ou seulement au besoin (ou peut-être une combinaison des deux; voir Redirect Users After Login pour en savoir plus). Si les utilisateurs peuvent accéder, au moyen d’un lien profond, à une version protégée (ou à une zone protégée) de votre site, vous devrez alors déterminer quels liens vers votre application entraîneront une redirection automatique vers Auth0.
Il est important de tenir compte de l’expérience utilisateur lorsqu’une personne arrive pour la première fois dans votre application. Si votre application prend en charge l’accès anonyme (ce qui est assez courant pour les applications de commerce électronique), différents scénarios sont à considérer :
Revient-elle dans l’application après s’être déjà connectée?
S’il s’agit de la première fois qu’elle accède à l’application :
A-t-elle déjà accédé à une autre application qui utilise le même tenant Auth0?
S’est-elle déjà authentifiée sur cet appareil ou dans ce navigateur, ou ne l’a-t-elle pas fait depuis longtemps?
Lorsqu’un utilisateur anonyme accède à votre application, il peut souvent être souhaitable que l’application détermine si l’utilisateur s’est déjà connecté à une autre application de la même famille, ou qu’elle se souvienne de cet utilisateur même si l’application est une SPA sans état. Par exemple, si vous pouvez déterminer que l’utilisateur est déjà connecté, vous pourriez décider que l’en-tête de l’interface utilisateur de l’application n’affiche pas de bouton de connexion et présente plutôt un menu de compte ou de profil. Pour y parvenir, vous devrez utiliser l’« authentification silencieuse ». L’authentification silencieuse vous permettra de vérifier si l’utilisateur est connecté sans lui demander de se connecter s’il ne l’est pas. L’application pourra alors afficher un bouton de connexion au besoin. Si l’utilisateur est déjà connecté, en revanche, vous recevrez des jetons et n’aurez pas à lui présenter de nouveau un bouton de connexion.
Vérifier l’existence d’une session de connexion en redirigeant vers Auth0 peut être utile pour votre application, mais si cela entraîne un grand nombre de requêtes, vous devriez mettre en place un mécanisme de limitation afin d’éviter la latence ou la limitation de débit.Les appels à la Management API sont assujettis à la politique de limitation de débit d’Auth0. Vous devez en tenir compte et, pour vous aider, Auth0 recommande généralement d’utiliser le SDK Auth0 approprié à votre environnement de développement plutôt que d’appeler directement nos API.
Liens profonds vers des points de terminaison protégés
Il peut y avoir plusieurs raisons pour lesquelles quelqu’un voudrait accéder directement à une page précise de votre application qui n’est accessible qu’aux utilisateurs authentifiés. Si c’est possible dans votre application, vous devriez rediriger automatiquement l’utilisateur vers Auth0 s’il n’est pas authentifié. Une fois qu’il s’est authentifié et que le le renvoie vers votre application, vous pouvez le rediriger vers l’endroit où il voulait aller au départ.
La plupart des frameworks d’authentification modernes prennent en charge un middleware permettant de rediriger vers un serveur d’autorisation comme Auth0. Au moment d’en choisir un, voici quelques éléments clés à considérer :
Prise en charge des clients confidentiels, des clients non confidentiels, ou des deux
L’authentification est le processus qui consiste à déterminer l’identité de l’utilisateur. En contexte OIDC, le résultat de l’authentification est un . Ce jeton contient des renseignements sur l’utilisateur et ne devrait pouvoir être obtenu que si l’utilisateur s’authentifie au moyen d’un ou de plusieurs facteurs, tels que définis par le serveur d’autorisation (la forme la plus courante étant l’ID utilisateur et le mot de passe). Voici aussi quelques éléments à prendre en compte en plus de l’obtention d’un ID Token :
Avez-vous aussi besoin d’un Access Token pour effectuer une requête à une API partagée ?
Avant la mise en production, vous devriez vous assurer que seuls les types d’autorisation que vous utilisez pour chaque application sont activés dans la configuration de votre Application.
Si votre SDK ne prend en charge que le grant de code d’autorisation, ou si vous avez besoin d’un Access Token ou d’un , le grant de code d’autorisation (avec ou sans PKCE) peut aussi être utilisé pour récupérer un ID Token. Le grant de code d’autorisation comprend un appel d’API supplémentaire pour échanger le code contre un jeton, ce qui peut entraîner une latence inutile si vous avez seulement besoin de l’ID Token. Dans bien des cas, le flux hybride est mis en œuvre afin d’offrir un accès optimal à l’ID Token tout en tirant parti du processus du grant de code d’autorisation pour récupérer les Access Tokens et les Refresh Tokens de façon sécurisée.
Bien qu’Auth0 prenne en charge l’utilisation du grant implicite pour les applications basées sur le navigateur qui nécessitent seulement un ID Token, il est recommandé d’utiliser le grant de code d’autorisation avec PKCE. Pour en savoir plus, consultez OAuth2 Implicit Grant and SPA sur le blogue Auth0.Si vous avez besoin d’un Refresh Token afin d’obtenir un nouvel Access Token ou ID Token sans devoir authentifier de nouveau l’utilisateur, vous devez utiliser le grant de code d’autorisation.
Les systèmes d’authentification sont importants, car ils empêchent les d’accéder aux applications et aux données des utilisateurs auxquelles ils ne devraient pas avoir accès. Nous voulons mettre le plus d’obstacles possible entre ces acteurs malveillants et l’accès à nos systèmes. L’un des moyens les plus simples d’y parvenir consiste à vous assurer que votre protection contre les attaques avec Auth0 est configurée correctement. Prenez donc un moment pour lire les conseils à ce sujet et vérifier qu’elle fonctionne comme prévu.
La détection des anomalies est gérée en arrière-plan par Auth0 et offre une excellente fonctionnalité de sécurité pour votre produit. Si vous comptez l’utiliser, assurez-vous d’avoir configuré votre fournisseur de courriel et vos modèles de courriel avant d’activer l’envoi de courriels à vos utilisateurs.
Dans le cadre d’une restructuration à grande échelle, il n’est pas toujours possible — ni pratique — de mettre à jour toutes vos applications en même temps. En fait, la pratique exemplaire que nous recommandons consiste à adopter une approche itérative pour l’intégration avec Auth0. Si vos applications prennent déjà part à l’authentification unique (SSO) et que votre système d’identité hérité prend en charge des protocoles comme OIDC ou , plusieurs options s’offrent à vous si vous souhaitez continuer à offrir le SSO pendant votre intégration avec Auth0 :
Mettez à jour votre fournisseur d’identité existant dans votre ancien système SSO afin qu’il redirige vers Auth0 pour la connexion (par ex., à l’aide de SAML), ou
Configurez Auth0 pour qu’il redirige vers votre ancien système SSO pour la connexion. Cela nécessite de configurer votre ancien système comme IdP dans Auth0 (c.-à-d. en utilisant soit SAML, soit OIDC).
Prendre en charge une expérience SSO avec votre ancien système peut ajouter de la complexité, mais cela peut en valoir la peine pour offrir une expérience utilisateur plus fluide pendant votre intégration avec Auth0. Si vous comptez aller dans cette direction, le fait de le planifier tôt peut aider à en assurer la faisabilité. Si vous n’avez pas déjà de SSO au niveau d’un service centralisé, la complexité nécessaire pour l’ajouter ne justifiera probablement pas les avantages.
Il s’agit d’un sujet complexe qui nécessitera probablement une analyse plus approfondie selon votre architecture héritée actuelle, et nous vous recommandons de ne vous y intéresser que si votre système hérité prend déjà en charge le SSO. Remarque : si vos applications redirigent actuellement vers un système centralisé pour authentifier vos utilisateurs et que ce système ne demande des identifiants que si vous n’avez pas déjà une session avec ce système centralisé, vous avez alors une mise en œuvre SSO héritée.
Le scénario « apportez votre propre identité » est devenu incontournable pour presque toutes les applications B2B. La plupart des entreprises s’attendent à pouvoir intégrer leur IdP à votre application afin que leurs employés n’aient pas à conserver un autre jeu d’identifiants. C’est un excellent moyen de simplifier l’expérience d’authentification des utilisateurs sans compromettre la sécurité, et l’utilisation de Universal Login permet d’ajouter facilement la prise en charge des Enterprise Connections avec un minimum de perturbations.
Dès que vous commencez à prendre en charge des connexions d’entreprise pour les utilisateurs, vous devez mettre en place une forme de Home Realm Discovery afin de déterminer vers quelle connexion acheminer l’utilisateur pour l’authentification.
Avec la prise en charge des connexions d’entreprise, les identités des utilisateurs et les identifiants sont gérés par le fournisseur d’identité de l’organisation de vos clients, de même que certaines claims d’identité, qu’Auth0 utilisera pour alimenter le profil de l’utilisateur.
« Apportez votre propre identité » est une excellente fonctionnalité à offrir, mais si vous ne la prenez pas en charge dès le départ, et parfois même si c’est le cas, il se peut qu’une organisation veuille passer à son propre IdP après avoir déjà utilisé l’application pendant un certain temps. Vous aurez besoin d’un moyen de lier des comptes d’utilisateur afin d’associer efficacement la nouvelle identité à l’ancienne identité de base de données.
À une époque où l’utilisation abusive des identifiants des utilisateurs atteint des sommets, protéger vos systèmes représente un véritable défi, surtout dans un contexte où les pirates volent fréquemment des renseignements d’identité. L’un des moyens les plus efficaces d’y parvenir consiste à offrir aux utilisateurs la possibilité de configurer un second facteur pour protéger leur compte. On parle plus couramment d’authentification multifacteur. Cela garantit que seul un utilisateur légitime peut accéder à son compte, même s’il utilise un nom d’utilisateur et mot de passe qui a pu être compromis dans une autre application.
Il est assez courant que les applications destinées aux clients offrent aux utilisateurs une option pour ajouter un second facteur plutôt que de les y obliger. Pour en savoir plus à ce sujet, consultez providing your users with an option to add MFA.
Auth0 prend en charge plusieurs options pour activer la MFA afin de protéger l’accès aux comptes d’utilisateur, et il existe plusieurs pratiques pour vous assurer d’offrir une protection souple et efficace par second facteur :
Auth0 Guardian : un service qui fournit à la fois la génération de notifications Push et une application permettant d’autoriser ou de rejeter des requêtes. Push envoie une notification à l’appareil préenregistré d’un utilisateur — généralement un téléphone mobile ou une tablette — à partir duquel l’utilisateur peut immédiatement autoriser ou refuser l’accès à son compte par une simple pression sur un bouton.
Mot de passe à usage unique basé sur le temps (TOTP) : vous permet d’enregistrer un appareil — comme Google Authenticator — qui génère un mot de passe à usage unique changeant au fil du temps et pouvant être saisi comme second facteur pour valider le compte d’un utilisateur.
SMS : pour envoyer un code à usage unique par SMS que l’utilisateur est ensuite invité à saisir avant de pouvoir terminer l’authentification.
Voice : pour transmettre un code à usage unique au moyen d’un appel téléphonique que l’utilisateur est ensuite invité à saisir avant de pouvoir terminer l’authentification.
Duo : vous permet d’utiliser votre compte Duo pour l’authentification multifacteur.
Email : vous permet d’utiliser votre compte de courriel pour l’authentification multifacteur.
Bien que le workflow de MFA utilisant des technologies comme Guardian ou Google Authenticator soit généralement fourni au moyen d’une application distincte qui s’exécute sur un appareil mobile ou une tablette, si vous ne voulez pas que vos clients aient à télécharger une application distincte, Auth0 vous fournit aussi un SDK que vous pouvez utiliser pour intégrer le workflow de second facteur directement à vos applications mobiles existantes.
Nous offrons un guide de planification en format PDF que vous pouvez télécharger et consulter pour en savoir plus sur nos stratégies recommandées.B2B IAM Project Planning Guide
Architecture à organisations multiples (multilocataire)
De nombreuses plateformes B2B mettent en œuvre une forme d’isolation et/ou d’image de marque pour les organisations de leurs clients, ce qui peut ajouter de la complexité à tout système de gestion des identités et des accès (IAM). Si cela correspond à votre situation, nous vous recommandons de prendre le temps de consulter nos conseils et nos recommandations de bonnes pratiques pour ce type d’environnement.Architecture à organisations multiples
Authentifier
Gérer les utilisateurs
Personnaliser
Plateforme