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

# Authentification avec mTLS

> Découvrez comment authentifier un client en utilisant mTLS.

## mTLS dans OAuth/OIDC

Les flux <Tooltip href="/docs/fr-ca/glossary?term=oath2" tip="OAuth 2.0
Cadre d’applications d’autorisation qui définit les protocoles d’autorisation et les flux de production." cta="Voir le glossaire">OAuth</Tooltip>/OIDC par défaut ne garantissent pas toujours une sécurité optimale en raison des problèmes suivants :

* L’utilisation d’un secret client partagé comme méthode d’authentification client.
* La possibilité qu’un jeton d’accès soit utilisé par des parties non autorisées.

En 2020, Internet Engineering Task Force (IETF) a publié [RFC 8705](https://www.rfc-editor.org/rfc/rfc8705), qui introduit l’authentification client par Mutual-TLS (mTLS) pour remédier à ces problèmes. Avec l’authentification mTLS, le certificat client, accompagné d’une clé privée, remplace le secret client dans un flux OAuth/OIDC pour valider l’identité du client. Si un client est déjà authentifié au niveau de la couche réseau, il n’est pas nécessaire de recourir à un secret client au niveau de la couche application. De surcroît, les certificats clients peuvent être utilisés avec plusieurs serveurs pour attester de l’identité d’un client auprès d’un serveur de ressources. Veuillez noter qu’il existe d’autres approches pour résoudre les problèmes ci-dessus, à savoir [Clé privée JWT](/docs/fr-ca/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt) et [DPoP](https://datatracker.ietf.org/doc/html/rfc9449) respectivement.

Pour sécuriser un flux OAuth avec mTLS, les clients transmettent un certificat mTLS au point de terminaison TLS sur le réseau périphérique lors de l’établissement de la connexion TLS. Avant que le serveur d’autorisation ne puisse traiter la requête, il doit d’abord valider le certificat mTLS du client.

<Frame>
  <img src="https://mintlify.s3.us-west-1.amazonaws.com/auth0-actions-triggers-prototype/docs/images/fr-ca/cdy7uua7fh8z/4SlprP2uTYMCoLIPLsOl4v/414ad59c922ae2d23a3b4e6808d2ce20/HRI_diagrams_-_mtls_diagram_1__2_.png" alt="null" />
</Frame>

En outre, mTLS peut également être utilisé pour garantir qu’un jeton d’accès ne soit exploité que par la partie désignée, un mécanisme appelé contrainte d’expéditeur ou liaison de jeton. Lorsque le client appelle le point de terminaison `/oauth/token` sur le serveur d’autorisation au moyen d’une connexion mTLS, le jeton d’accès généré contient des informations permettant au serveur de ressources de vérifier que le certificat TLS du client correspond à celui associé au jeton d’accès.

<Frame>
  <img src="https://mintlify.s3.us-west-1.amazonaws.com/auth0-actions-triggers-prototype/docs/images/fr-ca/cdy7uua7fh8z/7qocbfqySAnu85ph6WVSGU/343f49bd85195745a655ebc4adff448e/HRI_diagrams_-_mtls_diagram_2__1_.png" alt="null" />
</Frame>

**Remarque** : l’authentification client mTLS et la liaison de jeton mTLS peuvent être utilisées de manière indépendante. L’authentification client mTLS peut être mise en œuvre sans liaison de jeton mTLS, et la liaison de jeton mTLS peut être combinée avec d’autres méthodes d’authentification client, telles que le secret client ou la clé privée <Tooltip href="/docs/fr-ca/glossary?term=json-web-token" tip="Jeton Web JSON (JWT)
Format standard de jeton d’ID (et souvent de jeton d’accès) utilisé pour représenter en toute sécurité des demandes entre deux parties." cta="Voir le glossaire">JWT</Tooltip>. Même lorsque d’autres méthodes d’authentification client sont employées, le client envoie toujours son certificat au serveur d’autorisation pour assurer la liaison de jeton mTLS.

## mTLS à Auth0

mTLS pour Auth0 s'appuie sur des [domaines personnalisés](/docs/fr-ca/customize/custom-domains) et exploite l'infrastructure mTLS existante du client pour effectuer le provisionnement et la vérification des certificats.

Les appels client authentifiés à Auth0, qui nécessitent habituellement un secret client, sont d’abord redirigés vers le périphérique client. Cela est déjà en place pour les domaines personnalisés utilisant des certificats gérés par le client. Le client Edge effectue la négociation mTLS avec le client et valide son certificat. Une fois le certificat client validé, la requête est ensuite transmise au domaine périphérique du locataire sur Auth0, en incluant le certificat client validé dans un en-tête HTTP avec la clé correcte `cname-api-key`, conformément à la fonctionnalité des domaines personnalisés.

<Frame>
  <img src="https://mintlify.s3.us-west-1.amazonaws.com/auth0-actions-triggers-prototype/docs/images/fr-ca/cdy7uua7fh8z/7p3tqUtBeMAp4fBbbemhOh/bf2257f19da57f9f00a0506ed89c9659/HRI_diagrams_-_mtls_diagram_3__1_.png" alt="null" />
</Frame>

## Fait un appel au serveur d’autorisation

Étant donné que mTLS assure à la fois l’authentification du client et la liaison du jeton d’accès, il est essentiel que le client sache si ces fonctionnalités sont activées sur le serveur d’autorisation. De plus, les points de terminaison mTLS et non mTLS d’un serveur d’autorisation peuvent être exposés sur des domaines distincts.

Pour obtenir les détails de configuration du serveur d’autorisation, le client envoie une requête GET au point de terminaison [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html) : `https://<custom-domain>/.well-known/openid-configuration`

Une réponse réussie retourne le document de découverte OIDC ou un objet JSON détaillant les propriétés et points de terminaison du serveur d’autorisation, y compris ceux associés à mTLS.

Si l’authentification client mTLS est activée, le document de découverte OIDC inclut le `token_endpoint_auth_methods_supported` property, which contains either `tls_client_auth` ou `self_signed_tls_client_auth` :

```json lines theme={null}
{
  ...
  "token_endpoint_auth_methods_supported": ["tls_client_auth"]
  ...
}
```

Si la liaison de jeton mTLS est activée, le document de découverte OIDC définit la propriété `tls_client_certificate_bound_access_tokens` sur `true` :

```json lines theme={null}
{
  ...
  "tls_client_certificate_bound_access_tokens": true
  ...
}
```

Les environnements prenant en charge les alias de point de terminaison mTLS exposent une nouvelle propriété, `mtls_endpoint_aliases`, qui contient une liste de points de terminaison compatibles avec mTLS. Pour les clients qui prennent en charge mTLS, les points de terminaison répertoriés sous `mtls_endpoint_aliases` ont priorité sur les mêmes points de terminaison exposés à l’extérieur de `mtls_endpoint_aliases`.

Dans l’exemple de code suivant, la propriété du `token_endpoint` est exposée deux fois. Le point de terminaison à utiliser pour les appels mTLS est répertorié sous `mtls_endpoint_aliases`, ou `https://mtls.auth.bank.com/oauth/token` :

```json lines theme={null}
{
  ...
  "mtls_endpoint_aliases": {
"token_endpoint": "https://mtls.auth.bank.com/oauth/token"
  },
  "token_endpoint": "https://auth.bank.com/oauth/token",
  "pushed_authorization_request_endpoint": "https://auth.bank.com/oauth/par",
  ...
}
```

Si un point de terminaison n’est pas répertorié sous `mtls_endpoint_aliases`, utilisez le même point de terminaison répertorié en dehors de `mtls_endpoint_aliases`. Dans l’exemple ci-dessus, `pushed_authorization_request_endpoint` n’est pas répertorié sous `mtls_endpoint_aliases`. Par conséquent, utilisez le `pushed_authorization_request_endpoint` exposé à l’extérieur de `mtls_endpoint_aliases`, ou `https://auth.bank.com/oauth/par`.

Pour plus d’informations, veuillez consulter la section RFC 8705  [sur les alias de points de terminaison](https://www.rfc-editor.org/rfc/rfc8705#name-metadata-for-mutual-tls-end).

## Appel au serveur d’autorisation

Une fois qu’un client a reçu un jeton d’accès, il peut accéder aux ressources protégées sur un serveur de ressources. Si la liaison de jeton mTLS est activée, le serveur d’autorisation retourne le document de découverte OIDC, qui inclut la propriété `tls_client_certificate_bound_access_tokens`.

Lorsque le client appelle le serveur de ressources avec un jeton d’accès lié à mTLS, le serveur de ressources demande un certificat mTLS au client pendant l’établissement de liaison TLS. Le serveur de ressources doit rejeter les demandes avec un jeton d’accès qui ne correspond pas à ce certificat client avec un code d’état HTTP 401 et un code d’erreur `invalid_token`. Pour en savoir plus, veuillez consulter [Configurer le serveur de ressources pour la contrainte de l’expéditeur](/docs/fr-ca/secure/sender-constraining/configure-sender-constraining/configure-resource-server-for-sender-constraining).

## En savoir plus

* [Configurer l’authentification mTLS](/docs/fr-ca/get-started/applications/configure-mtls)