Skip to main content
Pour fournir des services à vos utilisateurs, vous devez être en mesure d’identifier qui ils sont. Ce processus s’appelle l’authentification des utilisateurs. Il existe plusieurs façons d’authentifier un utilisateur — au moyen de comptes de médias sociaux, d’un nom d’utilisateur et mot de passe, ou en mode — et il est souvent recommandé d’aller au-delà d’un premier facteur en activant l’ (MFA).

​
Bonne pratique

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 vous authentifierez vos utilisateurs. Offrir plusieurs facteurs primaires et/ou exiger plus d’un facteur pendant l’authentification sont deux moyens d’assurer les deux.
Il y a plusieurs éléments à prendre en considération 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 assurerez-vous la maintenance de votre système d’authentification ?
  • Comment pouvez-vous offrir une authentification par mot de passe à vos utilisateurs ?
  • Comment pouvez-vous empêcher des pirates d’essayer de se connecter à la place de vos utilisateurs ?
  • Comment mettrez-vous en œuvre l’authentification dans différents types d’applications ?
  • Comment pouvez-vous faciliter la connexion pour vos utilisateurs de différentes langues ?
  • Comment offrirez-vous une bonne expérience utilisateur pendant la migration hors de tout système d’authentification hérité ?
  • Que devriez-vous prendre en considération lors de l’intégration d’applications avec Auth0 ?
  • Les utilisateurs peuvent-ils se connecter avec leurs comptes sociaux existants (p. ex., Facebook ou Google) ?
  • Devez-vous offrir l’authentification multifacteur ?
  • Que faites-vous si vous avez un service qui n’offre aucun moyen à l’utilisateur de se connecter à l’avance ?
  • Pouvez-vous transmettre le même utilisateur d’une API à une autre ?
Auth0 Universal Login offre aux utilisateurs une expérience sûre et sécurisée, que vous choisissiez d’offrir une connexion par identifiants nom d’utilisateur/mot de passe ou de permettre les scénarios dits Bring Your Own Identity offerts par le Social Login. Il y a aussi des avantages sur le plan de la reconnaissance de l’image de marque à centraliser l’expérience de connexion avec , même si vous estimez devoir également répondre à des exigences propres au produit en matière d’image de marque. Les widgets d’interface utilisateur d’Auth0 habituellement utilisés avec Universal Login offrent aussi une prise en charge prête à l’emploi de l’internationalisation pour les utilisateurs ayant différentes exigences linguistiques, et la prise en charge prête à l’emploi de fonctionnalités Auth0 comme la MFA et la protection contre les attaques vous permet de mettre en place des mesures pour empêcher des pirates de tenter d’accéder aux comptes des utilisateurs. Permettre aux utilisateurs de se connecter au moyen d’identifiants nom d’utilisateur/mot de passe signifie que vous ne dépendez pas du bon fonctionnement des tiers pour que vos utilisateurs accèdent à votre système. Vous avez également les moyens d’exiger que les identifiants utilisés respectent vos politiques d’entreprise. Auth0 vous aide en vous offrant plusieurs options pour prendre en charge les connexions par nom d’utilisateur/mot de passe, et les directives fournies vous aideront à comprendre comment tirer parti de ces options. Ajouter une prise en charge sociale à une certaine étape, comme facteur d’authentification primaire supplémentaire, vous offre une plus grande flexibilité et peut vous aider à mieux comprendre vos utilisateurs sans devoir leur poser d’autres questions, en tirant parti des renseignements déjà stockés par les divers fournisseurs de connexion sociale. Si vous avez déjà un ancien répertoire d’identités, vous voudrez aussi consulter migration des utilisateurs. Cette section présente les avantages d’une migration vers le stockage des identités géré par Auth0 sur les plans de la sûreté et de la sécurité. Pour les applications destinées à la clientèle, Connect (OIDC) est le protocole standard du secteur le plus couramment utilisé, et OIDC est pris en charge de façon native par Auth0. Auth0 prend en charge diverses approches pour intégrer différents types d’applications; vous voudrez donc consulter la section sur l’intégration d’application pour obtenir l’information nécessaire à un choix éclairé. Lorsqu’on appelle une API depuis une autre API, 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 é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 volet sur l’autorisation, sous l’autorisation machine-to-machine (m2m).

​
Universal Login

Avez-vous, ou prévoyez-vous avoir, 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 (SSO) fluide entre plusieurs applications, il est essentiel de disposer d’un point central vers lequel rediriger vos utilisateurs pour l’authentification. Vous pouvez ainsi offrir à vos utilisateurs une expérience cohérente si vous ajoutez de l’authentification sociale plus tard, intégrez des applications tierces à votre système ou proposez l’authentification multifacteur comme option (ou exigence) — tout en profitant de nouvelles fonctionnalités pour améliorer leur expérience avec peu, voire aucun, effort de développement supplémentaire.

​
Pratique exemplaire

Si vous avez plus d’une application, la pratique exemplaire consiste à rediriger l’utilisateur vers un point central pour l’authentifier. Avec Auth0, cela signifie tirer parti de Universal Login, qui offre d’emblée de nombreux avantages sur le plan de la sécurité et de l’expérience utilisateur, y compris le SSO.
Auth0 Universal Login fait de l’authentification des utilisateurs un processus simple et rapide qui peut être réalisé en trois étapes faciles (tous nos Quickstarts le démontrent, et nos SDKs en masquent aussi la complexité) :
  1. Déterminez comment et quand vous souhaitez rediriger depuis votre application.
  2. Configurez l’image de marque appropriée et/ou du HTML personnalisé dans votre configuration Auth0.
  3. Configurez votre application pour recevoir et traiter la réponse du serveur d’autorisation.

​
Authentification par nom d’utilisateur et mot de passe

Presque toutes les applications B2C permettent à leurs clients de créer de nouveaux identifiants. Il s’agit d’une forme courante d’authentification que tous les utilisateurs connaissent bien. Dans Auth0, l’authentification par nom d’utilisateur et mot de passe se présente sous plusieurs formes. Si votre application est nouvelle et ne compte encore aucun utilisateur, une simple Database Connection prête à l’emploi d’Auth0 vous donnera tout ce qu’il faut pour commencer à authentifier vos utilisateurs. En revanche, si vous avez un ancien répertoire d’utilisateurs — par exemple votre propre base de données d’utilisateurs ou un système LDAP existant — différentes options s’offrent à vous pour migrer vos utilisateurs, comme l’explique notre guide sur la migration des utilisateurs. Quelle que soit la façon dont vous provisionnez les utilisateurs dans votre connexion de base de données, l’authentification de ces utilisateurs reste sensiblement la même. Vous devez leur présenter un formulaire dans lequel ils entreront leur nom d’utilisateur et leur mot de passe. Comme indiqué dans la section sur Universal Login, la manière 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 pour y recueillir ces renseignements. Auth0 peut ainsi déterminer s’ils se sont déjà authentifiés et ne pas afficher le formulaire de connexion lorsqu’il n’est pas nécessaire.

​
Bonne pratique

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 évite aussi de demander des identifiants inutilement. Consultez Universal Login pour en savoir plus.

​
Intégration de l’application

Une fois que vous avez déterminé comment vous souhaitez authentifier vos utilisateurs, l’étape suivante consiste à établir comment vous allez lancer cette authentification. Chaque application aura généralement son propre point de départ.
Les applications mobiles Native (et les applications de bureau) devraient utiliser le navigateur du 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 à la clientèle. Déterminer quel flux OIDC utiliser est votre première tâche, et vous devriez commencer par consulter d’abord nos conseils sur le grant mapping. Si vous souhaitez permettre à des utilisateurs anonymes d’accéder à une partie de votre application, vous devez déterminer si vous allez les rediriger immédiatement ou ne leur demander de se rediriger qu’au besoin (ou peut-être une combinaison des deux; consultez Redirect Users After Login pour en savoir plus). Si les utilisateurs peuvent accéder directement, par lien profond, à une version protégée (ou à une zone protégée) de votre site, vous devrez déterminer quels liens vers votre application déclencheront une redirection automatique vers Auth0.

​
Accès anonyme

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, 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 tenant 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 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 si ce n’est pas le cas. L’application pourra alors afficher un bouton de connexion au besoin. Si l’utilisateur est déjà connecté, toutefois, 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 l’utilisateur 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 régulation afin d’éviter la latence ou une limitation du nombre de requêtes.Les requêtes adressées à la Management API sont assujetties à la politique de limitation du nombre de requêtes d’Auth0. Vous devez en tenir compte et, pour vous aider, Auth0 recommande généralement d’utiliser l’Auth0 SDK 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 créer un lien direct vers une page précise de votre application qui n’est accessible qu’aux utilisateurs authentifiés. Si c’est le cas pour votre application, vous devriez rediriger automatiquement l’utilisateur vers Auth0 s’il n’est pas authentifié. Une fois qu’il s’authentifie et que le le renvoie vers votre application, vous pouvez le rediriger vers l’endroit où il voulait aller au départ.

​
Bonne pratique

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 :
  • La prise en charge des clients confidentiels, des clients publics ou des deux
  • La prise en charge de la configuration au moyen du point de terminaison de découverte ou définie explicitement en ligne
  • La prise en charge de la validation des jetons, y compris l’expiration, les signatures, les claims et les scopes
  • La prise en charge des , au besoin

​
Authentification de l’utilisateur

L’authentification est le processus qui permet d’établir l’identité de l’utilisateur. Le résultat de l’authentification dans un contexte OIDC 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 dont vous devrez peut-être tenir compte, en plus de l’obtention d’un ID Token :
Avant de passer 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.

​
Grant de code d’autorisation (avec ou sans PKCE)

Si votre SDK ne prend en charge que le grant de code d’autorisation, ou si vous avez besoin d’un jeton d’accès 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 tout ce dont vous avez besoin est l’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 flux de travail du grant de code d’autorisation pour récupérer les jetons d’accès et les Refresh Tokens de façon sécuritaire.
Bien qu’Auth0 prenne en charge l’utilisation du grant implicite pour les applications s’exécutant dans le navigateur qui n’ont besoin que d’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 nouveau jeton d’accès ou ID Token sans que l’utilisateur ait à s’authentifier de nouveau, vous devez utiliser le grant de code d’autorisation.

​
Protection contre les attaques

Les systèmes d’authentification sont essentiels, 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 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 est de vous assurer que votre protection contre les attaques avec Auth0 est correctement configurée. Prenez donc un moment pour consulter les recommandations à ce sujet et vérifier qu’elle fonctionne comme prévu dans votre cas.

​
Bonne pratique

La détection des anomalies est gérée en arrière-plan par Auth0 et constitue 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.

​
SSO avec des systèmes existants

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 bonne pratique que nous recommandons consiste à adopter une approche itérative pour l’intégration avec Auth0. Si vos applications utilisent déjà l’authentification unique (SSO) et que votre système d’identité existant prend en charge des protocoles comme OIDC ou , vous avez quelques options si vous souhaitez continuer d’offrir le SSO pendant votre intégration avec Auth0 :
  • Mettez à jour votre fournisseur d’identité actuel dans votre système SSO existant 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 existant pour la connexion. Cela exige de configurer votre système existant comme IdP dans Auth0 (c.-à-d. en utilisant soit SAML soit OIDC).

​
Bonne pratique

Prendre en charge une expérience SSO avec votre système existant peut ajouter de la complexité, mais cela peut valoir la peine pour offrir une expérience utilisateur plus fluide pendant votre intégration avec Auth0. Si vous envisagez cette avenue, le fait de la planifier tôt peut aider à en assurer la faisabilité. Si vous n’avez pas déjà de SSO dans un service centralisé, il est peu probable que la complexité nécessaire pour l’ajouter en vaille les bénéfices.
Il s’agit d’un sujet complexe qui exigera probablement une analyse plus approfondie selon votre architecture existante actuelle, et nous vous recommandons de ne l’examiner que si votre système existant prend déjà en charge le SSO. Remarque : si, actuellement, vos applications redirigent 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à de session avec lui, alors vous disposez d’une implémentation SSO existante.

​
Authentification sociale

Le scénario « apportez votre propre identité » offert par Facebook, Google, etc., 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 sociales avec un minimum de perturbations.
Auth0 offre une façon simple de tester les connexions sociales à l’aide de clés de développeur préconfigurées. Cependant, elles comportent des limites, et avant de passer en production, vous devrez configurer vos propres clés pour votre application en suivant les instructions du ou des fournisseurs sociaux que vous avez choisis.
Grâce à la prise en charge de sociale, les identités des utilisateurs et les informations d’authentification sont gérées par le fournisseur social, tout comme certaines claims d’identité, qu’Auth0 utilisera pour renseigner le profil de l’utilisateur. Auth0 peut aussi fournir l’accès aux jetons d’accès des fournisseurs d’identité sociale (IdP sociaux), afin que votre application puisse aussi effectuer des requêtes vers les API d’IdP sociaux tiers au nom de l’utilisateur.

​
Pratique exemplaire

Social est une excellente fonctionnalité à offrir, mais lorsque vous proposez plus d’une façon de se connecter, vous devez tenir compte de la possibilité que vos clients en utilisent réellement plus d’une. Par défaut, chaque identité d’utilisateur dans Auth0 possède son propre profil d’utilisateur; vous voudrez donc probablement envisager la capacité d’Auth0 à lier des comptes d’utilisateur afin d’associer efficacement un même profil d’utilisateur à plusieurs identités.
L’extension Custom Social Connections d’Auth0 pousse l’authentification sociale encore plus loin en vous permettant de vous connecter à tout fournisseur tiers compatible avec OpenID Connect (OIDC) qui n’est pas pris en charge d’emblée. Par exemple, la prise en charge du fournisseur d’identité gouvernementale SwissID peut être configurée dans Auth0 au moyen d’une connexion sociale personnalisée.

​
Authentification multifacteur (MFA)

À une époque où l’utilisation abusive des informations d’authentification des utilisateurs atteint des sommets, protéger vos systèmes représente un véritable défi, surtout alors qu’il est devenu si courant que des pirates volent les renseignements d’identité des utilisateurs. L’un des moyens les plus efficaces consiste toutefois à offrir aux utilisateurs la possibilité de configurer un second 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 mot de passe qui a pu être compromis dans une autre application.

​
Bonne pratique

Il est assez courant que les applications destinées aux clients offrent aux utilisateurs une option d’ajouter un second facteur plutôt que de les obliger à en utiliser un. 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 plusieurs pratiques permettent de vous assurer d’offrir une protection par second facteur à la fois souple et efficace :
  • 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 rejeter 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érera 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 par 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 offert au moyen d’une application distincte exécutée 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 un SDK que vous pouvez utiliser pour intégrer le workflow du second facteur directement dans vos applications mobiles existantes.

​
Guide de planification de projet

Nous fournissons un guide de planification au format PDF que vous pouvez télécharger et consulter pour en savoir plus sur les stratégies que nous recommandons. Guide de planification de projet B2C IAM