Authentification (B2B)

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 (MFA).

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, OpenID 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.

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 (SSO) 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.

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.

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.

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).

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.

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.

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.

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.

Une deuxième solution, plus complexe, consiste à stocker une carte des identifiants vers l’IdP 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.

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.

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.

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.

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.

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.

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.

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 :

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

• Votre application est-elle une application à page unique et qui ne nécessite qu’un jeton d’ID? Pour plus d’informations, consultez la rubrique Octroi de codes d’autorisation via PKCE (Proof Key for Code Exchange).

• Votre application est-elle une application native (mobile ou de bureau) et avez-vous besoin d’un jeton d’actualisation? Pour plus d’informations, consultez la rubrique Octroi de codes d’autorisation via 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.

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.

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 SAML, 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).

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.

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.

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.

À 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.

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.

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.

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