> ## 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 Highly Regulated Identity, la solution Financial-Grade Identity™ d’Auth0.

# Highly Regulated Identity

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Pour utiliser les fonctionnalités de Highly Regulated Identity, vous devez avoir un Enterprise Plan avec le module complémentaire Highly Regulated Identity. Consultez [la tarification Auth0](https://auth0.com/pricing/) pour en savoir plus.
</Callout>

Highly Regulated Identity (HRI) est la solution Financial-Grade Identity™ d’Auth0 conçue pour sécuriser les opérations liées à des données sensibles et les services essentiels à votre entreprise. Initialement destinée aux secteurs hautement réglementés comme la finance et les soins de santé, Highly Regulated Identity rehausse le niveau de sécurité pour protéger un large éventail de cas d’utilisation, y compris, sans s’y limiter, les transferts d’argent, les paiements numériques et l’accès aux dossiers médicaux. Vous pouvez aussi utiliser Highly Regulated Identity pour d’autres opérations sensibles qui exigent une sécurité renforcée, par exemple pour approuver des modifications aux identifiants administratifs, sécuriser l’accès privilégié à un portail Web, et plus encore.

Pour sécuriser vos opérations d’affaires sensibles, Highly Regulated Identity offre :

* [Sécurité avancée avec OpenID Connect (FAPI)](#advanced-security-with-openid-connect-fapi-)
* [Authentification forte du client (SCA)](#strong-customer-authentication-sca-) et [liaison dynamique](#dynamic-linking)
* [Protection de la confidentialité et de l’intégrité](#confidentiality-and-integrity-protection)
* [Authentification forte des applications](#stronger-application-authentication)
* [Protéger les jetons d’accès avec Token Binding](#protect-access-tokens-with-token-binding)
* [Flux d’approbation personnalisables pour une meilleure expérience utilisateur](#customizable-approval-flows-for-better-user-experience)

<div id="advanced-security-with-openid-connect-fapi">
  ## Sécurité avancée avec OpenID Connect (FAPI)
</div>

[OpenID FAPI](https://openid.net/wg/fapi/specifications/) est un ensemble de spécifications en matière de sécurité et de protection des renseignements personnels élaboré par la <Tooltip tip="OpenID : norme ouverte d’authentification qui permet aux applications de vérifier l’identité des utilisateurs sans recueillir ni stocker leurs renseignements de connexion." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OpenID">OpenID</Tooltip> Foundation. Les API conformes aux normes FAPI sont classées comme étant de « calibre financier », ce qui signifie qu’elles offrent des mécanismes robustes d’authentification et d’autorisation qui contribuent à sécuriser l’accès aux données et services financiers, ainsi qu’à d’autres données et services sensibles.

Auth0 est un fournisseur FAPI certifié. Pour en savoir plus sur les améliorations de sécurité que nous avons apportées pour satisfaire aux normes FAPI, consultez les sections suivantes :

* [Protection de la confidentialité et de l’intégrité](#confidentiality-and-integrity-protection)
* [Authentification forte des applications](#stronger-application-authentication)
* [Protéger les jetons d’accès avec Token Binding](#protect-access-tokens-with-token-binding)

Pour en savoir plus sur FAPI, consultez le livre blanc d’OpenID [Open Banking, Open Data, and Financial-grade APIs](https://openid.net/wordpress-content/uploads/2022/03/OIDF-Whitepaper_Open-Banking-Open-Data-and-Financial-Grade-APIs_2022-03-16.pdf) ainsi que les [spécifications du groupe de travail FAPI](https://openid.net/wg/fapi/specifications/).

<Frame>
  <img src="https://mintcdn.com/translations/eVsQcTnbClN-oB7d/docs/images/cdy7uua7fh8z/20iajPMtmICMORUfaVQH7a/ec900e1007b3faebd66eb2508f46acb0/image17.png?fit=max&auto=format&n=eVsQcTnbClN-oB7d&q=85&s=97675c68c904a2d70020c10e4fdbb6a1" alt="" width="1758" height="899" data-path="docs/images/cdy7uua7fh8z/20iajPMtmICMORUfaVQH7a/ec900e1007b3faebd66eb2508f46acb0/image17.png" />
</Frame>

<div id="strong-customer-authentication-sca">
  ## Authentification forte du client (SCA)
</div>

<Frame>
  <img src="https://mintcdn.com/translations/3nS3prIggmJG9TUI/docs/images/cdy7uua7fh8z/3JDIerJcevImoIDRd7OfIy/98597a9164b66cde9ec7ddc23f3e849b/image14.png?fit=max&auto=format&n=3nS3prIggmJG9TUI&q=85&s=9b73d3b3161eafbcc1e54f6e0f1c7996" alt="" width="667" height="232" data-path="docs/images/cdy7uua7fh8z/3JDIerJcevImoIDRd7OfIy/98597a9164b66cde9ec7ddc23f3e849b/image14.png" />
</Frame>

Introduite par la [directive sur les services de paiement (PSD2)](https://www.europeanpaymentscouncil.eu/sites/default/files/infographic/2018-04/EPC_Infographic_PSD2_April%202018.pdf) de l’Union européenne, l’authentification forte du client (SCA) impose l’utilisation d’au moins deux facteurs d’authentification distincts parmi les trois suivants :

* Quelque chose que l’utilisateur connaît (p. ex., un mot de passe)
* Quelque chose que l’utilisateur possède (p. ex., un appareil)
* Quelque chose qui est propre à l’utilisateur (p. ex., une empreinte digitale)

Les facteurs d’authentification doivent être indépendants afin que la compromission de l’un ne compromette pas les autres. La SCA devient rapidement la norme mondiale pour protéger les données et les services sensibles.

Pour faciliter la conformité à la SCA, Auth0 offre divers facteurs d’authentification pour inscrire les utilisateurs et leur présenter une demande de vérification pendant une transaction de connexion. Highly Regulated Identity s’appuie sur les facteurs d’authentification suivants pour sécuriser vos transactions :

* Notifications push sur mobile
* SMS
* Email
* WebAuthn

À l’aide d’[Actions](/docs/fr-ca/customize/actions), vous pouvez déterminer dynamiquement quels facteurs d’authentification utiliser. Vous bénéficiez ainsi de la souplesse nécessaire pour personnaliser la logique de votre code. Par exemple, vous pouvez ajouter un deuxième facteur d’authentification pour les paiements de plus de 10 USD. Pour en savoir plus, consultez [Apply dynamic policy](/docs/fr-ca/secure/highly-regulated-identity/transactional-authorization-with-authorization-code-flow#apply-dynamic-policy).

<div id="dynamic-linking">
  ## Liaison dynamique
</div>

La DSP2 exige que les fournisseurs de services de paiement mettent en œuvre la liaison dynamique ainsi que l’authentification forte du client. La liaison dynamique présente à l’utilisateur les détails de la transaction pour qu’il les valide et les approuve explicitement, et elle lie de manière unique l’autorisation à ces détails de transaction. Cela garantit une bonne expérience utilisateur et favorise la conformité réglementaire.

Pour activer la liaison dynamique, vous pouvez utiliser Rich Authorization Requests (RAR) pour transmettre des données d’autorisation de transaction granulaires au <Tooltip tip="OAuth 2.0 : Cadre d’autorisation qui définit les protocoles et les workflows d’autorisation." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OAuth">OAuth</Tooltip> point de terminaison d’autorisation. L’exemple de code suivant montre un objet JSON `authorization_details`, qui contient des renseignements comme le type de paiement, le montant, la devise et le destinataire :

```json lines theme={null}
"authorization_details": [
 {
   "type": "one_time_payment",
   "amount": {
     "amount": 2460.46,
     "currency": "USD"
   },
   "sourceAccount": "xxxxxxxxxxx4567",
   "recipient": "Acme Travel, Inc.",
   "concept": "All Inclusive Resort Package for Two",
 }
]
```

`authorization_details` se voit attribuer une référence de transaction unique, qu’Auth0 utilise pour demander à l’utilisateur d’effectuer une authentification renforcée :

* Utilisez des notifications push pour afficher les détails de la transaction et obtenir une approbation sur un appareil distinct, comme une application mobile.
* Utilisez le SMS, le courriel ou WebAuthn pour confirmer les détails sur l’appareil à l’origine de la transaction une fois que l’utilisateur a terminé le deuxième facteur d’authentification.

<Warning>
  Ne transmettez pas de données d’autorisation de transaction granulaires ni d’autres données sensibles ou réglementées à l’extérieur de `authorization_details`.
</Warning>

Si l’utilisateur confirme les détails, la transaction se poursuit et Auth0 émet 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> associé aux authorization\_details désormais approuvées. Les développeurs peuvent aussi ajouter la référence de transaction unique au jeton d’accès. Ainsi, vos serveurs d’API peuvent ensuite valider les détails de la transaction approuvée lorsqu’ils reçoivent et traitent des requêtes d’API.

Pour en savoir plus sur RAR, 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).

<div id="confidentiality-and-integrity-protection">
  ## Protection de la confidentialité et de l’intégrité
</div>

Les détails d’autorisation peuvent inclure des numéros de compte, des montants, des noms de commerçants et d’autres renseignements très sensibles transmis dans des URL ou des jetons d’accès non sécurisés. Pour protéger les données sensibles contre les accès non autorisés et toute altération, Highly Regulated Identity offre une protection complète de la confidentialité et de l’intégrité.

<div id="protect-sensitive-data-in-the-front-channel">
  ### Protéger les données sensibles dans le front channel
</div>

Pour protéger les données sensibles dans le front channel, par exemple dans un navigateur Web, Highly Regulated Identity offre les solutions suivantes dans le cadre du profil de sécurité avancée FAPI 1.

<div id="pushed-authorization-requests-par">
  #### Requêtes d’autorisation poussées (PAR)
</div>

[PAR](https://datatracker.ietf.org/doc/rfc9126/) introduit un nouvel endpoint qui permet aux clients d’envoyer directement la charge utile d’une requête d’autorisation OAuth 2.0 au <Tooltip tip="Serveur d’autorisation : serveur centralisé qui aide à définir les limites de l’accès d’un utilisateur. Par exemple, votre serveur d’autorisation peut contrôler les données, les tâches et les fonctionnalités accessibles à un utilisateur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=authorization+server">serveur d’autorisation</Tooltip> (c.-à-d. Auth0, dans ce cas). Cela évite de faire passer les paramètres d’autorisation par le front channel non sécurisé (c.-à-d. le navigateur), ce qui réduit le risque qu’un intermédiaire accède sans autorisation aux paramètres d’autorisation.

Pour en savoir plus sur PAR, consultez [flux du code d’autorisation avec des requêtes d’autorisation poussées (PAR)](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-par) et [Configurer les requêtes d’autorisation poussées (PAR)](/docs/fr-ca/get-started/applications/configure-par).

<div id="jwt-secured-authorization-request-jar">
  #### Requête d’autorisation sécurisée par JWT (JAR)
</div>

[JAR](https://datatracker.ietf.org/doc/rfc9101/) est une extension du protocole OAuth2 qui renforce la sécurité des requêtes d’autorisation. Pour ce faire, elle utilise un paramètre de requête <Tooltip tip="JSON Web Token (JWT) : format standard de ID Token (et souvent de access token) utilisé pour représenter des claims de façon sécurisée entre deux parties." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=JSON+Web+Token">JSON Web Token</Tooltip> (JWT) afin de protéger l’intégrité et, au besoin, la confidentialité des paramètres de la requête d’autorisation.

Pour en savoir plus sur JAR, consultez [Flux du code d’autorisation avec requêtes d’autorisation sécurisées par JWT (JAR)](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-jar) et [Configurer les requêtes d’autorisation sécurisées par JWT (JAR)](/docs/fr-ca/get-started/applications/configure-jar).

<div id="protect-sensitive-data-in-access-tokens">
  #### Protéger les données sensibles dans les jetons d’accès
</div>

Pour protéger les détails d’autorisation inclus dans les jetons d’accès, Highly Regulated Identity offre un soutien pour utiliser [JSON Web Encryption (JWE)](https://datatracker.ietf.org/doc/html/rfc7516) afin de chiffrer la charge utile des jetons d’accès. Cela protège les jetons d’accès contre les fuites de données du côté des applications et contre l’inspection non autorisée des appels d’API par des intermédiaires.

Pour en savoir plus sur JWE, consultez [JSON Web Encryption](/docs/fr-ca/secure/tokens/access-tokens/json-web-encryption) et [Configurer JSON Web Encryption](/docs/fr-ca/get-started/apis/configure-json-web-encryption).

<div id="stronger-application-authentication">
  ## Authentification renforcée des applications
</div>

Pour renforcer la sécurité de l’authentification de votre application, Highly Regulated Identity offre deux options dans le cadre du profil FAPI 1 Advanced Security :

* [Private Key JWT](http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer) : cette méthode consiste à générer une paire de clés publique-privée servant d’informations d’authentification pour authentifier une application. Elle est déjà offerte aux clients du forfait Enterprise. Pour en savoir plus, consultez [Private Key JWT Authentication](/docs/fr-ca/secure/application-credentials#private-key-jwt-authentication).
* [mTLS for OAuth](https://datatracker.ietf.org/doc/html/rfc8705) : cette méthode consiste à enregistrer un certificat X.509 standard lié à une application dans votre tenant. Le certificat peut être émis par une AC ou être auto-signé. Conformément aux procédures mTLS standard, la clé privée correspondant au certificat est utilisée côté client pour établir le tunnel mTLS lors de l’envoi de requêtes vers les points de terminaison de votre tenant Auth0. Auth0 peut ainsi authentifier l’application sans transmettre de secrets sur le réseau. Pour en savoir plus, consultez [mTLS for OAuth](/docs/fr-ca/get-started/authentication-and-authorization-flow/authenticate-with-mtls).

Avec Private Key JWT et OAuth 2.0 mTLS, vous pouvez effectuer la rotation des informations d’authentification sans interruption en conservant temporairement deux clés et/ou certificats actifs en même temps pour une application donnée.

<div id="protect-access-tokens-with-token-binding">
  ## Protéger les jetons d’accès avec Token Binding
</div>

La prise en charge de mTLS permet aussi d’utiliser Token Binding ou Sender Constraining. Token Binding associe l’empreinte du certificat client utilisé pour établir le tunnel mTLS à un jeton d’accès. Lorsque le client appelle une API à l’aide du jeton d’accès lié au certificat, le serveur d’API peut alors vérifier si le client utilise aussi le certificat client associé. Par conséquent, même si le jeton d’accès est compromis, des personnes malveillantes qui ne connaissent pas le certificat client ne peuvent quand même pas accéder aux ressources protégées.

**Remarque :** Token Binding fonctionne indépendamment de la méthode d’authentification de l’application et n’exige pas l’enregistrement préalable du certificat client. Pour en savoir plus, consultez [Configure Sender Constraining](/docs/fr-ca/secure/sender-constraining/configure-sender-constraining).

<div id="customizable-approval-flows-for-better-user-experience">
  ## Flux d’approbation personnalisables pour une meilleure expérience utilisateur
</div>

Lors de la conception de solutions concrètes exigeant une sécurité de niveau financier, il est important de tenir compte de l’expérience utilisateur. Appliquer les mêmes flux d’authentification à toutes les transactions n’est pas aussi efficace que de les adapter dynamiquement en fonction des détails de la transaction et des cas d’utilisation.

Vous pouvez personnaliser votre flux d’authentification à l’aide des [Actions](/docs/fr-ca/customize/actions). Par exemple, une fois que l’utilisateur s’est connecté, vous pouvez examiner les détails de la transaction reçus au moyen de RAR, répertorier les facteurs d’authentification de l’utilisateur déjà configurés et validés, et utiliser des services externes, comme des moteurs d’évaluation des risques, pour déterminer le prochain facteur d’authentification à utiliser. Pour en savoir plus, consultez [Apply dynamic policy](/docs/fr-ca/secure/highly-regulated-identity/transactional-authorization-with-authorization-code-flow#apply-dynamic-policy).

Les nouveaux modèles <Tooltip tip="Universal Login : votre application redirige vers Universal Login, hébergé sur l’Authorization Server d’Auth0, pour vérifier l’identité d’un utilisateur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Universal+Login">Universal Login</Tooltip> vous permettent aussi de personnaliser les attributs affichés sur l’écran d’approbation de la transaction selon le type de transaction et d’autres détails d’autorisation. Pour en savoir plus, consultez [Configure Rich Authorization Requests (RAR)](/docs/fr-ca/get-started/apis/configure-rich-authorization-requests).

<div id="learn-more">
  ## En savoir plus
</div>

Pour savoir comment Highly Regulated Identity fonctionne de bout en bout pour autoriser une transaction ponctuelle, consultez [Autorisation transactionnelle avec le flux de code d’autorisation](/docs/fr-ca/secure/highly-regulated-identity/transactional-authorization-with-authorization-code-flow).