> ## 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 utiliser la contrainte de l’expéditeur mTLS pour les jetons dans Auth0.

# Contrainte de l’expéditeur mTLS

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Pour utiliser les fonctionnalités Highly Regulated Identity, vous devez disposer d’un plan Enterprise avec l’option Highly Regulated Identity. Consultez [Auth0 Pricing](https://auth0.com/pricing/) pour en savoir plus.
</Callout>

La [contrainte de l’expéditeur](/fr-CA/docs/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="Voir le glossaire" href="/fr-CA/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> qui lie de façon 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 reconnecter." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=refresh+tokens">jetons d’actualisation</Tooltip> à l’application cliente qui les a demandés. Cela garantit que seule l’application légitime qui a obtenu le <Tooltip tip="Access Token : jeton d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisé pour accéder à une API." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=access+token">jeton d’accès</Tooltip> peut l’utiliser pour accéder à des ressources protégées, offrant une protection robuste contre le vol de jetons et les attaques par rejeu.

La contrainte de l’expéditeur mTLS, soit les jetons d’accès liés au certificat client Mutual TLS (mTLS), permet d’établir cette liaison en s’appuyant sur le certificat TLS de l’application. Avec mTLS, le jeton d’accès de l’application est lié à son certificat client unique, ce qui le rend inutilisable par toute autre partie.

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

Pour implémenter la contrainte de l’expéditeur mTLS, vous devez :

* Disposer d’un plan Enterprise avec l’option Highly Regulated Identity pour votre locataire Auth0.
* [Configurer la contrainte de l’expéditeur](/fr-CA/docs/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 demandes d’accès à des ressources protégées et y répondent." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=resource+server">serveur de ressources</Tooltip> dans Auth0.
* Vous assurer que votre application cliente est un <Tooltip tip="Client confidentiel : client (application) capable de stocker des identifiants de façon sécurisée à l’aide d’un serveur backend de confiance. Par exemple, une application Web avec un backend sécurisé ou une application machine à machine (M2M)." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=confidential+client">client confidentiel</Tooltip>, car seuls les clients confidentiels prennent en charge la contrainte de l’expéditeur mTLS.

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

Cette section présente le processus d’obtention et d’utilisation d’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 lié à 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 entame une négociation TLS avec le point de terminaison `/token` du <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 auxquelles un utilisateur a accès." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Authorization+Server">serveur d’autorisation</Tooltip> Auth0.
* Pendant cette négociation, l’application cliente présente son certificat client au serveur d’autorisation 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 de jeton OAuth 2.0 standard, par exemple avec `grant_type=client_credentials` ou `authorization_code`, au point de terminaison `/token` du serveur d’autorisation Auth0.
* La requête de jeton ne comprend aucun en-tête DPoP particulier ni aucun <Tooltip tip="JSON Web Token (JWT) : format standard des ID Token (et souvent des Jetons d’accès) utilisé pour représenter de façon sécurisée des revendications entre deux parties." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=JWTs">JWTs</Tooltip> supplémentaire comme preuve pour le mTLS. La preuve de possession découle directement de la connexion mTLS.

<div id="step-3-auth0-authorization-server-processes-request-and-binds-token">
  ### Étape 3 : le serveur d’autorisation Auth0 traite la demande et associe le jeton
</div>

Lorsque le serveur d’autorisation Auth0 reçoit la demande de jeton sur une connexion mTLS et que le certificat client est validé avec succès :

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

   * La revendication `cnf` contient le paramètre `x5t#S256`, qui correspond à l’empreinte SHA-256 du certificat client encodée en Base64url.
4. **Définit** `token_type`\*\* :\*\* Le serveur d’autorisation Auth0 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 :** Le serveur d’autorisation Auth0 émet le jeton d’accès mTLS à contrainte d’expéditeur à votre application cliente.

L’exemple de code suivant montre un exemple de payload d’un 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 lié à 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 : Appeler une API avec un jeton d’accès lié à mTLS
</div>

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

* Lorsque votre application cliente doit appeler une API qui applique la contrainte de l’expéditeur 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 associé à mTLS dans l’en-tête Authorization de la requête API à l’aide du 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 d’accès liés à mTLS, Auth0 recommande d’utiliser DPoP pour imposer des jetons d’accès liés à mTLS. Cela indique explicitement au serveur de ressources qu’il doit s’attendre à un jeton lié de façon cryptographique.
</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 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 son payload pour trouver la revendication `cnf` (confirmation), plus précisément la valeur `x5t#S256` (l’empreinte du certificat lié).
3. **Calcule l’empreinte actuelle du certificat :** 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, réussissent, 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 de la contrainte de l’expéditeur mTLS, tenez compte des éléments suivants :

* **Clients confidentiels uniquement :** La contrainte de l’expéditeur mTLS est conçue et prise en charge uniquement pour les clients confidentiels, comme les services backend, qui peuvent gérer de façon sécurisée des certificats clients et établir des connexions mTLS. <Tooltip tip="Client public : client (application) qui ne peut pas conserver des identifiants de façon sécurisée. Les exemples comprennent 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="/fr-CA/docs/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 sur la façon dont vous provisionnez, gérez et faites la rotation des certificats clients.
* **Exigences d’infrastructure :** La mise en œuvre de mTLS nécessite une infrastructure précise, y compris des serveurs proxy, des répartiteurs de charge et des API capables de terminer les connexions mTLS et de transmettre les renseignements sur le certificat client à l’application ou au serveur de ressources.
* **Contrôle par le serveur de ressources :** Lorsque vous activez la contrainte de l’expéditeur mTLS pour une API dans Auth0, le serveur de ressources doit effectuer la vérification de l’empreinte, 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 avec mTLS activé pour les clients compatibles avec mTLS. Vous pouvez aussi implémenter une logique sur un seul domaine pour distinguer les requêtes mTLS des requêtes non mTLS.
* **Gestion des erreurs :** Mettez en œuvre une gestion robuste des erreurs côté client et côté serveur de ressources afin de gérer correctement les cas où des certificats sont absents, invalides ou ne correspondent pas.

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

* [Configurer la contrainte de l’expéditeur](/fr-CA/docs/secure/sender-constraining/configure-sender-constraining)