Skip to main content
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 consulter des renseignements sensibles ou effectuer certaines transactions. Par exemple, un utilisateur peut être autorisé à accéder à des vues contenant des données sensibles ou à réinitialiser son mot de passe seulement après avoir confirmé son identité à l’aide de l’ (MFA). Pour mettre en œuvre l’authentification renforcée pour votre application web, vous allez créer une Action qui invite l’utilisateur à s’authentifier avec MFA lorsque l’application web en fait la demande, vérifier les claims du pour MFA si l’utilisateur tente d’accéder à une page restreinte, puis soumettre l’utilisateur à une vérification MFA si elle n’est pas incluse dans le claim.

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 claims. Le claim pertinent est amr (authentication methods reference), soit un tableau JSON de chaînes de caractères qui indique la méthode d’authentification utilisée lors de la connexion. Il doit être présent dans le payload du jeton d’identité et contenir la valeur mfa. Ses valeurs peuvent inclure n’importe laquelle des Authentication Method Reference Values prédéfinies. Comme il peut contenir des claims autres que mfa, lors de la validation, vous devez à la fois vérifier qu’il est présent et examiner son contenu pour voir s’il contient 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 relancer l’authentification, que vous avez configurée pour déclencher la MFA à l’aide d’une Action. Une fois que l’utilisateur fournit le second facteur, un nouveau jeton d’identité contenant le claim amr est généré et envoyé à l’application.
  1. Obtenez le jeton d’identité.
  2. Vérifiez la signature du jeton, qui sert à confirmer que l’émetteur du jeton est bien celui qu’il prétend être et à garantir que le message n’a pas été modifié en cours de route.
  3. Validez les claims suivants :

Exceptions concernant la claim amr

La claim amr est requise, sauf dans les cas d’utilisation suivants :
  1. Dans les flux de connexion hébergés, la claim amr n’est injectée dans le jeton d’identité qu’une fois que l’utilisateur a réussi une vérification MFA. Si l’application utilise l’authentification silencieuse ou des jetons d’actualisation pour des jetons d’identité nouvellement émis, la claim 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 claim amr. La claim amr indique les méthodes d’authentification utilisées au moment où l’utilisateur reçoit le jeton d’identité. Dans le processus d’authentification de l’API MFA, l’application contrôle le flux d’authentification et peut exiger la MFA au besoin.
Dans les exemples ci-dessous, vous pouvez comparer les valeurs possibles incluses dans la charge utile d’un jeton d’identité lorsqu’un utilisateur s’est authentifié avec MFA et lorsqu’il ne l’a pas fait.

Exemple : valeurs avec MFA

Exemple : valeurs sans MFA

Scénario : Données salariales avec notifications push

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

Prérequis

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

Créer une Action

Créez une Action qui demande à l’utilisateur de s’authentifier avec MFA lorsque l’application Web le demande. Allez à Dashboard > Actions > Flows, puis créez une Action qui contient le contenu suivant :
  • La variable CLIENTS_WITH_MFA contient les des applications auxquelles vous voulez que cette Action s’applique. 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 de caractères 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 à des renseignements salariaux. 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 MFA, et la valeur de la propriété api.multifactor que nous définissons dans notre code demandera à l’utilisateur d’effectuer une vérification MFA au moyen de l’une des méthodes disponibles configurées dans le tenant. Pour en savoir plus sur la méthode api.multifactor.enable(), consultez Déclencheurs d’Action : objet API de post-login.
  • La politique 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, ou 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é à l’aide de la MFA lorsqu’il tente d’accéder à la page contenant les renseignements salariaux restreints. (Lorsqu’un utilisateur s’est authentifié avec la MFA, les claims du jeton d’identité contiennent le claim 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 requête d’authentification qui comprend le paramètre acr_values avec la valeur : http://schemas.openid.net/pape/policies/2007/06/multi-factorce qui déclenchera l’Action. Dans ce scénario, l’application Web utilise le flux du code d’autorisation pour s’authentifier; la requête est donc la suivante : Une fois que l’utilisateur s’authentifie avec MFA, l’application web reçoit le code d’autorisation, qui doit être échangé contre le nouveau jeton d’identité, lequel devrait maintenant contenir la claim amr avec la valeur mfa. Pour savoir comment échanger le code contre un jeton d’identité, consultez Ajouter la connexion à 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, consigne les résultats dans la console.

En savoir plus