Autorisation transactionnelle avec le flux du code d’autorisation

Découvrez comment Highly Regulated Identity permet l’autorisation transactionnelle avec le flux du code d’autorisation.

Highly Regulated Identity permet l’autorisation transactionnelle avec le flux du code d’autorisation en appliquant une authentification multifacteur (MFA) renforcée pour autoriser une transaction. La MFA renforcée demande à l’utilisateur un deuxième facteur d’authentification afin d’autoriser explicitement les détails de la transaction d’une opération ponctuelle, ce qui est utile dans les cas d’utilisation qui exigent une sécurité de niveau financier :

• Sécuriser les opérations sensibles exécutées depuis vos propres services, comme l’approbation de virements bancaires, l’accès à l’historique des opérations et les changements aux identifiants d’accès.
• Sécuriser les opérations sensibles demandées depuis des services tiers, comme l’approbation de paiements numériques et l’autorisation d’un accès unique pour la vérification de compte.

Cet article vous présente le processus complet d’approbation d’un virement bancaire. Le même flux d’autorisation transactionnel peut s’appliquer à d’autres cas d’utilisation.

Vous devez configurer l’autorisation transactionnelle pour chaque API. Une fois activée, elle s’applique aux scopes et aux authorization_details.types de cette API.

​

Prérequis

Ne transmettez pas de données d’autorisation de transaction granulaires ni d’autres données sensibles ou réglementées en dehors de authorization_details.

Avant de commencer, suivez les instructions de Configurer Rich Authorization Requests pour enregistrer les authorization_details.types de votre API ou de votre serveur de ressources.

​

Flux de bout en bout

Le schéma suivant illustre le flux de bout en bout de l’autorisation transactionnelle avec la SCA contextuelle. Il comporte quatre phases principales :

1. Redirigez l’utilisateur de manière sécuritaire vers Auth0 avec les détails de la transaction. À cette étape, évitez d’exposer des renseignements sensibles sur le canal frontal (p. ex., le navigateur).
2. Appliquez une politique dynamique après l’authentification de l’utilisateur. À l’aide d’Actions, vous pouvez déterminer dynamiquement les prochaines étapes selon les détails de la transaction et d’autres renseignements obtenus de sources comme des API externes. Pour en savoir plus, consultez Appliquer une politique dynamique.
3. Soumettez l’utilisateur à un défi avec un deuxième facteur d’authentification et affichez les détails de la transaction afin qu’il puisse les approuver explicitement. Cette étape dépend du facteur d’authentification que vous avez choisi d’appliquer à l’aide d’Actions.
4. Obtenez le jeton d’accès et poursuivez l’opération sensible. Votre API valide les détails de la transaction approuvés associés au jeton d’accès.

Nous examinerons chacune de ces phases en détail dans les sections suivantes.

​

Communiquer les détails de la transaction et rediriger vers Auth0

L’utilisateur accède d’abord à votre application web après s’être authentifié avec Auth0. Dans notre exemple de cas d’utilisation, l’utilisateur demande ensuite un transfert d’argent à l’un de ses contacts.

Pour respecter les normes de sécurité de niveau financier, Highly Regulated Identity utilise les Pushed Authorization Requests (PAR) afin que les détails de la transaction ne transitent pas par le navigateur. Au lieu d’envoyer des paramètres de requête par l’entremise du navigateur vers le point de terminaison /authorize, PAR envoie directement les paramètres de votre backend vers un point de terminaison spécial, /par, au moyen d’une requête POST. Pour savoir comment le configurer, consultez Configurer les requêtes d’autorisation poussées.

Dans le corps de la requête PAR, les détails de la transaction sont envoyés dans l’objet JSON authorization_details :

"authorization_details": [
 {
   "type": "money_transfer",
   "instructedAmount": {
     "amount": 150,
     "currency": "USD"
   },
   "sourceAccount": "xxxxxxxxxxx1234",
   "destinationAccount": "xxxxxxxxxxx9876",
   "beneficiary": "Hanna Herwitz",
   "subject": "A Lannister Always Pays His Debts"
 }
]

Utilisez Actions pour examiner authorization_details afin de déterminer quels facteurs d’authentification utiliser en fonction de la transaction. Pour en savoir plus sur authorization_details et sur son utilisation avec PAR, consultez Flux du code d’autorisation avec Rich Authorization Requests.

Si vous voulez satisfaire aux exigences de conformité FAPI 1 Advanced Security, vous devez aussi utiliser la cryptographie à clé publique pour authentifier le backend auprès du point de terminaison /par ou /token. Cette méthode est plus sécuritaire que l’envoi d’un Client Secret. Auth0 offre les méthodes d’authentification par cryptographie à clé publique suivantes :

• Private Key JWT
• mutual-TLS (mTLS) for OAuth

Après avoir reçu une réponse positive à votre requête PAR, redirigez l’utilisateur vers le point de terminaison /authorize de votre tenant Auth0. Ajoutez le paramètre request_uri reçu dans la réponse PAR ainsi que le client_id comme seuls paramètres de requête, ce qui masque efficacement toute information sensible au navigateur.

​

Appliquer une politique dynamique

Lorsque l’utilisateur se connecte sans utiliser SSO et que le navigateur atteint le point de terminaison /authorize de votre tenant Auth0, Auth0 tente d’authentifier l’utilisateur. Dans notre exemple d’approbation d’un virement bancaire, Auth0 a déjà authentifié l’utilisateur pour lui permettre d’accéder à votre application web. Cependant, lorsqu’un tiers redirige l’utilisateur, par exemple pour un paiement numérique, Auth0 lui présente un écran de connexion. Pour en savoir plus sur le flux d’authentification, consultez la documentation Authenticate.

Une fois l’utilisateur authentifié avec succès, Auth0 déclenche les Actions post-login, qui exposent les détails de la transaction concernant l’utilisateur, l’application, le ou les facteurs d’authentification utilisés, et plus encore dans l’objet d’événement post-login. Dans l’objet d’événement post-login, la propriété event.transaction.requested_authorization_details contient les détails de la demande d’autorisation reçus à l’étape précédente.

Utilisez l’objet d’événement post-login pour décider de la marche à suivre pour la transaction. Par exemple, vous pouvez envoyer les détails de la transaction à un moteur de risque externe et, après avoir évalué le niveau de risque, déterminer s’il faut demander une authentification renforcée à l’aide du SMS, comme l’illustre l’exemple de code suivant.

exports.onExecutePostLogin = async (event, api) => {
  if (event.transaction?.requested_authorization_details.some(e => e.type === 'money_transfer')) {
      const axios = require('axios');

      //détails pour contacter le moteur d'évaluation des risques
      const risk_url = 'https://risk.example.org/score';
      const risk_options = {
        headers: {
          'Content-Type': 'application/json'
        }
      };

      const tx_data = {
        email: event.user.email,
        authorization_details: event.transaction?.requested_authorization_details
      };

      //envoyer les détails de l'opération au moteur d'évaluation des risques
      var risk = await axios.post(risk_url, tx_data, risk_options);

      //si l'opération est risquée, utiliser push pour autoriser
      if (risk.data.score >= 2) {
        api.authentication.challengeWith({ type: 'push-notification', options: {otpFallback: false}});

      }
    }
};

​

Soumettre l’utilisateur à un défi pour obtenir l’approbation des détails de la transaction

Vous pouvez personnaliser le facteur d’authentification à utiliser selon les facteurs déjà configurés par l’utilisateur, les facteurs déjà validés dans la session et/ou vos propres préférences. Vous pouvez aussi offrir à l’utilisateur d’autres options parmi lesquelles choisir. Pour en savoir plus, consultez Customize MFA Selection in New Universal Login.

De plus, pour SMS, le courriel et WebAuthn, vous pouvez personnaliser l’écran de consentement qu’Auth0 présente à l’utilisateur en y affichant les renseignements que vous souhaitez tirer de authorization_details et d’autres détails de la transaction. Pour en savoir plus, consultez Configure Rich Authorization Requests. Pour les notifications push, cela ne s’applique pas, puisque c’est l’application mobile qui affiche les détails de la transaction à l’utilisateur final.

Les sections suivantes expliquent les différents facteurs d’authentification que vous pouvez configurer pour l’autorisation transactionnelle.

​

Notifications push

Envoyez une notification push à l’appareil mobile inscrit de l’utilisateur pendant qu’Auth0 affiche l’écran d’attente de l’authentification multifacteur (MFA) sur l’appareil de consommation (par exemple, l’ordinateur portable où la transaction a été lancée).

Pour les notifications push, l’application mobile doit afficher les détails de la transaction à l’utilisateur afin d’obtenir son approbation explicite. Lors du déclenchement d’une notification push, vous pouvez désactiver la solution de secours par saisie manuelle d’un OTP en ajoutant l’option otpFallback: false.

Pour afficher les authorization_details à l’utilisateur, l’application mobile doit les récupérer à partir du paramètre txlnkid. Le SDK Auth0 Guardian transmet le paramètre txlnkid du tenant à l’application mobile au moyen d’une notification push.

Après avoir reçu la notification push par l’entremise du SDK Guardian, l’application mobile peut récupérer les consent details, y compris les authorization_details, à partir de l’Auth0 Consent API :

iOS

let device: AuthenticationDevice = // l’objet que vous avez obtenu lors de l’inscription
if let consentId = notification.transactionLinkingId {
    Guardian
        .consent(forDomain: {yourTenantDomain}, device: device)
        .fetch(consentId: consentId, notificationToken: notification.transactionToken)
        .start{result in
            switch result {
            case .success(let payload):
                let authorizationDetails = payload.requestedDetails.authorizationDetails
            case .failure(let cause):
                // un problème est survenu
        }
    }
}

Android

if (notification.getTransctionLinkingId() != null) {
    guardian
      .fetchConsent(notification, enrollment)
      .start(new Callback<Enrollment> {
        @Override
        void onSuccess(RichConsent consentDetails) {
          List<Map<String, Object>> authorizationDetails = consentDetails
                .getRequestedDetails()
                .getAuthorizationDetails();
        }

        @Override
        void onFailure(Throwable exception) {
          if (exception instanceof GuardianException) {
            GuardianException guardianException = (GuardianException) exception;
            if (guardianException.isResourceNotFound()) {
              // aucun consentement n’est associé à la transaction
            }
          }
          // un problème est survenu
        }
      });
}

À partir de la post-login Action, vous pouvez appeler api.multifactor.enable() avant api.authentication.challengeWith() pour supprimer l’option permettant de mémoriser cet appareil et obliger l’utilisateur à valider le défi push pour toutes les transactions. Pour en savoir plus, consultez Déclencheurs d’Actions : post-login - objet API.

Une fois que l’utilisateur approuve ou refuse l’opération, l’application mobile peut accepter ou rejeter le défi MFA. La transaction passe ensuite à l’étape Complete the operation.

Pour vérifier l’identité de l’utilisateur qui ouvre la notification push, vous pouvez ajouter l’authentification biométrique à l’application mobile. Pour en savoir plus, consultez Configurer WebAuthn avec Device Biometrics pour MFA.

​

SMS, courriel ou WebAuthn

Vous pouvez aussi configurer le téléphone, le courriel ou WebAuthn comme facteurs d’authentification pour soumettre l’utilisateur à un défi. Pour ces facteurs d’authentification, Auth0 présente à l’utilisateur l’écran d’attente MFA correspondant. Une fois que l’utilisateur valide le défi sur l’écran d’attente MFA, Auth0 lui affiche les détails de la transaction pour une approbation explicite. N’oubliez pas que vous devez Configurer Rich Authorization Requests pour que l’étape d’approbation fonctionne correctement.

Pour le facteur d’authentification par téléphone, Auth0 envoie un code de vérification à l’utilisateur par SMS ou appel vocal. La capture d’écran suivante montre l’écran d’attente MFA après l’envoi du code par SMS par Auth0 :

Dans Actions, vous pouvez appeler api.multifactor.enable('any', { allowRememberBrowser: false }) avant api.authentication.challengeWith pour supprimer l’option permettant de mémoriser cet appareil et obliger l’utilisateur à valider le défi push pour toutes les transactions.

L’utilisateur reçoit ensuite le SMS contenant le code de vérification.

Après avoir saisi le code de vérification dans l’écran d’attente MFA, l’utilisateur voit les détails de la transaction sur un écran de consentement dans Auth0. Une fois qu’il approuve ou refuse les détails de la transaction, la transaction passe à l’étape Terminer l’opération.

Le courriel et WebAuthn utilisent le même flux d’approbation transactionnelle ainsi que des écrans d’attente MFA et d’approbation explicite semblables.

En vertu de la PSD2, le courriel n’est pas un facteur d’authentification valide pour l’authentification forte du client. Nous vous recommandons d’utiliser un autre facteur d’authentification pour soumettre les utilisateurs à un défi afin de respecter les exigences de conformité de la PSD2.

​

Aucun défi

Si vous ne demandez pas à l’utilisateur de confirmer son identité au moyen d’un deuxième facteur d’authentification, Auth0 lui présente l’écran de consentement afin d’obtenir son approbation explicite des détails de la transaction.

​

Terminer l’opération

Pour terminer l’opération, Auth0 suit le Flux du code d’autorisation standard. Si la transaction est approuvée, le navigateur de l’utilisateur est redirigé vers votre application avec un code d’autorisation, qui est ensuite échangé contre un jeton d’accès chiffré à l’aide de JSON Web Encryption. Le jeton d’accès contient les authorization_details que vous avez transmis initialement. L’exemple de code suivant montre le contenu d’un jeton d’accès déchiffré :

{
 "iss": "https://my_tenant.auth0.com/",
 "sub": "auth0|me",
 "aud": "https://myapi.zewobnak.com",
 "iat": 1683661385,
 "exp": 1683747785,
 "azp": "my_client",
 "transaction_linking_id": "ce4842e8-2894-418a-b1f9-39a330cd4911",
 "authorization_details": [
   {
     "type": "money_transfer",
     "instructedAmount": {
       "amount": 150,
       "currency": "USD"
     },
     "sourceAccount": "xxxxxxxxxxx1234",
     "destinationAccount": "xxxxxxxxxxx9876",
     "beneficiary": "Hanna Herwitz",
     "subject": "A Lannister Always Pays His Debts",
   }
 ]
}

Transmettez le jeton d’accès à l’API qui gère le transfert d’argent. L’API vérifie ensuite les authorization_details du jeton d’accès afin de valider les détails de la transaction, comme le montant, l’émetteur, la destination, entre autres. Une fois la vérification terminée, le transfert d’argent est exécuté avec succès, et vous devriez voir l’écran d’approbation.

Si la transaction est rejetée à une étape quelconque, le navigateur de l’utilisateur affiche un code d’erreur access_denied.