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

> Liez les jetons d’accès au certificat mTLS d’un client afin que seul le détenteur de ce certificat puisse utiliser le jeton pour envoyer une requête à un serveur de ressources.

# mTLS sender constraining

<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 [Auth0 Pricing](https://auth0.com/pricing/) pour en savoir plus.
</Callout>

La [restriction de l’émetteur](/docs/fr-ca/secure/sender-constraining) est un mécanisme de sécurité <Tooltip tip="OAuth 2.0 : cadre d’autorisation qui définit les protocoles et les flux d’autorisation." cta="Consulter le glossaire" href="/docs/fr-ca/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> qui lie de manière cryptographique les jetons d’accès et les <Tooltip tip="Refresh Token : jeton utilisé pour obtenir un nouveau jeton d’accès sans obliger les utilisateurs à se connecter de nouveau." cta="Consulter le glossaire" href="/docs/fr-ca/glossary?term=refresh+tokens">jetons d’actualisation</Tooltip> à l’application cliente qui les a demandés. Cela garantit que seule l’application cliente légitime qui a obtenu le <Tooltip tip="Access Token : justificatif d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisé pour accéder à une API." cta="Consulter le glossaire" href="/docs/fr-ca/glossary?term=access+token">jeton d’accès</Tooltip> peut l’utiliser pour accéder à des ressources protégées, offrant ainsi une solide protection contre le vol de jetons et les attaques par rejeu.

Les jetons d’accès liés à un certificat client Mutual-TLS (mTLS), ou la mTLS sender constraining, assurent cette liaison au moyen du certificat TLS du client. Avec mTLS, le jeton d’accès du client est lié à son certificat client unique, ce qui rend ce jeton inutilisable par toute autre partie.

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

Pour mettre en place le mTLS sender constraining, vous devez :

* Disposer d’un plan Enterprise avec le module complémentaire Highly Regulated Identity pour votre tenant Auth0.
* [Configurer sender constraining](/docs/fr-ca/secure/sender-constraining/configure-sender-constraining) pour votre application cliente et 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> dans Auth0.
* Vous assurer que votre application cliente est un <Tooltip tip="Client confidentiel : client (application) qui peut conserver des informations d’authentification en toute sécurité à l’aide d’un backend de confiance. Par exemple, une application Web avec un backend sécurisé et une application machine-à-machine (M2M)." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=confidential+client">client confidentiel</Tooltip>, puisque seuls les clients confidentiels prennent en charge le mTLS sender constraining.

<div id="how-it-works">
  ## Fonctionnement
</div>

Cette section explique comment obtenir et utiliser un jeton d’accès lié à mTLS.

<Frame>
  <img src="https://mintcdn.com/translations/mMSz-RNYLuOm2GmQ/docs/images/cdy7uua7fh8z/Nrf2Jm8Gq1yuMlS35jqDR/3972d735b883ea1ce5ae0999b678db2f/Screenshot_2025-07-30_at_4.07.34_PM.png?fit=max&auto=format&n=mMSz-RNYLuOm2GmQ&q=85&s=55ae89a9b547b93daf8645b891e9a36c" alt="" width="1222" height="852" data-path="docs/images/cdy7uua7fh8z/Nrf2Jm8Gq1yuMlS35jqDR/3972d735b883ea1ce5ae0999b678db2f/Screenshot_2025-07-30_at_4.07.34_PM.png" />
</Frame>

<div id="phase-1-request-an-mtls-bound-access-token">
  ## Phase 1 : Demander un jeton d’accès associé à mTLS
</div>

<div id="step-1-client-application-establishes-mtls-connection">
  ### Étape 1 : L’application cliente établit une connexion mTLS
</div>

* Avant de demander un jeton d’accès, votre application cliente amorce une négociation TLS avec le point de terminaison `/token` du <Tooltip tip="Serveur d’autorisation : serveur centralisé qui contribue à 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> d’Auth0.
* Pendant cette négociation, l’application cliente présente son certificat client au serveur d’autorisation d’Auth0 dans le cadre du processus d’authentification TLS mutuelle.

<div id="step-2-client-application-requests-access-token">
  ### Étape 2 : L’application cliente demande un jeton d’accès
</div>

* L’application cliente envoie une requête OAuth 2.0 standard pour obtenir un jeton, par exemple en utilisant `grant_type=client_credentials` ou `authorization_code`, au point de terminaison `/token` du serveur d’autorisation Auth0.
* La requête de jeton n’inclut aucun en-tête DPoP particulier ni aucune preuve <Tooltip tip="JSON Web Token (JWT) : format standard des ID Token (et souvent des jetons d’accès) 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=JWTs">JWTs</Tooltip> supplémentaire pour mTLS. La preuve de possession provient directement de la connexion mTLS.

<div id="step-3-auth0-authorization-server-processes-request-and-binds-token">
  ### Étape 3 : Auth0 Authorization Server traite la requête et associe le jeton
</div>

Lorsque Auth0 Authorization Server reçoit la requête de jeton via une connexion mTLS et que le certificat client est validé avec succès :

1. **Extrait le certificat :** Auth0 Authorization Server extrait le certificat client utilisé lors de l’échange mTLS.
2. **Calcule l’empreinte :** Auth0 Authorization Server calcule un hachage unique (empreinte) du certificat client.
3. **Associe le jeton :** Auth0 Authorization Server associe l’empreinte de ce certificat client au jeton d’accès émis en incluant une revendication de confirmation (`cnf`) dans la charge utile du jeton d’accès.

   * La revendication `cnf` contient le paramètre `x5t#S256`, soit l’empreinte SHA-256 du certificat client encodée en Base64url.
4. **Définit** `token_type`\*\* :\*\* Auth0 Authorization Server définit `token_type` sur DPoP. Cela diffère des jetons Bearer traditionnels et indique que le jeton est lié à une clé précise.
5. **Émet le jeton :** Auth0 Authorization Server émet le jeton d’accès mTLS à contrainte d’émetteur à votre application cliente.

L’exemple de code suivant présente une charge utile de jeton d’accès lié à un certificat mTLS :

```json lines theme={null}
{
  "iss": "https://server.example.com",
  "sub": "ty.webb@example.com",
  "exp": 1493726400,
  "nbf": 1493722800,
  "cnf": {
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
  }
}
```

Dans l’exemple de jeton d’accès lié à un certificat mTLS, `x5t#S256` indique que le jeton d’accès est associé à un certificat client mTLS dont l’empreinte SHA-256 est `bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2`.

<div id="phase-2-call-an-api-with-an-mtls-bound-access-token">
  ## Phase 2 : Effectuer une requête à une API avec un jeton d’accès associé à mTLS
</div>

<div id="step-4-client-application-calls-api">
  ### Étape 4 : L’application cliente appelle l’API
</div>

* Lorsque votre application cliente doit appeler une API qui applique la contrainte d’émetteur mTLS, elle doit établir une nouvelle connexion mTLS avec le serveur de ressources.
* Lors de cette négociation mTLS, l’application cliente présente de nouveau le même certificat client que celui utilisé pour obtenir le jeton d’accès.
* L’application cliente inclut ensuite le jeton d’accès lié à mTLS dans l’en-tête Authorization de la requête d’API en utilisant le schéma d’authentification DPoP :

```http lines theme={null}
Authorization: DPoP {your_mtls_bound_access_token}
```

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Bien que la RFC 8705 autorise un schéma Bearer avec des jetons liés à mTLS, Auth0 recommande d’utiliser DPoP pour faire respecter l’utilisation de jetons d’accès liés à mTLS. Cela indique explicitement au serveur de ressources qu’il doit s’attendre à un jeton lié cryptographiquement.
</Callout>

<div id="step-5-resource-server-verifies-token-and-certificate">
  ### Étape 5 : Le serveur de ressources vérifie le jeton et le certificat
</div>

Lorsque le serveur de ressources reçoit la requête d’API via une connexion mTLS :

1. **Demande le certificat client :** Le serveur de ressources récupère le certificat client à partir de la connexion mTLS établie.
2. **Extrait le jeton et la revendication cnf :** Le serveur de ressources extrait le jeton d’accès de l’en-tête `Authorization` et décode sa charge utile pour trouver la revendication `cnf` (confirmation), plus précisément la valeur `x5t#S256` (l’empreinte du certificat associé).
3. **Calcule l’empreinte du certificat actuel :** Le serveur de ressources calcule l’empreinte SHA-256 du certificat client reçu dans la connexion mTLS en cours.
4. **Compare les empreintes (vérification de la preuve de possession) :** Le serveur de ressources compare l’empreinte nouvellement calculée à l’empreinte `x5t#S256` de la revendication `cnf` du jeton d’accès.
5. **Autorise ou rejette la requête :**

   * Si les empreintes correspondent et que les autres validations du jeton, comme l’expiration, l’audience et l’émetteur, sont concluantes, la requête est autorisée.
   * Si le certificat client n’a pas été envoyé, ou si son empreinte ne correspond pas à celle de la revendication `cnf`, le serveur de ressources rejette la requête avec un code d’état `HTTP 401 Unauthorized` et un code d’erreur `invalid_token`.

Pour comprendre comment l’empreinte est calculée et le format de la revendication `cnf`, consultez la RFC 8705 : Mutual-TLS Client Certificate-Bound Access Tokens.

<div id="important-considerations">
  ## Considérations importantes
</div>

Lors de la mise en œuvre du mTLS sender constraining, tenez compte des éléments suivants :

* **Clients confidentiels uniquement :** le mTLS sender constraining est conçu et pris en charge uniquement pour les clients confidentiels, comme les services backend, qui peuvent gérer de façon sécuritaire des certificats clients et établir des connexions mTLS. Les <Tooltip tip="Client public : client (application) qui ne peut pas conserver des informations d’identification de façon sécuritaire. Exemples : une application native de bureau ou mobile et une application web côté client basée sur JavaScript (comme une application monopage (SPA))." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Public+clients">clients publics</Tooltip>, comme les SPA et les applications mobiles, devraient utiliser DPoP.
* **Gestion des certificats :** la sécurité de votre mise en œuvre de mTLS repose en grande partie sur vos pratiques de gestion des certificats, notamment la façon dont vous provisionnez, gérez et renouvelez les certificats clients.
* **Exigences en matière d’infrastructure :** la mise en œuvre de mTLS exige une infrastructure précise, y compris des proxys, des équilibreurs de charge et des API capables de terminer les connexions mTLS et de transmettre les informations du certificat client à l’application ou au serveur de ressources.
* **Application par le serveur de ressources :** lorsque vous activez le mTLS sender constraining pour une API dans Auth0, le serveur de ressources doit effectuer la vérification de l’empreinte numérique comme décrit à l’[Étape 5](#step-5-resource-server-verifies-token-and-certificate).
* **Stratégies de migration :** si vous migrez progressivement des clients vers mTLS, envisagez d’exposer votre API sur deux domaines : un domaine non mTLS pour les clients existants et un domaine compatible avec mTLS pour les clients qui peuvent l’utiliser. Sinon, vous pourriez implémenter une logique sur un seul domaine pour différencier les requêtes mTLS et non mTLS.
* **Gestion des erreurs :** implémentez une gestion robuste des erreurs sur le client et le serveur de ressources afin de gérer adéquatement les cas où des certificats sont manquants, invalides ou ne correspondent pas.

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

* [Configurer Sender Constraining](/docs/fr-ca/secure/sender-constraining/configure-sender-constraining)