Fonctionnement de l’authentification dans votre implémentation B2B IAM.
Afin de fournir 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 — par l’entremise de comptes de médias sociaux, d’un nom d’utilisateur et d’un mot de passe, — et il est souvent recommandé d’aller au-delà d’un premier facteur d’authentification en activant l’ (MFA).
Il est important de tenir compte à la fois de la sécurité et de l’expérience utilisateur lorsque vous concevez la façon dont vos utilisateurs s’authentifieront. Offrir plusieurs facteurs principaux et/ou exiger plus d’un facteur lors de l’authentification sont des moyens d’assurer les deux.
Il y a plusieurs éléments à prendre en compte lorsque vous évaluez les fonctionnalités et le flux de travail :
Où les utilisateurs saisiront-ils leurs informations d’identification ?
Comment assurerez-vous la sécurité des informations d’identification des utilisateurs ?
Comment assurerez-vous la maintenance de votre système d’authentification ?
Comment pouvez-vous offrir l’authentification par mot de passe à vos utilisateurs ?
Comment pouvez-vous empêcher des pirates d’essayer d’ouvrir une session en se faisant passer pour vos utilisateurs ?
Comment mettrez-vous en œuvre l’authentification dans différents types d’applications ?
Comment pouvez-vous faciliter l’ouverture de session pour vos utilisateurs lorsqu’ils proviennent de contextes linguistiques différents ?
Comment offrirez-vous une bonne expérience utilisateur pendant la migration à partir d’un système d’authentification existant ?
Quels éléments devez-vous prendre en compte lors de l’intégration d’applications avec Auth0 ?
Que faites-vous si vous avez un service qui n’offre aucun moyen à l’utilisateur d’ouvrir une session à l’avance ?
Pouvez-vous transmettre le même utilisateur d’une API à une autre ?
Que faites-vous si vous devez isoler les utilisateurs par organisation ?
Comment déterminerez-vous à quelle organisation les utilisateurs appartiennent ?
Quel est l’avantage d’offrir des connexions d’entreprise à vos organisations ?
Auth0 Universal Login offre aux utilisateurs une expérience fiable et sécurisée, que vous choisissiez de proposer une ouverture de session avec identifiant utilisateur et mot de passe ou d’autoriser les scénarios dits Bring Your Own Identity offerts par Social Login. La centralisation de l’expérience d’ouverture de session avec présente aussi des avantages sur le plan de la reconnaissance de la marque, même si vous estimez avoir également des exigences propres au produit en matière d’image de marque. Les widgets d’interface Auth0 habituellement 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 prête à l’emploi des fonctionnalités Auth0 comme la MFA et la protection contre les attaques vous permet de mettre en place des mécanismes afin d’empêcher des pirates de tenter d’accéder aux comptes des utilisateurs.Permettre aux utilisateurs d’ouvrir une session au moyen d’un identifiant utilisateur et d’un mot de passe signifie que vous ne dépendez pas de la disponibilité de tiers pour permettre à vos utilisateurs d’accéder à votre système. Vous avez également la possibilité d’exiger que les informations d’identification utilisées soient conformes à vos politiques d’entreprise. Auth0 vous aide à cet égard en vous offrant plusieurs options pour prendre en charge les ouvertures de session avec identifiant utilisateur et mot de passe, et les directives fournies vous aideront à comprendre comment tirer parti de ces options. L’ajout de la prise en charge sociale à une certaine étape, comme facteur d’authentification principal supplémentaire, vous donne plus de flexibilité et peut vous aider à mieux comprendre vos utilisateurs sans avoir à leur poser davantage de questions, en tirant parti des renseignements déjà stockés par les différents fournisseurs de connexion sociale.Si vous disposez déjà d’un référentiel d’identités hérité, vous voudrez aussi consulter Migration des utilisateurs. Cette section présente les avantages de migrer vers le stockage d’identités géré par Auth0 en matière de fiabilité et de 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 native dans Auth0. Auth0 prend en charge différentes approches d’intégration pour divers types d’applications. Vous voudrez donc consulter la section sur l’intégration d’applications pour obtenir l’information dont vous avez besoin afin de faire un choix éclairé.Lorsqu’une API en appelle une autre, ou dans toute situation où il n’y a pas de contexte d’utilisateur authentifié — par exemple une ou plusieurs tâches cron, 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 un seul appel. Vous pouvez en apprendre davantage à ce sujet dans notre section sur l’autorisation machine à machine (m2m).Les entreprises ont souvent besoin de segmenter leurs utilisateurs par organisation, et il arrive parfois que des utilisateurs aient accès à plus d’une organisation. Déterminer lequel de ces scénarios s’applique à votre entreprise vous aidera à définir comment savoir dans quelle connexion se trouve un utilisateur : si vous devez le faire, quand vous devez le faire et comment y parvenir. Consultez détermination du domaine d’origine 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 intérêt à offrir une expérience de connexion centralisée. Pour assurer une expérience fluide de (SSO) entre plusieurs applications, il est essentiel de disposer d’un emplacement centralisé vers lequel rediriger vos utilisateurs pour l’authentification. Vous pourrez ainsi offrir une expérience cohérente à vos utilisateurs si vous ajoutez plus tard l’authentification sociale, des applications tierces à votre système, ou encore l’authentification multifacteur comme option (ou exigence) — tout en profitant aussi 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 intégrés en matière de sécurité et d’expérience utilisateur, notamment le SSO.
Auth0 Universal Login simplifie l’authentification des utilisateurs en un processus court et facile à mettre en place en trois étapes (tous nos Quickstarts le montrent, et nos SDK masquent aussi la complexité) :
La détermination du domaine d’origine (HRD) est le processus qui consiste à identifier à quel fournisseur d’identité (ou à quelle connexion dans Auth0) l’utilisateur appartient avant de l’authentifier. La HRD peut se faire de deux façons :
Prévoir un mécanisme pour que cette décision soit prise dans l’application
Faire en sorte que la détermination du domaine d’origine ait lieu sur la page 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 les différentes approches de la HRD afin d’appliquer celle(s) qui conviennent le mieux à vos applications.
Une façon courante de déterminer à quel domaine d’origine un utilisateur appartient consiste à avoir une application aux couleurs de chaque organisation. Dans ce contexte, une organisation dispose généralement de sa propre instance de l’application, à laquelle on accède habituellement au moyen d’une URL distincte. Cette copie ou instance peut être isolée physiquement (en s’exécutant sur un ensemble distinct de serveurs) ou virtuellement (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 détermination du domaine d’origine se résume à stocker org_id avec la configuration de l’application propre à l’organisation et à l’envoyer comme paramètre d’organisation lorsque vous redirigez l’utilisateur vers Universal Login. L’utilisateur sera ainsi limité à 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 détermination du domaine d’origine (une fois l’organisation identifiée). Auth0 gère généralement cela pour vous si vous utilisez la fonctionnalité Organisations.
Si l’utilisateur est partagé entre plusieurs organisations au moyen d’une identité unique, vous devez prendre en charge la détermination du domaine d’origine sur la page Universal Login. Universal Login pourra ainsi d’abord identifier l’utilisateur, puis présenter les domaines d’origine appropriés pour cet utilisateur, ce qui améliore l’expérience utilisateur.Vous pouvez transmettre les paramètres organization et/ou connection 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’API d’authentification. Toutefois, vous le ferez généralement au moyen du SDK correspondant au langage dans lequel votre application est écrite.
Il existe trois principales approches pour la détermination du domaine d’origine :
Déterminer le domaine d’origine à partir du sous-domaine du courriel de l’utilisateur.
Déterminer le domaine d’origine en recherchant un identifiant utilisateur dans une table de correspondance entre identifiants et domaines d’origine.
Permettre à l’utilisateur de choisir ou de saisir son domaine d’origine (ou son organisation).
Dans les deux premiers cas, vous pouvez envisager d’utiliser « Identifier First Login ». Cela signifie que vous demandez d’abord uniquement la saisie d’un identifiant. Ensuite, vous recueillez l’identifiant de l’utilisateur et, selon cet identifiant, vous redirigez automatiquement l’utilisateur ou lui permettez de saisir son mot de passe si la redirection n’est pas nécessaire. Auth0 fournit une implémentation prête à l’emploi pour gérer tout cela au moyen de 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 page Universal Login, cela peut ajouter de la complexité en matière d’authentification unique (SSO), ainsi que pour reproduire ce comportement dans toutes vos applications. Auth0 recommande plutôt d’implémenter une forme de HRD avec Universal Login.
HRD via Universal Login à l’aide du sous-domaine de l’adresse courriel
La façon la plus simple de mettre en œuvre 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 afin de l’associer à son fournisseur d’identité. Cela ne fonctionne toutefois 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 souhaitez l’implémenter vous-même, c’est possible, mais vous devrez créer 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é Organisations vous aidera de deux façons :
Si vous n’avez pas transmis de org_id à /authorize lorsque vous avez lancé la demande de connexion, Auth0 présentera à l’utilisateur une invite lui demandant de saisir l’organisation à laquelle il appartient.
Si l’Organisation est associée à plus d’un IdP, Auth0 présentera à l’utilisateur des boutons pour choisir l’organisation ou un formulaire pour saisir un nom d’utilisateur et un mot de passe.
HRD avec Universal Login à l’aide d’un mappage des identifiants vers les domaines d’origine
Une deuxième option, plus complexe, consiste à stocker un mappage entre les identifiants et l’IdP, puis à fournir un point de terminaison public pour accéder à cette information. Ensuite, sur la page Universal Login, vous pouvez déterminer la connexion et rediriger de nouveau vers /authorize avec cette connexion. Les principaux inconvénients de cette approche sont la latence et, surtout, les enjeux de sécurité liés à la découverte d’identifiants : si vous utilisez des adresses de courriel, il devient beaucoup plus facile pour quelqu’un de découvrir si une adresse de courriel donnée correspond à l’un de vos utilisateurs.
Tout point de terminaison public devrait être protégé par une limitation du nombre de requêtes afin d’empêcher des pirates de l’utiliser pour recueillir de l’information et pour prévenir les attaques par déni de service.
HRD au moyen de Universal Login selon le choix de l’utilisateur
L’autre option consiste à permettre à vos utilisateurs de choisir dans une liste, si cela ne vous dérange pas de rendre publique la liste des organisations qui utilisent votre produit, ou de leur permettre d’entrer 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 simplement laisser Auth0 lui demander son nom d’utilisateur et son mot de passe si la connexion est de type 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 de connexion. Il s’agit d’une forme d’authentification courante que tous les utilisateurs connaissent bien.L’authentification par nom d’utilisateur et mot de passe se décline de plusieurs façons dans Auth0. Si votre application est nouvelle et ne dispose pas encore d’une base d’utilisateurs, 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 avez un référentiel d’utilisateurs existant (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 conseils sur la migration des utilisateurs.Quelle que soit la façon dont vous provisionnez les utilisateurs pour votre connexion de base de données, l’authentification de ces utilisateurs reste très semblable. Vous devez leur présenter un formulaire pour qu’ils saisissent leur nom d’utilisateur et leur mot de passe. Comme indiqué dans les conseils sur Universal Login, la façon la plus simple et la plus sécuritaire d’authentifier les utilisateurs à l’aide d’un nom d’utilisateur et d’un mot de passe consiste à les rediriger vers une page de connexion centralisée afin d’y recueillir ces renseignements. Cela permet à Auth0 de déterminer s’ils se sont déjà authentifiés et de ne pas afficher 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éduira les risques de fuite de secrets utilisateur. Cela réduira également le besoin de demander des identifiants inutilement. Consultez Universal Login pour en savoir plus.
Une fois que vous avez déterminé comment vous souhaitez authentifier vos utilisateurs, l’étape suivante consiste à déterminer comment vous déclencherez cette authentification. Chaque application a généralement son propre point de départ.
Les applications mobiles natives (et les applications de bureau) doivent utiliser le navigateur système pour l’authentification, faute de quoi elles s’exposent à des risques de sécurité supplémentaires. Consultez Connexion native pour en savoir plus.
Comme nous l’avons mentionné, nous avons constaté que la plupart de nos clients utilisent OpenID Connect (OIDC) comme protocole normalisé de l’industrie pour leurs applications destinées aux clients. Déterminer quel flux OIDC utiliser est votre première tâche, et vous devriez commencer par consulter notre guide de correspondance des types d’autorisation.Si vous souhaitez permettre à des utilisateurs anonymes d’accéder à une partie de votre application, vous devez déterminer si vous les redirigerez immédiatement ou seulement lorsque ce sera nécessaire (ou peut-être une combinaison des deux; consultez Rediriger les utilisateurs après la connexion pour en savoir plus). Si les utilisateurs peuvent accéder directement à une version (ou à une section) 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 accède à votre application pour la première fois. Si votre application prend en charge l’accès anonyme des utilisateurs (ce qui est assez courant pour les applications de commerce électronique), différents scénarios doivent être pris en compte :
Revient-elle dans l’application après s’être déjà connectée, ou
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 locataire Auth0,
S’est-elle déjà authentifiée sur cet appareil ou dans ce navigateur (ou peut-être pas depuis longtemps).
Lorsqu’un utilisateur anonyme accède à votre application, il peut souvent être utile 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 ce faire, vous devrez utiliser « l’authentification silencieuse ». L’authentification silencieuse vous permet de vérifier si l’utilisateur est connecté sans lui demander de se connecter si ce n’est pas le cas. L’application peut ensuite afficher un bouton de connexion au besoin. Si l’utilisateur est déjà connecté, vous recevrez toutefois des jetons et vous n’aurez pas à lui afficher de nouveau un bouton de connexion.
Vérifier l’existence d’une session de connexion au moyen d’une redirection 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 pour éviter la latence ou une limitation du débit.Les appels à la Management API sont assujettis à la politique de limitation du 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 existe plusieurs raisons pour lesquelles quelqu’un pourrait accéder directement à une page précise de votre application qui n’est accessible qu’aux utilisateurs authentifiés. Si votre application le permet, vous devriez rediriger automatiquement l’utilisateur vers Auth0 s’il n’est pas authentifié. Une fois l’authentification effectuée et le revenu à votre application, vous pouvez le rediriger vers l’emplacement où il voulait aller au départ.
La plupart des frameworks d’authentification modernes prennent en charge des intergiciels permettant de rediriger vers un serveur d’autorisation comme Auth0. Si vous en choisissez un, voici quelques points importants à considérer :
Prise en charge des applications confidentielles, des applications non confidentielles, ou des deux
L’authentification est le processus qui permet de déterminer l’identité de l’utilisateur. Dans un 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 à l’aide d’un ou de plusieurs facteurs, selon ce qui est défini par le serveur d’autorisation (la forme la plus courante étant l’identifiant utilisateur et le mot de passe). Il y a aussi quelques éléments à prendre en compte en plus de l’obtention d’un ID Token :
Avons-nous aussi besoin d’un Jeton d’accès pour appeler une API partagée ?
Avant la mise en production, vous devriez vous assurer que seuls les types d’octroi que vous utilisez pour chaque application sont activés dans la configuration de votre application.
Si votre SDK ne prend en charge que le flux de code d’autorisation, ou si vous avez besoin d’un Jeton d’accès ou d’un , le flux de code d’autorisation (avec ou sans PKCE) peut aussi servir à récupérer un ID Token. Le flux 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 supplémentaire inutile si tout ce dont vous avez besoin est un ID Token. Dans bien des cas, le flux hybride est mis en œuvre pour offrir un accès optimal à l’ID Token tout en tirant parti du processus du flux de code d’autorisation pour récupérer de façon sécurisée les Jetons d’accès et les Jetons d’actualisation.
Bien qu’Auth0 prenne en charge l’utilisation du flux implicite pour les applications côté navigateur qui ne nécessitent qu’un ID Token, il est recommandé d’utiliser le flux 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 Jeton d’actualisation afin d’obtenir un nouveau Jeton d’accès ou un ID Token sans avoir à réauthentifier l’utilisateur, vous devez utiliser le flux de code d’autorisation.
Les systèmes d’authentification sont essentiels pour empêcher les d’accéder aux applications et aux données des utilisateurs auxquelles ils ne devraient pas avoir accès. Nous voulons multiplier les obstacles entre ces acteurs malveillants et l’accès à nos systèmes. L’une des façons les plus simples d’y parvenir consiste à vous assurer que votre protection contre les attaques avec Auth0 est correctement configurée. Prenez donc un moment pour lire les recommandations à ce sujet et vérifier qu’elle fonctionne correctement dans votre environnement.
La détection des anomalies est gérée en arrière-plan par Auth0 et constitue une excellente mesure 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 à Auth0. Si vos applications participent déjà à l’authentification unique (SSO) et que votre système d’identité hérité prend en charge des protocoles comme OIDC ou , vous avez alors quelques options si vous souhaitez continuer à offrir le SSO pendant l’intégration à Auth0 :
Mettez à jour votre fournisseur d’identité existant dans votre système SSO hérité afin qu’il redirige vers Auth0 pour la connexion (p. ex., en utilisant SAML), ou
Configurez Auth0 pour qu’il redirige vers votre système SSO hérité pour la connexion. Cela exige de configurer votre système hérité comme fournisseur d’identité (IdP) dans Auth0 (c.-à-d. en utilisant soit SAML ou OIDC).
Prendre en charge une expérience SSO avec votre système hérité peut ajouter de la complexité, mais cela peut valoir la peine pour offrir une expérience utilisateur plus fluide pendant l’intégration à Auth0. Si vous comptez aller dans cette direction, le fait de planifier tôt peut vous aider à vous assurer que ce sera réalisable. Si vous n’avez pas déjà le SSO dans un service centralisé, il est peu probable que la complexité nécessaire pour l’ajouter en vaille la peine.
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 l’envisager 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à de session avec lui, alors vous disposez d’une implémentation SSO héritée.
Le scénario « apportez votre propre identité » est devenu incontournable pour presque toutes les applications B2B. La plupart des grandes entreprises s’attendent à pouvoir intégrer leur IdP à votre application afin que leurs employés n’aient pas à conserver un autre ensemble 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 facilite l’ajout de la prise en charge des connexions d’entreprise avec un minimum de perturbations.
Dès que vous commencez à prendre en charge les connexions d’entreprise pour les utilisateurs, vous devez mettre en place une forme de détermination du domaine d’origine afin de déterminer vers quelle connexion rediriger l’utilisateur pour l’authentification.
Avec la prise en charge des connexions d’entreprise, les identités et les identifiants des utilisateurs sont gérés par le fournisseur d’identité de l’organisation de vos clients, de même que certaines revendications 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 vous le faites, il se peut qu’une organisation souhaite passer à son propre IdP après avoir déjà utilisé l’application pendant un certain temps. Vous aurez besoin d’un moyen de lier les comptes utilisateur afin d’associer efficacement la nouvelle identité à l’ancienne identité de base de données.
À une époque où l’utilisation abusive des identifiants d’utilisateur n’a jamais été aussi répandue, protéger vos systèmes représente un véritable défi, surtout quand le vol de renseignements d’identité est si courant. L’un des moyens les plus efficaces consiste toutefois à permettre aux utilisateurs de configurer un deuxième facteur pour protéger leur compte, ce qu’on appelle plus couramment l’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 un mot de passe qui ont pu être compromis dans une autre application.
Il est assez courant que les applications destinées aux clients offrent aux utilisateurs une option d’ajouter un deuxième facteur plutôt que de les obliger à en utiliser un. Pour en savoir plus à ce sujet, consultez offrir à vos utilisateurs la possibilité d’ajouter la MFA.
Auth0 prend en charge plusieurs options pour activer la MFA afin de protéger l’accès aux comptes utilisateur, et il existe plusieurs pratiques pour vous assurer d’offrir une protection par deuxième facteur à la fois efficace et souple :
Auth0 Guardian : un service qui offre à la fois la génération de notifications Push et une application permettant d’accepter ou de refuser les demandes. Push envoie des notifications à 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 au compte en appuyant simplement 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 deuxième facteur pour valider le compte d’un utilisateur.
SMS : permet d’envoyer un code à usage unique par SMS que l’utilisateur est ensuite invité à saisir avant de pouvoir terminer l’authentification.
Voix : permet de 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.
Courriel : vous permet d’utiliser votre compte de courriel pour l’authentification multifacteur.
Bien que le flux de travail MFA utilisant des technologies comme Guardian ou Google Authenticator soit généralement fourni au moyen d’une application distincte exécutée sur un téléphone 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 flux de deuxième facteur directement dans vos applications mobiles existantes.
Nous proposons des conseils de planification au format PDF que vous pouvez télécharger et consulter pour obtenir plus de détails sur les stratégies recommandées.Guide de planification du projet B2B IAM
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 complexifier tout système de gestion des identités et des accès (IAM). Si c’est votre cas, nous vous recommandons de prendre le temps de consulter nos recommandations et nos bonnes pratiques pour ce type d’environnement.Architecture multi-organisations
Authentification
Gérer les utilisateurs
Personnaliser
Auth0 AI
Plateforme