> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

# Autorisation transactionnelle avec le flux du code d’autorisation

Highly Regulated Identity permet l’autorisation transactionnelle avec le [flux du code d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow) en appliquant une <Tooltip tip="Authentification multifacteur (MFA) : processus d’authentification de l’utilisateur qui utilise un facteur en plus du nom d’utilisateur et mot de passe, comme un code envoyé par SMS." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=multi-factor+authentication">authentification multifacteur</Tooltip> (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 <Tooltip tip="Flux d’autorisation : grant d’autorisation (ou workflow) défini dans le framework OAuth 2.0." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=authorization+flow">flux d’autorisation</Tooltip> transactionnel peut s’appliquer à d’autres cas d’utilisation.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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.
</Callout>

<div id="prerequisites">
  ## Prérequis
</div>

<Warning>
  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`.
</Warning>

Avant de commencer, suivez les instructions de [Configurer Rich Authorization Requests](/docs/fr-ca/get-started/apis/configure-rich-authorization-requests) pour enregistrer les `authorization_details.types` de votre API ou de votre <Tooltip tip="Serveur de ressources : serveur qui héberge des ressources protégées. Les serveurs de ressources acceptent les requêtes visant des ressources protégées et y répondent." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=resource+server">serveur de ressources</Tooltip>.

<div id="end-to-end-flow">
  ## Flux de bout en bout
</div>

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](/docs/fr-ca/customize/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](#apply-dynamic-policy).
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.

<Frame>
  <img src="https://mintcdn.com/translations/6GE5Z24GDCZehiJ9/docs/images/cdy7uua7fh8z/6VYcY5YJRT9Ngaomj5f9yi/ea5f0caa41a7db330a1c1d980ce7116c/Transactional_Authorization__1_.png?fit=max&auto=format&n=6GE5Z24GDCZehiJ9&q=85&s=505d4914fb5878a9a84ddc738a1785cc" alt="" width="2200" height="2740" data-path="docs/images/cdy7uua7fh8z/6VYcY5YJRT9Ngaomj5f9yi/ea5f0caa41a7db330a1c1d980ce7116c/Transactional_Authorization__1_.png" />
</Frame>

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

<div id="communicate-transaction-details-and-redirect-to-auth0">
  ### Communiquer les détails de la transaction et rediriger vers Auth0
</div>

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](/docs/fr-ca/get-started/applications/configure-par).

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

```json lines theme={null}
"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](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-rar).

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 <Tooltip tip="Client Secret : secret utilisé par un client (application) pour s’authentifier auprès du serveur d’autorisation; il ne doit être connu que du client et du serveur d’autorisation et doit être suffisamment aléatoire pour ne pas pouvoir être deviné." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Client+Secret">Client Secret</Tooltip>. Auth0 offre les méthodes d’authentification par cryptographie à clé publique suivantes :

* [Private Key JWT](/docs/fr-ca/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt)
* [mutual-TLS (mTLS) for OAuth](/docs/fr-ca/get-started/authentication-and-authorization-flow/authenticate-with-mtls)

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.

<div id="apply-dynamic-policy">
  ### Appliquer une politique dynamique
</div>

Lorsque l’utilisateur se connecte sans utiliser <Tooltip tip="Single Sign-On (SSO) : service qui, après qu’un utilisateur s’est connecté à une application, le connecte automatiquement à d’autres applications." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=SSO">SSO</Tooltip> 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](/docs/fr-ca/authenticate).

Une fois l’utilisateur authentifié avec succès, Auth0 déclenche les [Actions](/docs/fr-ca/customize/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](/docs/fr-ca/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger/post-login-event-object). 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](/docs/fr-ca/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger/post-login-event-object) 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.

```js lines expandable theme={null}
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}});

      }
    }
};
```

<div id="challenge-the-user-to-get-transaction-details-approval">
  ### Soumettre l’utilisateur à un défi pour obtenir l’approbation des détails de la transaction
</div>

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](/docs/fr-ca/secure/multi-factor-authentication/customize-mfa/customize-mfa-selection-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](/docs/fr-ca/get-started/apis/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.

<div id="push-notifications">
  #### Notifications push
</div>

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

<Frame>
  <img src="https://mintcdn.com/translations/pvjQqAy3EB2TK6NP/docs/images/cdy7uua7fh8z/4mEJTT4VsAAAb6I0HhJI6r/851fe5ff489bfc9e5aaa2c52b4644f2c/Mobile_Push_-_English.png?fit=max&auto=format&n=pvjQqAy3EB2TK6NP&q=85&s=ef3ac05d3498b91f7333fcf99fd941b4" alt="" width="434" height="672" data-path="docs/images/cdy7uua7fh8z/4mEJTT4VsAAAb6I0HhJI6r/851fe5ff489bfc9e5aaa2c52b4644f2c/Mobile_Push_-_English.png" />
</Frame>

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](/docs/fr-ca/secure/multi-factor-authentication/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 :

<Tabs>
  <Tab title="iOS">
    ```swift lines theme={null}
    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
            }
        }
    }
    ```
  </Tab>

  <Tab title="Android">
    ```kotlin lines theme={null}
    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
            }
          });
    }
    ```
  </Tab>
</Tabs>

À 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](/docs/fr-ca/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger/post-login-api-object).

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

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](/docs/fr-ca/secure/multi-factor-authentication/fido-authentication-with-webauthn/configure-webauthn-device-biometrics-for-mfa).
</Callout>

<div id="sms-email-or-webauthn">
  #### SMS, courriel ou WebAuthn
</div>

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](/docs/fr-ca/get-started/apis/configure-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 :

<Frame>
  <img src="https://mintcdn.com/translations/xwVvTWJUElMm5YAK/docs/images/cdy7uua7fh8z/kYn2A0p2jTY5CUn1FsjVf/b926a1689ee9722e6b902e433a77223b/Phone_Challenge_-_English.png?fit=max&auto=format&n=xwVvTWJUElMm5YAK&q=85&s=2ba7944108a1cae3f062c68e7aa1ddfe" alt="" width="432" height="586" data-path="docs/images/cdy7uua7fh8z/kYn2A0p2jTY5CUn1FsjVf/b926a1689ee9722e6b902e433a77223b/Phone_Challenge_-_English.png" />
</Frame>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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.
</Callout>

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](#complete-the-operation).

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

<Warning>
  En vertu de la PSD2, [le courriel n’est pas un facteur d’authentification valide](https://www.eba.europa.eu/sites/default/documents/files/documents/10180/2622242/4bf4e536-69a5-44a5-a685-de42e292ef78/EBA%20Opinion%20on%20SCA%20elements%20under%20PSD2%20.pdf) 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.
</Warning>

<div id="no-challenge">
  #### Aucun défi
</div>

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.

<div id="complete-the-operation">
  ### Terminer l’opération
</div>

Pour terminer l’opération, Auth0 suit le [Flux du code d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow) 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 <Tooltip tip="Jeton d’accès : information d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisée pour accéder à une API." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=access+token">jeton d’accès</Tooltip> chiffré à l’aide de [JSON Web Encryption](/docs/fr-ca/secure/tokens/access-tokens/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é :

```json lines theme={null}
{
 "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`.