Passer au contenu principal
Avec l’authentification renforcée, les applications qui donnent accès à différents types de ressources peuvent exiger que les utilisateurs s’authentifient au moyen d’un mécanisme plus robuste pour accéder à des renseignements sensibles ou effectuer certaines transactions. Par exemple, un utilisateur peut être autorisé à accéder à des pages contenant des données sensibles ou à réinitialiser son mot de passe seulement après avoir confirmé son identité au moyen de l’ (MFA). Pour mettre en œuvre l’authentification renforcée dans votre application web, vous allez créer une Action qui demande à l’utilisateur de s’authentifier avec MFA lorsque l’application web le requiert, vérifier les revendications du pour MFA si l’utilisateur tente d’accéder à une page restreinte, puis demander à l’utilisateur de s’authentifier si MFA n’est pas inclus dans la revendication.

​
Valider les jetons d’identité pour la MFA

Lorsqu’un utilisateur se connecte, vous obtenez un jeton d’identité qui contient des informations pertinentes sur la session de l’utilisateur sous forme de revendications. La revendication pertinente est amr (référence des méthodes d’authentification), un tableau JSON de chaînes qui indique la méthode d’authentification utilisée lors de la connexion. Elle doit être présente dans le payload du jeton d’identité et doit contenir la valeur mfa. Ses valeurs peuvent inclure n’importe laquelle des Authentication Method Reference Values prédéfinies. Comme elle peut contenir des revendications autres que mfa, vous devez, lors de la validation, vérifier à la fois sa présence et si son contenu comprend la valeur mfa. Si un utilisateur tente d’accéder à une page restreinte et que le jeton indique qu’il ne s’est pas authentifié avec la MFA, vous pouvez alors relancer l’authentification, que vous avez configurée pour déclencher la MFA à l’aide d’une Action. Une fois que l’utilisateur a fourni le deuxième facteur, un nouveau jeton d’identité contenant la revendication amr est généré et envoyé à l’application.
  1. Obtenez le jeton d’identité.
  2. Vérifiez la signature du jeton, pour confirmer que l’expéditeur du jeton est bien celui qu’il prétend être et pour vous assurer que le message n’a pas été modifié en cours de route.
  3. Validez les revendications suivantes :
RevendicationDescription
expExpiration du jeton
issÉmetteur du jeton
audDestinataire prévu du jeton
amrSi amr n’est pas présent dans le payload ou ne contient pas la valeur mfa, l’utilisateur ne s’est pas connecté avec la MFA. Si amr est présent dans le payload et contient la valeur mfa, l’utilisateur s’est bien connecté avec la MFA.

​
Exceptions relatives à la revendication AMR

La revendication amr est requise, sauf dans les cas d’utilisation suivants :
  1. Dans les flux de connexion hébergés, la revendication amr n’est injectée dans le jeton d’identité qu’après que l’utilisateur a réussi un défi MFA. Si l’application utilise l’authentification silencieuse ou des Jetons d’actualisation pour des jetons d’identité nouvellement émis, la revendication amr ne sera pas présente, puisque l’utilisateur a déjà effectué une connexion avec MFA.
  2. Les jetons émis par l’API MFA ne contiennent pas la revendication amr. La revendication amr indique les méthodes d’authentification utilisées lorsque l’utilisateur reçoit l’ID Token. Dans le processus d’authentification de l’API MFA, l’application contrôle le flux d’authentification et peut imposer MFA au besoin.
Dans les exemples ci-dessous, vous pouvez comparer les valeurs possibles incluses dans le payload d’un jeton d’identité selon qu’un utilisateur s’est authentifié avec MFA ou non.

​
Exemple : valeurs avec MFA

​
Exemple : valeurs sans MFA

​
Scénario : Données sur les salaires avec notifications push

Dans le scénario suivant, une application Web authentifie un utilisateur à l’aide d’un nom d’utilisateur et d’un mot de passe. Certains utilisateurs veulent accéder à un écran précis qui affiche des données sur les salaires; ils doivent donc s’authentifier avec le facteur push Guardian.

​
Prérequis

Pour ce scénario, vous devez configurer les éléments suivants dans l’Auth0 Dashboard :

​
Créer une Action

Créez une Action qui demande à l’utilisateur de s’authentifier avec MFA lorsque l’application web en fait la demande. Accédez à Auth0 Dashboard > Actions > Flows, puis créez une Action avec le contenu suivant : 
exports.onExecutePostLogin = async (event, api) => {
 const CLIENTS_WITH_MFA = ['REPLACE_WITH_{yourClientId}'];
 // exécuter uniquement pour les applications spécifiées
 if (CLIENTS_WITH_MFA.includes(event.client.client_id)) {
 // demander la MFA uniquement si l'application web l'a spécifié dans la requête d'authentification
 if (event.transaction?.acr_values.includes('http://schemas.openid.net/pape/policies/2007/06/multi-factor')) {
 api.multifactor.enable('any', { allowRememberBrowser: false });
 }
 }
}
  • La variable CLIENTS_WITH_MFA contient les des applications auxquelles vous souhaitez appliquer cette Action. Vous pouvez supprimer cet élément (ainsi que la condition if qui suit) si vous n’en avez pas besoin.
  • La propriété event.transaction.acr_values est un tableau de chaînes qui contient la ou les références de classe du contexte d’authentification (acr). Il s’agit d’une propriété facultative qui n’existe que lorsque l’application l’inclut dans la requête d’authentification envoyée au . Dans cet exemple, notre application web l’inclura dans la requête d’authentification, mais seulement lorsqu’un utilisateur qui ne s’est pas déjà authentifié avec MFA tente d’accéder aux données salariales. Lorsque notre application web l’inclut, elle définit la valeur http://schemas.openid.net/pape/policies/2007/06/multi-factor, ce qui indique que nous voulons que le serveur d’autorisation exige la MFA; la valeur de la propriété api.multifactor que nous définissons dans notre code demandera alors à l’utilisateur d’effectuer la MFA à l’aide de l’une des méthodes disponibles configurées dans le locataire. Pour en savoir plus sur la méthode api.multifactor.enable(), consultez Action Triggers: objet API post-login.
  • La stratégie http://schemas.openid.net/pape/policies/2007/06/multi-factor définit un mécanisme d’authentification dans lequel l’utilisateur final s’authentifie auprès du fournisseur en fournissant plus d’un facteur d’authentification, c’est-à-dire la MFA. Pour en savoir plus, consultez OpenID Provider Authentication Policy Extension 1.0.

​
Configurer l’application

Configurez l’application pour vérifier que l’utilisateur s’est authentifié au moyen de la MFA lorsqu’il tente d’accéder à la page des renseignements salariaux restreints. (Lorsqu’un utilisateur s’est authentifié avec la MFA, le jeton d’identité contient la revendication amr avec la valeur mfa.) Si l’utilisateur s’est déjà authentifié avec la MFA, l’application Web affichera la page restreinte; sinon, l’application Web enverra une nouvelle demande d’authentification qui inclut le paramètre acr_values avec la valeur suivante : http://schemas.openid.net/pape/policies/2007/06/multi-factor, ce qui déclenchera l’Action. L’application Web, dans ce scénario, utilise le flux de code d’autorisation pour s’authentifier; la demande est donc la suivante : Une fois l’utilisateur authentifié avec MFA, l’application web reçoit le code d’autorisation, qui doit être échangé contre le nouveau jeton d’identité. Celui-ci devrait maintenant contenir la revendication amr ayant pour valeur mfa. Pour savoir comment échanger le code contre un jeton d’identité, consultez Ajouter Login à l’aide du flux de code d’autorisation.

​
Valider le jeton d’identité

Dans ce scénario, effectuez les validations à l’aide de l’exemple de code JSON Web Token, qui vérifie la signature du jeton (jwt.verify), décode le jeton, vérifie si le payload contient amr et, le cas échéant, affiche les résultats dans la console.

​
En savoir plus