Authentification (B2C)

Pour fournir des services à vos utilisateurs, vous devez être en mesure d’identifier ces derniers. Ce processus est appelé Authentification utilisateur. Il existe plusieurs façons d’authentifier un utilisateur (compte de réseau social, nom d’utilisateur et mot de passe, sans mot de passe) et il est souvent recommandé de ne pas se contenter que d’un seul facteur d’authentification, mais d’activer l’authentification multifacteur (MFA).

Plusieurs éléments doivent être pris en compte lors de l’examen des fonctionnalités et du flux de travail :

• À quel endroit les utilisateurs saisissent-ils leurs identifiants?

• Comment assurez-vous la sécurité des identifiants des utilisateurs?

• Comment comptez-vous maintenir votre système d’authentification?

• Comment pouvez-vous fournir une authentification par mot de passe à vos utilisateurs?

• Comment empêcher les pirates de se connecter en se faisant passer pour vos utilisateurs?

• Comment comptez-vous mettre en œuvre l’authentification dans plusieurs types d’applications?

• Comment faciliter la connexion de vos utilisateurs de langues différentes?

• Comment allez-vous offrir une bonne expérience à l’utilisateur alors que vous vous éloignez d’un système hérité d’authentification?

• Quels sont les éléments à prendre en compte lors de l’intégration d’applications avec Auth0?

• Les utilisateurs peuvent-ils se connecter en utilisant leurs comptes de réseaux sociaux existants (par ex., Facebook ou Google)?

• Vous faut-il une authentification multifacteur (MFA)?

• Que comptez-vous faire si votre service ne permet pas à l’utilisateur de se connecter au préalable?

• Êtes-vous en mesure de transmettre le même jeton d’accès d’un utilisateur d’une API à l’autre?

La connexion universelle Auth0 offre aux utilisateurs une expérience sûre et sécurisée, qu’il s’agisse de fournir un identifiant et un mot de passe pour l’ouverture d’une session ou d’autoriser les scénarios de type « Apportez votre propre identité » fournis par la connexion via un réseau social. Le fait de centraliser l’expérience d’ouverture de session en utilisant la connexion universelle présente également des avantages sur le plan de la reconnaissance de la marque, même si vous pensez devoir répondre à des exigences particulières en matière de marque de produit. Les widgets de l’interface utilisateur Auth0 généralement utilisés pour la connexion universelle offrent également une prise en charge prête à l’emploi de l’internationalisation pour les utilisateurs ayant des exigences linguistiques différentes, et la prise en charge prête à l’emploi des fonctions Auth0 telles que l’authentification multifacteur (MFA) et la protection contre les attaques vous permet de mettre en place des barrières afin d’empêcher les pirates informatiques de tenter d’accéder aux comptes de vos utilisateurs.

En permettant aux utilisateurs de s’identifier à l’aide d’un identifiant et d’un mot de passe, vous ne dépendez pas du statut des fournisseurs d’identité tiers pour l’accès de vos utilisateurs à 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 de connexion par ID utilisateur/mot de passe, ainsi que des conseils qui vous aideront à comprendre comment tirer parti de ces options. L’ajout d’une prise en charge de la connexion via un réseau social à un moment donné, en tant que facteur d’authentification primaire supplémentaire, vous offre une plus grande flexibilité et peut vous aider à mieux comprendre vos utilisateurs sans avoir à les questionner davantage en exploitant les informations déjà stockées par les différents fournisseurs de connexion via un réseau social.

Si vous disposez d’un magasin d’identités existant, vous devez également consulter la rubrique Migration des utilisateurs. Cette section traite des avantages que présente la migration vers le stockage d’identité géré par Auth0 en termes de sûreté et de sécurité.

Pour les applications destinées aux clients, OpenID Connect (OIDC) est le protocole standard le plus fréquemment utilisé dans l’industrie, et OIDC dispose d’un soutien citoyen de première classe dans Auth0. Auth0 prend en charge différentes approches pour l’intégration de différentes applications. Consultez la section sur l’intégration des applications pour obtenir les informations dont vous aurez besoin pour faire un choix éclairé.

Si vous appelez une API à partir d’une autre API, ou dans toute situation où il n’y a pas de contexte d’utilisateur authentifié, comme 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 é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 en consultant la rubrique Autorisation de communication entre machines de notre flux de travail sur l’autorisation.

Avez-vous ou prévoyez-vous d’avoir plus d’une application dans votre système? Si la réponse à cette question est oui, il vous faut une expérience de connexion centralisée. Pour obtenir une expérience d’authentification unique (SSO) transparente entre plusieurs applications, il est essentiel de disposer d’un emplacement centralisé où rediriger vos utilisateurs aux fins d’authentification. Cela vous permet de fournir à vos utilisateurs une expérience cohérente si vous prévoyez d’ajouter l’authentification au moyen de réseaux sociaux à l’avenir, d’ajouter des applications tierces à votre système ou d’ajouter l’authentification multifacteur (MFA) en tant qu’option (ou exigence) pour vos utilisateurs, et 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.

La connexion universelle Auth0 simplifie l’authentification des utilisateurs, en trois étapes simples (tous nos guides de démarrage rapide le démontrent et nos trousses SDK masquent la complexité pour vous également) :

1. Déterminez comment et quand vous souhaitez rediriger les utilisateurs à partir de votre application.

2. Mettez en place la stratégie de marque appropriée ou le code HTML personnalisé dans votre configuration Auth0.

3. Configurez votre application pour recevoir et traiter la réponse du serveur d’autorisation.

La plupart des applications de commerce électronique de détail (B2C) offrent à leur clientèle la possibilité de créer un nouvel ensemble d’identifiants. Il s’agit d’une forme d’authentification courante que tous les utilisateurs connaissent.

Auth0 propose plusieurs types d’authentification par nom d’utilisateur et mot de passe. Si vous disposez d’une application nouvelle sans base d’utilisateurs existante, une simple connexion à la base de données Auth0 prête à l’emploi vous fournira tout ce dont vous avez besoin pour procéder à l’authentification de vos utilisateurs. Cependant, si vous disposez d’une base d’utilisateurs existante, comme votre propre base de données d’utilisateurs ou un système LDAP existant, plusieurs options de migration s’offrent à vous, comme décrit dans notre guide sur la Migration des utilisateurs.

Quelle que soit la manière dont vous procédez à la fourniture des utilisateurs pour votre connexion à la base de données, l’authentification de ces utilisateurs est assez similaire. Vous devez présenter aux utilisateurs un formulaire dans lequel ils doivent saisir leur nom d’utilisateur et leur mot de passe. Comme indiqué dans le guide sur 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 si l’utilisateur s’est déjà authentifié et le cas échéant d’ignorer le formulaire de connexion.

Une fois la méthode d’authentification déterminée, l’étape suivante consiste à déterminer la manière dont l’authentification sera déclenchée. Chaque demande dispose généralement de son propre point de départ.

Comme expliqué précédemment, nous avons constaté que la plupart de nos clients utilisent OpenID Connect (OIDC) comme protocole standard pour leurs applications orientées client. La première chose à faire est de déterminer le flux OIDC à utiliser et de consulter notre guide sur le mappage des autorisations avant toute chose.

Si vous souhaitez permettre à des utilisateurs anonymes d’accéder à toute partie de notre application, vous devez déterminer si les utilisateurs seront redirigés immédiatement ou s’ils seront invités à le faire uniquement si 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 créer un lien profond vers une version (ou une zone) protégée de votre site, alors vous devrez déterminer les liens vers votre application qui entraîneront une redirection automatique vers Auth0.

Il est important de prendre en compte l’expérience de l’utilisateur lorsqu’il utilise votre application pour la première fois. Si votre application prend en charge l’accès anonyme des utilisateurs (pratique assez courante pour les applications de commerce électronique), différents scénarios doivent être envisagés :

• L’utilisateur revient-il dans l’application après s’être déjà connecté?

• Est-ce la première fois que l’utilisateur accède à l’application :

  • A-t-il déjà accédé à une autre application qui utilise le même locataire Auth0?

  • S’est-il déjà (peut-être pas depuis longtemps) authentifié sur cet appareil ou ce navigateur?

Lorsqu’un utilisateur anonyme accède à votre application, il peut souvent être souhaitable que l’application puisse savoir 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 monopage sans état. Par exemple, si vous pouvez déterminer que l’utilisateur est déjà connecté, il est possible de ne pas afficher de bouton de connexion dans l’en-tête de l’interface utilisateur de l’application et d’afficher à 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 qu’il soit invité à se connecter (s’il ne l’est pas). L’application peut alors afficher un bouton de connexion si nécessaire. Toutefois, si l’utilisateur est déjà connecté, vous recevrez des jetons et il ne sera pas nécessaire de lui présenter à nouveau un bouton de connexion.

De nombreuses raisons peuvent amener quelqu’un à se connecter directement à une page particulière de votre application qui n’est accessible qu’aux utilisateurs authentifiés. Si votre application le permet, vous devez automatiquement rediriger l’utilisateur vers Auth0 s’il n’est pas authentifié. Une fois qu’il s’est authentifié et que le serveur d’autorisation le renvoie à votre application, vous pouvez le rediriger vers la page qu’il souhaitait visiter.

L’authentification est le processus qui consiste à déterminer l’identité de l’utilisateur. Dans le contexte de l’OIDC, l’authentification aboutit à l’obtention d’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’autorisation (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 :

• Devons-nous également disposer d’un jeton d’accès pour appeler une API partagée?

• L’application que vous utilisez est-elle une application monopage qui ne nécessite qu’un seul jeton d’ID? Pour plus d’informations, voir Octroi d’un code d’autorisation avec PKCE.

• L’application que vous utilisez est-elle une application native (mobile ou de bureau) ou avez-vous besoin d’un jeton d’actualisation? Pour plus d’informations, voir Octroi d’un code d’autorisation avec 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’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 superflue si vous souhaitez uniquement obtenir le jeton d’ID. Dans de nombreux cas, le flux hybride est mis en œuvre 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.

La raison pour laquelle les systèmes d’authentification sont essentiels est d’empêcher les acteurs malveillants d’accéder à des applications et à des données d’utilisateur auxquelles ils ne devraient pas avoir accès. Le but est de placer autant de barrières que possible entre ces acteurs malveillants et l’accès à nos systèmes. L’un des moyens les plus simples d’y parvenir est de s’assurer que la protection contre les attaques assurée par Auth0 est correctement configurée; prenez donc le temps de lire les conseils à ce sujet et assurez-vous du bon fonctionnement de votre système d’authentification.

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 itérative lorsqu’il s’agit d’intégrer Auth0. Si vos applications participent déjà à l’authentification unique (SSO) et que votre ancien système d’identité prend en charge des protocoles tels que OIDC ou SAML, deux 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 ancien système SSO de sorte à rediriger les utilisateurs vers Auth0 au moment de la connexion (par ex., à l’aide de SAML), ou

• alors autorisez Auth0 à rediriger les utilisateurs vers votre ancien système SSO pour qu’ils se connectent. Pour ce faire, vous devez configurer votre ancien système en tant que fournisseur d’identité (IdP) dans Auth0 (c-à-d., au moyen de SAML ou d’OIDC).

Il s’agit d’un sujet complexe qui nécessitera probablement des recherches supplémentaires en fonction de votre architecture existante, c’est pourquoi nous vous recommandons de ne vous pencher sur cette question que si votre système existant prend actuellement en charge l’authentification unique (SSO). Remarque : si vous redirigez actuellement les utilisateurs de vos applications vers un système centralisé pour leur permettre de s’authentifier et que ce système ne demande des identifiants que si aucune session n’a déjà été ouverte avec le système centralisé, cela signifie que vous disposez d’une ancienne méthode d’authentification unique (SSO).

Le scénario « Apportez votre propre identité » proposé par Facebook, Google, etc., est un moyen précieux de simplifier l’expérience d’authentification de l’utilisateur sans compromettre la sécurité et la connexion universelle permet d’ajouter facilement la prise en charge des connexions via un réseau social avec un minimum de perturbation.

Avec la prise en charge de la connexion via un réseau social, les identités et les identifiants des utilisateurs sont gérés par le fournisseur de services de réseau social, de même que certaines revendications d’identité, qu’Auth0 utilisera pour remplir le profil de l’utilisateur. Auth0 peut également fournir un accès aux jetons d’accès des fournisseurs d’identité (IdP) des réseaux sociaux , de sorte que votre application puisse également appeler des API d’IdP des réseaux sociaux tiers au nom de l’utilisateur.

L’extension d’Auth0 Connexion par réseaux sociaux personnalisée étend l’authentification via un réseau social encore plus loin en vous permettant de vous connecter avec n’importe quel fournisseur tiers en conformité avec OpenID Connect (OIDC) qui n’est pas pris en charge dans la version standard. Par exemple, la prise en charge du fournisseur d’identités gouvernementales SwissID peut être configurée dans Auth0 à l’aide d’une connexion via un réseau social personnalisée.

À une époque où l’utilisation abusive des identifiants des utilisateurs atteint un niveau record, protéger vos systèmes alors qu’il est monnaie courante pour les pirates de voler les informations d’identité des utilisateurs représente un véritable défi. L’un des moyens les plus efficaces consiste à fournir aux utilisateurs la possibilité de configurer un second facteur pour protéger leur compte. Cette méthode est plus connue sous le nom d’authentification multifacteur (MFA). L’authentification multifacteur (MFA) permet de s’assurer que seul un utilisateur autorisé 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.

Auth0 prend en charge un certain nombre d’options différentes en ce qui concerne l’activation de l’authentification multifacteur (MFA) pour protéger l’accès aux comptes utilisateurs. Nous proposons plusieurs pratiques qui vous permettront de fournir 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 pour autoriser ou refuser les demandes. Une notification poussée est envoyée à 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 en appuyant simplement sur un bouton.

• Mot de passe à usage unique et durée définie (TOTP) : permet d’enregistrer un dispositif, tel que Google Authenticator, qui génère un mot de passe à usage unique qui change au fil du temps et qui peut être saisi en tant que second facteur de validation du compte d’un utilisateur.

• Message texte : pour l’envoi par message texte d’un code à usage unique que l’utilisateur est ensuite invité à saisir avant de pouvoir terminer l’authentification.

• Message vocal : 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 de messagerie pour l’authentification multifacteur (MFA).

Bien que le flux de travail MFA utilisant des technologies telles que Guardian ou Google Authenticator est généralement fourni via une application séparée qui fonctionne sur un appareil mobile ou une tablette, pour éviter que vos clients n’aient à télécharger une application séparée, Auth0 vous fournit également une trousse SDK que vous pouvez utiliser pour créer un flux de travail de second facteur directement dans vos applications mobiles existantes.

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.