Passer au contenu principal
Pour 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 — au moyen 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 en activant l’ (MFA).

​
Pratique exemplaire

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 pendant l’authentification sont des moyens d’assurer les deux.
Voici un certain nombre d’éléments à prendre en considération en ce qui concerne les fonctionnalités et le flux de travail :
  • 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 l’authentification par mot de passe à vos utilisateurs ?
  • Comment pouvez-vous empêcher des pirates de tenter 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 simplifier la connexion pour vos utilisateurs de différentes langues ?
  • Comment offrirez-vous une bonne expérience utilisateur pendant la migration à partir d’un système d’authentification existant ?
  • Que devriez-vous prendre en compte lors de l’intégration d’applications avec Auth0 ?
  • Les utilisateurs peuvent-ils se connecter à l’aide de leurs comptes sociaux existants (par exemple, Facebook ou Google) ?
  • Devez-vous offrir l’authentification multifacteur ?
  • Que faites-vous si vous avez un service qui ne permet pas à l’utilisateur de se connecter au préalable ?
  • Pouvez-vous transmettre le même utilisateur d’une API à une autre ?
Auth0 Universal Login offre aux utilisateurs une expérience fiable et sécurisée, que vous choisissiez de proposer une connexion au moyen d’un identifiant utilisateur et d’un mot de passe ou d’autoriser les scénarios dits Bring Your Own Identity au moyen de la connexion sociale. La centralisation de l’expérience de connexion 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 utilisateur d’Auth0 habituellement utilisés avec Universal Login offrent également une prise en charge prête à l’emploi de l’internationalisation pour les utilisateurs ayant des besoins linguistiques différents, et la prise en charge prête à l’emploi de fonctionnalités d’Auth0 comme la MFA et la protection contre les attaques vous permet de mettre en place des barrières afin d’empêcher des pirates d’essayer d’accéder aux comptes des utilisateurs. Permettre aux utilisateurs de se connecter à l’aide 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 pouvez aussi exiger que les identifiants utilisés soient conformes à vos politiques d’entreprise. Auth0 vous aide à cet égard en vous offrant plusieurs options pour prendre en charge les connexions par identifiant utilisateur et mot de passe, et les indications fournies vous aideront à comprendre comment tirer parti de ces options. L’ajout de la prise en charge sociale à une étape donnée, comme facteur d’authentification principal supplémentaire, vous offre une plus grande souplesse et peut vous aider à mieux comprendre vos utilisateurs sans avoir à leur poser plus de questions, en tirant parti des informations déjà stockées 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 User Migration. Cette section présente les avantages de migrer vers le stockage d’identités géré par Auth0 du point de vue 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 est pris en charge nativement par Auth0. Auth0 prend en charge différentes approches pour intégrer différents types d’applications; vous voudrez donc consulter la section sur l’intégration d’applications pour obtenir l’information nécessaire afin de faire un choix éclairé. Lorsqu’une API appelle une autre API, ou dans toute situation où il n’y a aucun contexte d’utilisateur authentifié — par exemple un ou plusieurs travaux cron, des générateurs de rapports ou des systèmes d’intégration et de 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 un seul appel. Vous pouvez en apprendre davantage à ce sujet dans notre section sur l’autorisation, sous autorisation machine à machine (m2m).

​
Universal Login

Avez-vous, ou aurez-vous, plus d’une application dans votre système? Si oui, vous aurez avantage à offrir une expérience de connexion centralisée. Pour offrir une expérience fluide d’ (SSO) entre plusieurs applications, il est essentiel de disposer d’un emplacement centralisé vers lequel rediriger vos utilisateurs pour l’authentification. Vous pouvez ainsi leur offrir une expérience cohérente si vous ajoutez ultérieurement l’authentification sociale, des applications tierces à votre système, ou 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.

​
Bonne pratique

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, y compris le SSO.
Auth0 Universal Login simplifie l’authentification des utilisateurs, qui peut se faire en trois étapes simples (tous nos Quickstarts le démontrent, et nos SDK 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 d’authentification courante que tous les utilisateurs connaissent bien. Dans Auth0, l’authentification par nom d’utilisateur et mot de passe se décline en plusieurs variantes. Si votre application est nouvelle et ne compte aucun utilisateur existant, une simple connexion de base de données 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éférentiel d’utilisateurs — par exemple votre propre base de données d’utilisateurs ou un système LDAP existant — vous disposez de plusieurs options pour migrer vos utilisateurs, comme indiqué dans notre guide sur la migration des utilisateurs. Peu importe la façon dont vous provisionnez les utilisateurs pour votre connexion de base de données, l’authentification de ces utilisateurs reste assez semblable. Vous devez leur présenter un formulaire pour qu’ils saisissent leur nom d’utilisateur et leur mot de passe. Comme il est mentionné dans le guide sur Universal Login, le moyen le plus simple et le plus sûr d’authentifier des utilisateurs avec un nom d’utilisateur et un mot de passe consiste à les rediriger vers une page de connexion centralisée et à y recueillir ces renseignements. Cela permet à Auth0 de déterminer s’ils sont déjà authentifiés et d’ignorer complètement 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 de secrets utilisateur. Cela réduit aussi la nécessité de recueillir des identifiants inutilement. Consultez Universal Login pour en savoir plus.

​
Intégration de l’application

Une fois que vous avez déterminé comment vous voulez authentifier vos utilisateurs, l’étape suivante consiste à déterminer comment vous allez déclencher 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, sans quoi elles s’exposent à des risques de sécurité supplémentaires. Consultez Native Login pour en savoir plus.
Comme nous l’avons indiqué, 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. Votre première tâche consiste à déterminer quel flux OIDC utiliser, et vous devriez commencer par consulter notre guide de correspondance des types d’autorisation. Si vous voulez permettre à des utilisateurs anonymes d’accéder à une partie de votre application, vous devez déterminer si vous les redirigerez immédiatement ou seulement au besoin (ou encore utiliser une combinaison des deux ; consultez Redirect Users After Login pour en savoir plus). Si les utilisateurs peuvent créer un lien profond vers une version (ou une section) protégée de votre site, vous devrez déterminer quels liens vers votre application entraîneront 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 des utilisateurs (ce qui est assez courant pour les applications de commerce électronique), il y a différents scénarios à 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 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 est souvent 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 choisir de ne pas afficher de bouton de connexion dans l’en-tête de l’interface et de présenter plutôt un menu de compte ou de profil. Pour ce faire, vous devrez utiliser « l’authentification silencieuse ». L’authentification silencieuse vous permettra de vérifier si l’utilisateur est connecté sans l’inviter à 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é, 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 vers Auth0 peut être utile pour votre application, mais si cela entraîne un grand nombre de requêtes, vous devriez utiliser un mécanisme de limitation afin d’éviter la latence et/ou une limitation du débit.Les appels à la Management API sont assujettis à la stratégie 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 directs vers des points de terminaison protégés

Il existe plusieurs raisons pour lesquelles quelqu’un pourrait créer un lien direct vers une page précise de votre application, accessible uniquement 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’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 pour rediriger vers un serveur d’autorisation comme Auth0. Au moment d’en choisir un, voici quelques points importants à considérer :
  • Prise en charge des applications confidentielles, des applications non confidentielles ou des deux
  • Prise en charge d’une configuration via le point de terminaison de découverte ou définie explicitement
  • Prise en charge de la validation des jetons, y compris les dates d’expiration, les signatures, les claims et les scopes
  • Prise en charge des , au besoin

​
Authentification de 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 . 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, tels que définis par le serveur d’autorisation (la forme la plus courante étant l’identifiant utilisateur et le mot de passe). Voici quelques autres éléments à prendre en compte en plus de l’obtention d’un ID Token :
Avant de passer en production, vous devez vous assurer que seuls les types d’octroi que vous utilisez pour chaque application sont activés dans la configuration de votre application.

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

Si votre SDK prend uniquement en charge 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 additionnelle inutile si vous n’avez besoin que de 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 code d’autorisation pour récupérer les Jetons d’accès et les Jetons d’actualisation de façon sécuritaire.
Bien qu’Auth0 prenne en charge l’utilisation du flux implicite pour les applications exécutées dans le navigateur qui nécessitent uniquement 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 d’Auth0.Si vous avez besoin d’un Jeton d’actualisation afin d’obtenir un nouveau Jeton d’accès ou un ID Token sans devoir réauthentifier l’utilisateur, vous devez utiliser le flux de code d’autorisation.

​
Protection contre les attaques

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 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 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érifiez qu’elle fonctionne correctement.

​
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 prévoyez 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 hérités

Dans le cadre d’une restructuration à grande échelle, il n’est pas toujours possible — ni réaliste — de mettre à jour toutes vos applications d’un seul coup. En fait, la pratique exemplaire que nous recommandons consiste à adopter une approche itérative pour l’intégration à Auth0. Si vos applications prennent déjà en charge l’authentification unique (SSO) et que votre système d’identité hérité prend en charge des protocoles comme OIDC ou , deux options s’offrent à vous si vous souhaitez continuer à offrir le SSO pendant votre intégration à Auth0 :
  • Mettre à 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
  • Configurer Auth0 pour qu’il redirige vers votre système SSO hérité pour la connexion. Cela nécessite de configurer votre système hérité comme fournisseur d’identité (IdP) dans Auth0 (c.-à-d. en utilisant soit SAML, soit OIDC).

​
Pratique exemplaire

Prendre en charge une expérience 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 pendant votre intégration à Auth0. Si vous envisagez cette approche, le fait de la planifier tôt peut aider à garantir sa faisabilité. Si vous n’avez pas déjà de SSO dans un service centralisé, la complexité nécessaire pour l’ajouter n’en va probablement pas valoir les avantages.
Il s’agit d’un sujet complexe qui exigera probablement une analyse plus approfondie selon votre architecture héritée actuelle, et nous vous recommandons d’explorer cette option uniquement 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 ce système centralisé, vous avez alors une implémentation SSO héritée.

​
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 permet d’ajouter facilement la prise en charge des connexions sociales avec un minimum d’impact.
Auth0 offre un moyen simple de tester les connexions sociales à l’aide de clés de développeur préconfigurées. Toutefois, celles-ci comportent des limitations, et avant de passer en production, vous devrez configurer vos propres clés propres à l’application en suivant les instructions pour le ou les fournisseurs sociaux de votre choix.
Grâce à la prise en charge du social, les identités et les identifiants de connexion des utilisateurs sont gérés 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é sociaux (IdP sociaux), afin que votre application puisse également appeler des API tierces de fournisseurs d’identité sociaux au nom de l’utilisateur.

​
Bonne pratique

L’authentification sociale est une excellente fonctionnalité à offrir, mais lorsque vous proposez plus d’une façon de se connecter, vous devez tenir compte du fait que vos clients pourraient réellement en utiliser plusieurs. Par défaut, chaque identité d’utilisateur dans Auth0 possède son propre profil utilisateur; vous devriez donc probablement envisager la fonctionnalité d’Auth0 qui permet de lier des comptes d’utilisateurs, afin d’associer efficacement un profil utilisateur à plusieurs identités.
L’extension Custom Social Connections d’Auth0 va encore plus loin en matière d’authentification sociale en vous permettant de vous connecter à tout fournisseur tiers conforme à OpenID Connect (OIDC) qui n’est pas pris en charge d’emblée. Par exemple, la prise en charge du fournisseur d’identité gouvernemental 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 identifiants des utilisateurs atteint des sommets, protéger vos systèmes représente un défi, surtout quand le vol d’information d’identité est devenu 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, plus communément appelé authentification multifacteur. Cela garantit que seul un utilisateur légitime peut accéder à son compte, même si son nom d’utilisateur et son mot de passe ont été compromis dans une autre application.

​
Bonne pratique

Il est assez courant que les applications destinées aux clients offrent aux utilisateurs une option pour ajouter un deuxième facteur plutôt que de les obliger à l’utiliser. 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 et protéger l’accès aux comptes utilisateur. Il existe aussi plusieurs pratiques qui vous aideront à offrir une protection par deuxième facteur à la fois efficace et flexible :
  • Auth0 Guardian : un service qui fournit à la fois la génération de notifications Push et une application permettant d’autoriser ou de refuser des demandes. Push envoie une notification à l’appareil préenregistré de l’utilisateur — généralement un téléphone mobile ou une tablette — à partir duquel il peut immédiatement autoriser ou refuser l’accès au compte d’une simple pression sur un bouton.
  • Time-based One-Time Password (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 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.
  • Courriel : vous permet d’utiliser votre compte de courriel pour l’authentification multifacteur.
Bien que les flux de travail MFA utilisant des technologies comme Guardian ou Google Authenticator soient généralement fournis au moyen d’une application distincte exécutée sur un téléphone mobile ou une tablette, Auth0 vous offre également un SDK que vous pouvez utiliser pour intégrer le flux de travail du deuxième facteur directement dans vos applications mobiles existantes, si vous ne voulez pas que vos clients aient à télécharger une application distincte.

​
Guide de planification de projet

Nous mettons à votre disposition un guide de planification en 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 IAM B2C