Passer au contenu principal
Grâce à l’authentification renforcée, les applications qui permettent l’accès à différents types de ressources peuvent exiger des utilisateurs qu’ils s’authentifient à l’aide d’un mécanisme plus puissant pour accéder à des informations sensibles ou effectuer certaines transactions. Par exemple, un utilisateur peut être autorisé à accéder à des contenus contenant des données sensibles ou à réinitialiser son mot de passe uniquement après avoir confirmé son identité par authentification multifacteur (). Pour réaliser l’authentification renforcée pour votre application Web, vous allez créer une action qui exigera à l’utilisateur de s’authentifier par MFA lorsque l’application Web le demande. Vous allez aussi vérifier les demandes de jeton d’ID pour la MFA si l’utilisateur tente d’accéder à une page restreinte. Enfin, vous allez inviter l’utilisateur à s’authentifier si la MFA n’est pas incluse dans la demande.

​
Valider les jetons d’ID pour la MFA

Lorsqu’un utilisateur se connecte, vous obtenez un jeton d’ID qui contient des informations pertinentes sur la session de l’utilisateur sous forme de demandes. La demande pertinente est amr (référence des méthodes d’authentification), qui est un tableau JSON de chaînes indiquant la méthode d’authentification utilisée lors de la connexion. Elle doit être présente dans la charge utile du jeton d’ID et doit contenir la valeur mfa. Ses valeurs peuvent inclure l’une des valeurs de référence de méthode d’authentificationprédéfinies. Vu qu’elle peut contenir des demandes autres que mfa, lors de la validation, vous devez à la fois vérifier son existence et examiner son contenu pour y trouver 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é par 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 deuxième facteur, un nouveau jeton d’ID contenant la demande amr est généré et envoyé à l’application.
  1. Obtenir le jeton d’ID.
  2. Vérifier la signature du jeton qui est utilisée pour vérifier que l’expéditeur du jeton est bien celui qu’il prétend être et pour s’assurer que le message n’a pas été modifié en cours de route.
  3. Valider les demandes suivantes :
    DemandeDescription
    expExpiration du jeton
    issÉmetteur de jetons
    audDestinataire prévu du jeton
    amrSi amr n’existe pas dans la charge utile ou ne contient pas la valeur mfa, l’utilisateur ne s’est pas connecté avec la MFA. Si amr existe dans la charge utile et contient la valeur mfa, l’utilisateur s’est connecté avec la MFA.

​
Exceptions aux demandes AMR

La demande amr est requise, sauf dans les cas d’utilisation suivants :
  1. Dans les flux de connexion hébergés, la demande amr n’est injectée dans le jeton d’ID qu’après que l’utilisateur a réussi à relever un défi-réponse MFA. Lorsque l’application emploie l’authentification silencieuse ou les jetons d’actualisation pour les jetons d’ID nouvellement émis, la demande amrne sera pas nécessaire, car l’utilisateur a déjà terminé la connexion par MFA.
  2. Les jetons émis par l’API MFA ne contiennent pas la demande amr . La demande amr signale les méthodes d’authentification utilisées lorsque l’utilisateur reçoit le jeton d’ID. Pendant l’authentification de l’API MFA, l’application gère le flux d’authentification et peut imposer la MFA si cela s’avère nécessaire.
Dans les exemples ci-dessous, vous pouvez comparer les valeurs potentielles contenues dans la charge utile d’un jeton d’ID lorsqu’un utilisateur s’est authentifié par MFA et lorsqu’il ne l’a pas fait.

​
Exemple : Valeurs avec MFA

codeblockOld.header.login.logInButton codeblockOld.header.login.configureSnippet 
{
    "iss": "https://{yourDomain}/",
    "sub": "auth0|1a2b3c4d5e6f7g8h9i",
    "aud": "{yourClientId}",
    "iat": 1522838054,
    "exp": 1522874054,
    "acr": "http://schemas.openid.net/pape/policies/2007/06/multi-factor",
    "amr": [
        "mfa"
    ]
}

​
Exemple : Valeurs sans MFA

{
    "iss": "https://{yourDomain}/",
    "sub": "auth0|1a2b3c4d5e6f7g8h9i",
    "aud": "{yourClientId}",
    "iat": 1522838054,
    "exp": 1522874054
}

​
Scénarios : Données salariales avec notifications poussées

Dans le scénario suivant, une application Web authentifie un utilisateur avec un nom d’utilisateur et un mot de passe. Certains utilisateurs souhaitent accéder à un écran particulier affichant des données salariales, ils doivent donc s’authentifier par le facteur poussé Guardian.

​
Prérequis

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

​
Créer une action

Créer une action qui demande à l’utilisateur de s’authentifier par MFA lorsque l’application Web le demande. Rendez-vous dans le Tableau de bord > Actions > Flux, et créez une action qui comporte le contenu suivant : 
exports.onExecutePostLogin = async (event, api) => {
 const CLIENTS_WITH_MFA = ['REPLACE_WITH_YOUR_CLIENT_ID'];
 // run only for the specified clients
 if (CLIENTS_WITH_MFA.includes(event.client.client_id)) {
 // ask for MFA only if the web app said so in the authentication request
 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 identifiants des clients des applications auxquelles vous souhaitez que cette action s’applique. Vous pouvez la supprimer (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 les références de classe de contexte d’authentification (acr). Il s’agit d’une propriété facultative qui n’existe que lorsque l’application l’inclut dans la demande d’authentification adressée au serveur d’autorisation. Dans cet exemple, notre application Web l’inclura dans la demande d’authentification, mais uniquement lorsqu’un utilisateur qui ne s’est pas encore authentifié par MFA essaie d’accéder aux informations salariales. Lorsque notre application Web l’inclut, elle définit une valeur de http://schemas.openid.net/pape/policies/2007/06/multi-factor. Cette valeur signifie que nous voulons que le serveur d’autorisation exige la MFA. La propriété api.multifactor que nous avons définie dans notre code invite l’utilisateur à procéder par MFA, en utilisant l’une des méthodes proposées nous avons configurées dans le locataire. Pour en savoir plus sur la méthode api.multifactor.enable(), consultez Déclencheurs d’action : objet API post-connexion.
  • La politique http://schemas.openid.net/pape/policies/2007/06/multi-factor définit un mécanisme d’authentification où l’utilisateur final s’authentifie auprès du fournisseur en fournissant plus d’un facteur d’authentification, ou MFA. Pour en savoir plus, consultez Extension de la politique d’authentification du fournisseur OpenID 1.0.

​
Configurer l’application

Configurer l’application pour vérifier que l’utilisateur s’est authentifié par MFA lorsque celui-ci tente d’accéder à la page d’informations salariales restreintes. Lorsqu’un utilisateur s’est authentifié par MFA, les demandes du jeton d’ID contiennent la demande amr avec une valeur de mfa.) L’application Web affichera la page restreinte si l’utilisateur s’est déjà authentifié par MFA; sinon, l’application Web enverra une nouvelle demande d’authentification qui inclut le paramètre acr_values avec une valeur de : http://schemas.openid.net/pape/policies/2007/06/multi-factorqui déclenchera l’action. L’application Web dans ce scénario utilise le flux de code d’autorisation pour l’authentification, la requête est donc la suivante : 
https://{yourDomain}/authorize?
        audience=https://{yourDomain}/userinfo&
        scope=openid&
        response_type=code&
        client_id={yourClientId}&
        redirect_uri={https://yourApp/callback}&
        state={yourOpaqueValue}&
        acr_values=http://schemas.openid.net/pape/policies/2007/06/multi-factor
Après l’authentification de l’utilisateur par MFA, l’application Web reçoit le code d’autorisation, qu’elle doit échanger contre le nouveau jeton d’ID. Ce dernier devrait maintenant contenir la demande amr avec une valeur de mfa. Pour apprendre à échanger le code contre un jeton d’ID, consultez Ajouter une connexion utilisant le flux de code d’autorisation.

​
Valider un jeton d’ID

Dans ce scénario, effectuez les validations en utilisant le Code d’exemple de jeton Web JSON, qui vérifie la signature du jeton (jwt.verify), décode le jeton, vérifie si la charge utile contient amr, et, si c’est le cas, enregistre les résultats dans la console. 
const AUTH0_CLIENT_SECRET = '{yourClientSecret}';
const jwt = require('jsonwebtoken');

jwt.verify(id_token, AUTH0_CLIENT_SECRET, { algorithms: ['HS256'] }, function(err, decoded) {
  if (err) {
    console.log('invalid token');
    return;
  }

  if (Array.isArray(decoded.amr) && decoded.amr.indexOf('mfa') >= 0) {
    console.log('You used mfa');
    return;
  }

  console.log('you are not using mfa');
});

​
En savoir plus

⌘I