> ## 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 le protocole TLS mutuel (mTLS) sécurise les flux OAuth en remplaçant les secrets client partagés par des certificats X.509 et, facultativement, en liant les jetons d’accès au client.
# S’authentifier avec mTLS
## mTLS dans OAuth/OIDC
Les flux OAuth/OIDC par défaut ne sont pas toujours sécurisés pour les raisons suivantes :
* L’utilisation d’un Client Secret partagé comme mécanisme d’authentification du client.
* La possibilité qu’un jeton d’accès soit utilisé par des tiers non autorisés.
En 2020, l’Internet Engineering Task Force (IETF) a publié [RFC 8705](https://www.rfc-editor.org/rfc/rfc8705), sur l’authentification client Mutual-TLS (mTLS), pour remédier à ces problèmes. Avec l’authentification mTLS, le certificat client assorti d’une clé privée joue le même rôle qu’un Client Secret dans un flux OAuth/OIDC pour vérifier l’identité du client. Si un client est déjà authentifié à la couche réseau, il n’est pas nécessaire d’utiliser un Client Secret à la couche applicative. De plus, les certificats clients peuvent être utilisés avec plusieurs serveurs pour prouver l’identité d’un client auprès d’un serveur de ressources. Notez qu’il existe d’autres approches pour résoudre les problèmes ci-dessus, à savoir [Private Key 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 envoient un certificat mTLS au point de terminaison TLS du réseau de périphérie du client au moment où la connexion TLS est établie. Avant que le serveur d’autorisation traite la requête, il doit d’abord vérifier le certificat mTLS du client.
Facultativement, mTLS peut aussi être utilisé pour veiller à ce qu’un jeton d’accès soit utilisé uniquement par la partie prévue, ce qu’on appelle Sender Constraining ou Token Binding. Lorsque le client appelle le point de terminaison `/oauth/token` sur le serveur d’autorisation à l’aide d’une connexion mTLS, le jeton d’accès obtenu contient des informations que le serveur de ressources utilise pour vérifier que le certificat TLS du client correspond à celui associé au jeton d’accès.
**Remarque** : l’authentification client mTLS et mTLS Token Binding peuvent être utilisées indépendamment l’une de l’autre. L’authentification client mTLS peut être utilisée sans mTLS Token Binding, et mTLS Token Binding peut être utilisé avec d’autres formes d’authentification du client, comme Client Secret ou Private Key JWT. Même si d’autres formes d’authentification du client sont utilisées, le client envoie tout de même le certificat client au serveur d’autorisation pour mTLS Token Binding.
## mTLS chez Auth0
Le mTLS pour Auth0 s’appuie sur les [domaines personnalisés](/docs/fr-ca/customize/custom-domains) et exploite l’infrastructure mTLS existante du client pour assurer le provisionnement et la vérification des certificats.
Les appels authentifiés du client vers Auth0 qui nécessitent normalement un Secret client sont d’abord envoyés au Customer Edge. C’est déjà le cas pour les domaines personnalisés qui utilisent des certificats gérés par le client. Le Customer Edge effectue la négociation mTLS avec le client et valide le certificat client. Une fois le certificat client vérifié, la requête est ensuite transmise au domaine de périphérie du tenant dans Auth0, en incluant le certificat client validé dans un en-tête HTTP ainsi que la valeur `cname-api-key` appropriée, conformément à la fonctionnalité des domaines personnalisés.
## Appeler le serveur d’autorisation
Comme mTLS sert à la fois à l’authentification du client et à la liaison du jeton d’accès, le client doit savoir 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 différents.
Pour obtenir le détail 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:///.well-known/openid-configuration`
Si la requête réussit, elle renvoie le document de découverte OIDC, c’est-à-dire un objet JSON qui répertorie les propriétés et les points de terminaison du serveur d’autorisation, y compris ceux liés à mTLS.
Si l’authentification du client mTLS est activée, le document de découverte OIDC inclut la propriété `token_endpoint_auth_methods_supported`, qui contient soit `tls_client_auth`, soit `self_signed_tls_client_auth` :
```json lines theme={null}
{
...
"token_endpoint_auth_methods_supported": ["tls_client_auth"]
...
}
```
Si mTLS Token Binding est activé, le document de découverte OIDC définit la propriété `tls_client_certificate_bound_access_tokens` à `true:`
```json lines theme={null}
{
...
"tls_client_certificate_bound_access_tokens": true
...
}
```
Les environnements qui prennent en charge les alias de points 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` prévalent sur les mêmes points de terminaison exposés en dehors de `mtls_endpoint_aliases`.
Dans l’exemple de code suivant, la propriété `token_endpoint` est exposée deux fois. Le point de terminaison à utiliser pour les requêtes mTLS figure sous `mtls_endpoint_aliases`, soit `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 indiqué sous `mtls_endpoint_aliases`, utilisez le même point de terminaison que celui indiqué à l’extérieur de `mtls_endpoint_aliases`. Dans l’exemple ci-dessus, `pushed_authorization_request_endpoint` n’est pas indiqué sous `mtls_endpoint_aliases`. Par conséquent, utilisez le `pushed_authorization_request_endpoint` exposé à l’extérieur de `mtls_endpoint_aliases`, soit `https://auth.bank.com/oauth/par`.
Pour en savoir plus, consultez la [section sur les alias de point de terminaison](https://www.rfc-editor.org/rfc/rfc8705#name-metadata-for-mutual-tls-end) de la RFC 8705.
## Appeler le serveur de ressources
Une fois qu’un client reçoit un jeton d’accès, il peut accéder aux ressources protégées sur le serveur de ressources. Si mTLS Token Binding est activé, le serveur d’autorisation renvoie le document de découverte OIDC qui contient la propriété `tls_client_certificate_bound_access_tokens`.
Lorsque le client envoie une requête au serveur de ressources avec un jeton d’accès lié à mTLS, le serveur de ressources demande au client de présenter un certificat client lors de la négociation TLS. Le serveur de ressources doit rejeter, avec un code d’état HTTP 401 et un code d’erreur `invalid_token`, toute requête accompagnée d’un jeton d’accès qui ne correspond pas à ce certificat client. Pour en savoir plus, consultez [Configurer le serveur de ressources pour Sender Constraining](/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)