Passer au contenu principal
Vous devez être en mesure d’identifier vos utilisateurs pour pouvoir leur fournir des services. Ce processus est appelé authentification de l’utilisateur. Il existe plusieurs façons d’effectuer l’authentification d’un utilisateur, que ce soit via des comptes de médias sociaux, un nom d’utilisateur et un mot de passe ou encore sans mot de passe. De plus, il est souvent recommandé d’aller au-delà d’un premier facteur d’authentification de l’utilisateur en activant l’authentification multifacteur ().

​
Meilleure pratique

Il est important de prendre en compte à la fois la sécurité et l’expérience de l’utilisateur lorsque vous concevez la manière dont vous allez authentifier vos utilisateurs. Proposer plusieurs facteurs principaux et/ou exiger plus d’un facteur lors de l’authentification sont des moyens de répondre à ces deux besoins. Il y a un certain nombre d’éléments que vous voudrez prendre en compte lors de l’examen de la fonctionnalité et du flux de travail :
  • À quel endroit les utilisateurs saisiront-ils leurs identifiants?
  • Comment assurez-vous la sécurité des identifiants des utilisateurs?
  • Comment allez-vous administrer votre système d’authentification?
  • Comment pouvez-vous fournir une authentification par mot de passe à vos utilisateurs?
  • Comment empêcher les pirates d’essayer de se connecter en tant qu’utilisateurs?
  • Comment allez-vous mettre en œuvre l’authentification dans différents types d’applications?
  • Comment faciliter la connexion de vos utilisateurs de langues différentes?
  • Que comptez-vous faire pour offrir une bonne expérience à l’utilisateur lorsque vous abandonnerez un système hérité d’authentification?
  • Que devez-vous prendre en compte lors de l’intégration d’applications avec Auth0?
  • Devez-vous proposer un authentification multifacteur (MFA)?
  • Que pouvez-vous faire si vous disposez d’un service qui ne permet pas à l’utilisateur de se connecter à l’avance?
  • Pouvez-vous transmettre le même jeton d’accès utilisateur d’une API à l’autre?
  • Que faites-vous si vous devez isoler les utilisateurs par organisation?
  • Comment allez-vous déterminer l’organisation à laquelle appartiennent les utilisateurs?
  • Quel est l’avantage de fournir des connexions d’entreprise à vos organisations?
La connexion universelle Auth0 offre aux utilisateurs une expérience sûre et sécurisée indépendamment du fait que vous choisissiez de fournir un identifiant et un mot de passe pour l’ouverture de session ou d’autoriser les scénarios dits « Apportez votre propre identité » fournis par la connexion via un réseau social. La centralisation de l’expérience d’ouverture de session avec la connexion universelle présente également des avantages sur le plan de la reconnaissance de la marque, même si vous prévoyez également d’avoir des exigences en matière de marque propres à chaque produit. Les widgets Auth0 IU généralement utilisés avec la connexion universelle offrent également une prise en charge prête à l’emploi en ce qui concerne l’internationalisation pour les utilisateurs ayant des exigences linguistiques différentes. Par ailleurs, la prise en charge prête à l’emploi des fonctionnalités Auth0 telles que MFA et la protection contre les attaques vous permet de mettre en place des barrières afin d’empêcher les pirates informatiques d’accéder aux comptes des utilisateurs. En permettant aux utilisateurs de se connecter à l’aide d’un identifiant et d’un mot de passe, vous n’êtes pas dépendant de l’état des fournisseurs d’identité tiers pour que vos utilisateurs puissent accéder à votre système. Vous avez également les moyens d’exiger que les identifiants utilisés soient conformes à vos politiques d’entreprise. Auth0 vous aide dans cette tâche en vous proposant plusieurs options pour les connexions par identifiant et mot de passe, et les conseils offerts vous aideront à comprendre comment vous pouvez tirer parti de ces options. L’ajout de la prise en charge des réseaux sociaux à un moment donné, en tant que facteur d’authentification principal supplémentaire, vous offre une flexibilité accrue et peut vous aider à mieux comprendre vos utilisateurs sans qu’il soit nécessaire de les interroger davantage en exploitant les informations déjà stockées par les différents fournisseurs de connexions aux réseaux sociaux. Si vous disposez d’un magasin d’identités hérité, vous devez également consulter la rubrique Migration des utilisateurs. Cette section présente les avantages de la migration vers le stockage d’identités géré par Auth0 en termes de sûreté et de sécurité. Pour les applications destinées à la clientèle, Connect (OIDC) est le protocole standard le plus fréquemment utilisé dans l’industrie, et OIDC dispose d’une prise en charge des objets de première classe dans Auth0. Auth0 prend en charge différentes approches pour l’intégration de différentes applications. Vous voudrez donc consulter la section sur l’intégration des applications pour obtenir les informations dont vous aurez besoin pour faire un choix éclairé. Lorsque vous appelez une API depuis une autre API, ou depuis 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/de livraison continue, vous aurez besoin d’un moyen d’autoriser l’application au lieu d’un utilisateur. Il s’agit d’un processus en une seule étape au cours duquel l’application est authentifiée (à l’aide d’un ID et d’un secret client), puis autorisée en un seul appel. Vous pouvez en savoir plus à ce sujet dans notre flux de travail sur l’autorisation dans Autorisation de communication machine à machine (m2m). Souvent, les sociétés doivent séparer leurs utilisateurs par organisation et parfois les utilisateurs peuvent avoir accès à plus d’une organisation. Savoir lequel de ces scénarios est pertinent pour votre entreprise vous aidera à établir dans quelle connexion un utilisateur existe : si vous devez le faire, quand vous devez le faire et comment le faire. Consultez Découverte de domaine d’accueil pour déterminer si cela concerne votre entreprise.

​
Connexion universelle

Avez-vous, ou aurez-vous, plus d’une application dans votre système? Si vous répondez par l’affirmative à cette question, alors vous voudrez une expérience de connexion centralisée. Pour obtenir une expérience d’authentification unique () transparente entre plusieurs applications, il est essentiel de disposer d’un emplacement centralisé où rediriger vos utilisateurs pour l’authentification. Cela vous permet de fournir à vos utilisateurs une expérience cohérente si vous ajoutez l’authentification à partir des médias sociaux à l’avenir, si vous ajoutez des applications tierces à votre système ou si vous ajoutez l’authentification multifacteur (MFA) en tant qu’option (ou exigence) pour vos utilisateurs. Cela vous permet également de profiter des nouvelles fonctionnalités pour améliorer l’expérience de vos utilisateurs avec peu, voire aucun, effort de développement supplémentaire.

​
Meilleure pratique Si Si vous avez plusieurs applications, la meilleure pratique consiste à rediriger l’utilisateur vers un emplacement centralisé pour l’authentification. Avec Auth0, cela signifie tirer parti de la Connexion universelle, qui offre de nombreux avantages en matière de sécurité et d’expérience utilisateur prêts à l’emploi, y compris le SSO.

La Connexion universelle Auth0 fait de l’authentification des utilisateurs un processus court et facile qui peut être accompli en trois étapes simples (tous nos démarrages rapides le démontrent et nos trousses SDK vous facilitent la tâche) :
  1. Déterminez comment et quand vous souhaitez effectuer une redirection à partir de votre application.
  2. Configurez la marque appropriée ou le code HTML original dans votre configuration Auth0.
  3. Configurez votre application pour qu’elle reçoive et traite la réponse du serveur d’autorisations.

​
Découverte de domaine d’accueil

La détection de domaine d’accueil (HRD/Home Realm Discovery) est le processus qui consiste à déterminer à quel fournisseur d’identité (ou à quelle connexion dans Auth0) l’utilisateur appartient avant de l’authentifier. HRD peut être mis en œuvre de deux manières :
  • Prévoir un moyen pour que la décision soit prise au niveau de l’application
  • Faire en sorte que la détection de domaine d’accueil se fasse sur la page de connexion universelle
Votre système peut avoir besoin de recourir à l’une ou l’autre méthode, voire aux deux. Il est donc important de comprendre toutes les approches de la HDR afin de pouvoir appliquer celles qui conviennent le mieux à vos applications.

​
HDR en fonction de l’application

Une façon courante de déterminer à quel domaine appartient un utilisateur est de faire en sorte qu’une application soit associée à chaque organisation. Une organisation dispose généralement de sa propre instance de l’application, à laquelle on accède généralement par une URL différente. Cette copie ou instance peut être physiquement isolée (s’exécutant sur un ensemble distinct de serveurs) ou virtuellement isolée (s’exécutant sur des serveurs partagés) et est généralement désignée par un nom d’hôte personnalisé (companyA.application1.yourcompany.com) ou un chemin d’accès (application1.yourcompany.com/companyA).

​
Meilleure pratique

Si votre application connaît déjà la connexion spécifique (IdP) requise, vous pouvez également la transmettre lorsque vous redirigez l’utilisateur vers /authorize, en utilisant le paramètre de requête connection. Si c’est le cas pour votre ou vos applications, la découverte du domaine d’accueil consiste simplement à stocker l’identifiant org_id dans la configuration de l’application propre à l’organisation et à l’envoyer comme paramètre d’organisation lorsque l’utilisateur est redirigé vers la connexion universelle. Cela limitera l’utilisateur à cette organisation particulière et à son ensemble de connexions configurées.

​
Meilleure pratique Si une organisation a besoin de plus d’un fournisseur d’identité (IdP), vous devrez peut-être effectuer une deuxième phase de découverte du domaine d’origine (une fois l’identification de l’organisation effectuée). Auth0 s’en charge généralement pour vous si vous utilisez la fonctionnalité Organizations (Organisations).

Si l’utilisateur est partagé entre plusieurs organisations utilisant une identité unique, vous devez prendre en charge la découverte du domaine d’accueil sur la page de connexion universelle. Cela permettra à la connexion universelle de déterminer d’abord l’utilisateur, puis de présenter les domaines appropriés à cet utilisateur, ce qui améliorera son expérience. L’envoi des paramètres de l’organisation ou de la connexion peut être réalisé en les ajoutant comme paramètre de requête lorsque vous redirigez l’utilisateur vers le point de terminaison /authorize. Pour plus d’informations, consultez la documentation relative à la Authentication API. Cependant, vous le ferez généralement en utilisant la trousse SDK pour le langage dans lequel votre application est écrite.

​
HRD via la connexion universelle

Il existe trois approches principales de la détection du domaine d’accueil :
  • Déterminez le domaine grâce au sous-domaine de courriel de l’utilisateur.
  • Déterminez le domaine en recherchant l’identifiant d’un utilisateur dans une sorte de carte de correspondance entre l’identifiant et le domaine.
  • Permettez à l’utilisateur de choisir ou de saisir son domaine (ou organisation).
Dans les deux premières approches, vous pouvez envisager d’utiliser la méthode d’identification préalable (Identifier First Login). Cela signifie que vous ne présentez d’abord que la possibilité de saisir un identifiant. Ensuite, vous collectez l’identifiant de l’utilisateur et, sur la base de cet identifiant, vous redirigez automatiquement l’utilisateur ou vous lui présentez un moyen de saisir son mot de passe si la redirection n’est pas nécessaire. Auth0 fournit une implémentation prête à l’emploi pour s’occuper de tout cela, via l’utilisation de la connexion universelle.
Bien qu’il soit possible de mettre en œuvre l’identifiant prioritaire ou de permettre à un utilisateur de sélectionner son organisation au niveau de l’application plutôt que sur la page de connexion universelle, cela peut augmenter la complexité concernant l’authentification unique ainsi que la complexité associée à la reproduction de ce comportement dans l’ensemble de vos applications. Auth0 conseille plutôt de mettre en œuvre une stratégie HRD par le biais de la connexion universelle.

​
HDR via la connexion universelle au moyen du sous-domaine du courriel

La manière la plus simple de mettre en œuvre la détection du domaine d’accueil sur la page de connexion universelle est d’utiliser le sous-domaine de courriel de l’identifiant de l’utilisateur pour le mettre en correspondance avec son fournisseur d’identité. Bien entendu, cela ne fonctionne que dans les cas où le sous-domaine de courriel est associé à une organisation ou au moins à un fournisseur d’identité. Le widget Lock d’Auth0 ou la connexion universelle peuvent le faire pour vous si vous utilisez le mappage du domaine dans une connexion d’entreprise. Toutefois, vous pouvez le faire vous-même, mais cela nécessite de créer un mappage du sous-domaine du courriel vers la connexion. En outre, lors de l’utilisation de la connexion universelle, la fonctionnalité Organizations vous aidera de deux manières :
  1. Si vous n’avez pas transmis d’identifiant d’organisation à /authorize lorsque vous avez lancé la demande de connexion, Auth0 demandera à l’utilisateur d’indiquer l’organisation à laquelle il appartient.
  2. Si l’organisation est associée à plusieurs 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.

​
HDR via la connexion universelle au moyen de la carte de correspondance entre l’identifiant et le domaine

Une deuxième solution, plus complexe, consiste à stocker une carte des identifiants vers l’ et à fournir un point de terminaison public pour accéder à ces informations. Ensuite, sur la page de connexion universelle, vous pouvez trouver la connexion et rediriger vers /authorize avec la connexion. Les principaux inconvénients de cette approche sont la latence et, plus important encore, la sécurité lorsqu’il s’agit d’identifier un utilisateur : si vous utilisez des adresses de courriel, il est beaucoup plus facile pour quelqu’un de découvrir si une adresse courriel particulière est celle d’un de vos utilisateurs.

​
Meilleure pratique

Tout point de terminaison public doit être soumis à une limite anti-attaque afin d’empêcher les pirates de l’utiliser pour découvrir des informations et de prévenir les attaques par déni de service.

​
HDR via la connexion universelle au moyen du choix de l’utilisateur

L’autre option consiste à permettre à vos utilisateurs de choisir dans une liste, si vous ne voyez pas d’inconvénient à rendre publique la liste des organisations qui utilisent votre produit, ou en permettant à l’utilisateur de saisir directement le nom de son organisation. Cette étape est généralement effectuée avant de rediriger l’utilisateur vers la fonction de connexion universelle. Une fois que l’utilisateur vous a indiqué l’organisation à laquelle il appartient, vous pouvez le rediriger vers Auth0 en précisant la connexion de cette organisation ou demander à Auth0 d’indiquer simplement à l’utilisateur son nom d’utilisateur et son mot de passe s’il s’agit d’une connexion à une base de données.

​
Authentification par nom d’utilisateur et mot de passe

Presque toutes les applications de commerce électronique de détail (B2C) offrent à leurs clients la possibilité de créer de nouveaux identifiants. Il s’agit d’une forme d’authentification courante que tous les utilisateurs connaissent. L’authentification par nom d’utilisateur et mot de passe se présente sous plusieurs formes avec Auth0. Si votre application est nouvelle et n’a pas de base d’utilisateurs existante, une simple connexion Auth0 à la base de données vous fournira tout ce dont vous avez besoin pour commencer à authentifier vos utilisateurs. Toutefois, si vous disposez d’un système hérité (comme votre propre base de données d’utilisateurs ou un système LDAP existant), vous avez plusieurs possibilités pour migrer vos utilisateurs, comme indiqué dans notre guide sur la migration des utilisateurs. Quelle que soit la manière dont vous provisionnez les utilisateurs pour votre connexion à la base de données, l’authentification de ces utilisateurs est assez similaire. Elle requiert que vous présentiez aux utilisateurs un formulaire leur permettant de saisir leur nom d’utilisateur et leur mot de passe. Comme indiqué dans les lignes directrices concernant la connexion universelle, le moyen le plus simple et le plus sûr d’authentifier les utilisateurs avec un nom d’utilisateur et un mot de passe est de les rediriger vers une page de connexion centralisée et d’y recueillir leur nom d’utilisateur et leur mot de passe. 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.

​
Meilleure pratique La collecte d’identifiants uniquement sur la page de connexion centralisée réduira la surface d’exposition au risque de fuite de secrets utilisateur. Elle réduira également la nécessité de collecter inutilement des identifiants. Voir Connexion universelle pour plus d’informations. :::

​
Intégration de l’application

Une fois que vous avez déterminé comment vous souhaitez authentifier vos utilisateurs, l’étape suivante consiste à définir la manière dont vous allez lancer cette authentification. Chaque demande aura généralement son propre point de départ.
Les applications mobiles natives (et les applications de bureau) doivent utiliser le navigateur du système pour s’authentifier, faute de quoi elles s’exposent à des risques de sécurité supplémentaires. Voir Connexion native par rapport à la Connexion par navigateur sur mobile pour plus d’informations.
Comme nous l’avons indiqué, nous avons constaté que la plupart de nos clients utilisent OpenID Connect (OIDC) comme protocole standard pour leurs applications destinées à la clientèle. La première tâche consiste à déterminer le flux OIDC à utiliser. Pour ce faire, vous devez commencer par consulter notre guide sur le mappage des autorisations. Si vous souhaitez permettre à des utilisateurs anonymes d’accéder à n’importe quelle partie de notre application, vous devez déterminer si vous allez rediriger immédiatement les utilisateurs ou les inviter à le faire uniquement lorsque cela est nécessaire (ou peut-être une combinaison des deux; voir Rediriger les utilisateurs après la connexion pour plus d’informations). Si les utilisateurs peuvent utiliser un lien profond vers une version (ou une zone) protégée de votre site, vous devrez alors déterminer les liens vers votre application qui entraîneront une redirection automatique vers Auth0.

​
Accès anonyme

Il est important de prendre en compte l’expérience de l’utilisateur quand celui-ci arrive pour la première fois sur votre application. Si votre application prend en charge l’accès anonyme des utilisateurs (ce qui est assez courant pour les applications de commerce électronique), il y a différents scénarios à prendre en compte :
  • S’agit-il d’une personne qui revient sur l’application après s’être déjà connectée,
  • ou est-ce la première fois qu’elle accède à l’application :
    • la personne a-t-elle déjà accédé à une autre application qui utilise le même locataire Auth0?
    • S’est-elle déjà authentifiée (ou peut-être pas depuis longtemps) sur cet appareil ou ce navigateur?
Lorsqu’un utilisateur anonyme accède à votre application, il peut souvent être préférable que l’application découvre 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 application Web monopage (SPA) sans état. Par exemple, si vous pouvez déterminer que l’utilisateur est déjà connecté, vous pouvez décider que l’en-tête de l’interface utilisateur de l’application n’affiche pas de bouton de connexion et propose à la place un menu de compte ou de profil pour l’utilisateur. Pour ce faire, vous devez utiliser l’« authentification silencieuse ». L’authentification silencieuse vous permet de vérifier si l’utilisateur est connecté sans l’inviter à se connecter s’il ne l’est pas. L’application peut ensuite présenter un bouton de connexion si nécessaire. Toutefois, si l’utilisateur est déjà connecté, vous recevrez des jetons et n’aurez pas à lui présenter à nouveau un bouton de connexion.
Vérifier une session de connexion en redirigeant vers Auth0 peut s’avérer très pratique pour votre application. Cependant, si cela génère un grand nombre de requêtes, vous devriez utiliser un mécanisme de limitation pour éviter la latence et/ou la limite anti-attaques.Les appels à Management API sont soumis à une Auth0 Rate Limiting policy (politique de limite anti-attaques Auth0). Vous devez prendre cela en compte. Pour vous aider, Auth0 conseille généralement l’utilisation de la trousse SDK Auth0 qui convient à votre environnement de développement plutôt que d’appeler nos API directement.

​
Liens profonds vers des points de terminaison protégés

Il y a plusieurs raisons pour lesquelles quelqu’un peut créer un lien direct vers une page spécifique de votre application, page qui n’est accessible qu’aux utilisateurs authentifiés. Si cela est possible pour votre application, vous devez automatiquement rediriger votre utilisateur vers Auth0 s’il n’est pas authentifié. Une fois qu’ils se sont authentifiés et que le serveur d’autorisations les a renvoyés à votre application, vous pouvez les rediriger vers l’endroit où ils avaient l’intention d’aller au départ.

​
Meilleure pratique La plupart des cadres d’applications d’authentification modernes prennent en charge des logiciels médiateurs permettant de rediriger vers un serveur d’autorisation tel que Auth0. Lors de la sélection, voici quelques éléments clés à prendre en compte :

  • Prise en charge des clients confidentiels, des clients non confidentiels ou des deux
  • Prise en charge de la configuration via [point de terminaison d’exploration] (https://auth0.com/docs/get-started/applications/configure-applications-with-oidc-discovery « Configurer des applications avec OIDC Discovery » ou explicitement en ligne
  • Prise en charge de la validation des jetons, y compris les expirations, signatures, demandes et permissions
  • Prise en charge des si nécessaire :::

​
Authentifier l’utilisateur

L’authentification est le processus qui consiste à déterminer l’identité de l’utilisateur. Le résultat de l’authentification dans un contexte OIDC est un jeton d’ID. Ce jeton contient des informations sur l’utilisateur et ne peut être obtenu que si l’utilisateur s’authentifie à l’aide d’un ou plusieurs facteurs définis par le serveur d’autorisations (la forme la plus courante étant l’identifiant et le mot de passe). Outre l’obtention d’un jeton d’ID, vous devez également prendre en compte certains éléments :
Avant de passer en direct, vous devrez vous assurer que  seules les autorisations que vous utilisez pour chaque application sont activées dans votre configuration pour votre application.

​
Octroi de codes d’autorisation (avec ou sans PKCE)

Si votre trousse SDK ne prend en charge que l’octroi d’un code d’autorisation, ou si vous avez besoin d’un jeton d’accès ou d’un jeton d’actualisation, l’octroi d’un code d’autorisation (avec ou sans PKCE) peut également être utilisé pour récupérer un jeton d’ID. L’octroi du code d’autorisation comprend un appel supplémentaire à l’API pour échanger le code contre un jeton, ce qui peut entraîner une latence supplémentaire inutile si vous n’avez besoin que du jeton d’ID. Dans de nombreux cas, le flux hybride fonctionne pour fournir un accès optimal au jeton d’ID tout en tirant parti du flux d’octroi du code d’autorisation pour récupérer en toute sécurité les jetons d’accès et d’actualisation.
Bien qu’Auth0 prenne en charge l’utilisation de l’octroi implicite pour les applications basées sur un navigateur ne nécessitant qu’un jeton d’ID, il est conseillé d’utiliser l’octroi de code d’autorisation avec PKCE. Pour des informations détaillées, veuillez consulter Octroi implicite OAuth2 et SPA sur le blog Auth0.Si vous avez besoin d’un Jeton d’actualisation pour obtenir un nouveau jeton d’accès ou jeton d’ID sans avoir à réauthentifier l’utilisateur, vous devez alors utiliser l’octroi de code d’autorisation.

​
Protection contre les attaques

La raison pour laquelle les systèmes d’authentification sont importants est qu’ils empêchent les acteurs menaçants d’accéder aux applications et aux données des utilisateurs alors qu’ils ne le devraient pas. Nous voulons placer autant de barrières que possible entre ces acteurs menaçants et l’accès à nos systèmes. L’un des moyens les plus simples d’y parvenir est de s’assurer que votre protection contre les attaques avec Auth0 est correctement configurée. Prenez donc le temps de lire les conseils à ce sujet et assurez-vous que la protection fonctionne correctement dans votre cas.

​
Meilleure pratique

La détection d’anomalies est gérée en coulisses par Auth0 et constitue une excellente fonction 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.

​
SSO avec les systèmes hérités

Lors 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 meilleure pratique que nous recommandons est de prévoir une approche de style itératif lorsqu’il s’agit d’intégrer Auth0. Si vos applications prennent déjà en charge l’authentification unique (SSO) et que votre système hérité prend en charge des protocoles tels que OIDC ou , plusieurs options s’offrent à vous si vous souhaitez continuer à assurer l’authentification unique lors de l’intégration avec Auth0 :
  • Mettez à jour votre fournisseur d’identité existant dans votre système hérité de SSO pour rediriger vers Auth0 pour la connexion (p. ex., en utilisant SAML), ou
  • faites en sorte qu’Auth0 redirige vers votre système SSO hérité pour la connexion. Pour ce faire, vous devez configurer votre système hérité en tant qu’IdP dans Auth0 (c’est-à-dire en utilisant SAML ou OIDC).

​
Meilleure pratique La prise en charge d’une expérience d’authentification unique (SSO) avec votre système hérité peut ajouter de la complexité, mais cela peut en valoir la peine pour offrir une expérience utilisateur plus fluide lors de l’intégration avec Auth0. Si vous envisagez de suivre cette voie, planifier cela tôt peut aider à garantir d’y parvenir. Si vous ne disposez pas déjà d’un service centralisé pour l’authentification unique (SSO), la complexité de son intégration risque de ne pas justifier les avantages. :::

Il s’agit d’un sujet complexe qui nécessitera probablement des recherches supplémentaires en fonction de votre architecture héritée actuelle, et nous vous recommandons de ne vous pencher sur cette question que si votre système hérité prend actuellement en charge le SSO. Remarque - Si vous redirigez actuellement vos applications vers un système centralisé pour authentifier vos utilisateurs et que ce système ne demande des informations d’identification que si vous n’avez pas déjà une session avec le système centralisé, cela veut dire que vous disposez d’une implémentation SSO héritée.

​
Connexion d’entreprise

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 dans votre application afin que leur personnel n’ait pas besoin de stocker un autre ensemble d’identifiants. Il s’agit là d’un moyen efficace de simplifier l’authentification des utilisateurs sans compromettre la sécurité, et l’utilisation de la connexion universelle permet d’ajouter facilement la prise en charge des connexions d’entreprise avec un minimum de perturbations.

​
Meilleure pratique

Une fois que vous commencez à prendre en charge les connexions d’entreprise pour les utilisateurs, vous devez effectuer une certaine forme de [Découverte de domaine d’accueil] (#home-realm-discovery) afin de pouvoir déterminer la connexion vers laquelle envoyer 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, ainsi que certaines déclarations d’identité qu’Auth0 utilisera pour remplir la vérification de l’utilisateur.

​
Meilleure pratique « Utilisez votre propre identité » est une fonctionnalité intéressante à fournir, mais si vous ne la prenez pas en charge dès le premier jour, et parfois même si vous le faites, vous pouvez avoir une organization qui souhaite passer à son propre fournisseur d’identité après avoir déjà utilisé l’application pendant un certain temps. Vous aurez besoin d’un moyen de [Associer des comptes d’utilisateurs] (/users/concepts/overview-user-account-linking) pour fournir un moyen efficace d’associer la nouvelle identité à l’ancienne identité de la base de données. :::

​
Authentification multifacteur (MFA)

À une époque où l’utilisation abusive des identifiants des utilisateurs n’a jamais été aussi répandue, protéger vos systèmes alors qu’il est si courant que les pirates volent les informations d’identité des utilisateurs en général est un véritable défi. L’un des moyens les plus efficaces consiste à donner aux utilisateurs la possibilité de configurer un deuxième facteur de protection de leur compte. On parle plus communément d’authentification multifacteur (MFA). Ainsi, seul un utilisateur légitime pourra accéder à son compte, même s’il utilise un nom d’utilisateur et un mot de passe qui ont pu être compromis à partir d’une autre application.

​
Meilleure pratique

Il est assez courant pour les applications destinées aux clients de fournir aux utilisateurs une option pour ajouter un deuxième facteur plutôt que de les forcer à utiliser un deuxième facteur. Pour plus d’informations à ce sujet, voir [fournir à vos utilisateurs une option pour ajouter la MFA] (https://auth0.com/learn/multifactor-authentication-customers/). Auth0 prend en charge un certain nombre d’options différentes lorsqu’il s’agit d’activer le MFA pour protéger l’accès aux comptes utilisateurs, et il existe plusieurs pratiques pour s’assurer que vous fournirez réellement une barrière flexible de second facteur d’accès :
  • Auth0 Guardian : un service qui fournit à la fois la génération de notifications poussées et une application permettant d’autoriser ou de refuser les demandes. La fonctionnalité de notifications poussées envoie une notification à l’appareil pré-enregistré de l’utilisateur, généralement un téléphone portable 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) : permet d’enregistrer un appareil, tel que Google Authenticator, qui générera un mot de passe à usage unique qui change au fil du temps et qui peut être saisi comme deuxième facteur pour valider le compte d’un utilisateur.
  • Message texte (SMS) : pour l’envoi par SMS d’un code à usage unique que l’utilisateur est invité à saisir avant de pouvoir terminer l’authentification.
  • Communication vocale : pour délivrer 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 (MFA).
  • Courriel : permet d’utiliser votre compte courriel pour l’authentification multifacteur (MFA).
Alors que le flux de travail MFA utilisant des technologies telles que Guardian ou Google Authenticator est généralement fourni à partir d’une application séparée qui fonctionne 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 également une trousse SDK que vous pouvez utiliser pour construire un flux de travail à deuxième facteur directement dans vos applications d’appareil mobile existantes.

​
Guide de planification de projet

Nous fournissons un guide de planification en format PDF que vous pouvez télécharger; vous pouvez vous y référer pour de plus amples détails concernant nos stratégies recommandées. B2B IAM Project Planning Guide

​
Architecture pour organisations multiples (Multilocataire)

Plusieurs plateformes 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 s’applique à vous, nous vous conseillons de prendre le temps de lire nos conseils et bonnes pratiques pour ce type d’environnement. Architecture à organisations multiples
⌘I