> ## 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 authentifier une application à l’aide de mTLS.
# Authentifier une application 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 Secret client partagé comme mécanisme d’authentification de l’application.
* 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é la [RFC 8705](https://www.rfc-editor.org/rfc/rfc8705) sur l’authentification d’application Mutual-TLS (mTLS) pour répondre à ces problèmes. Avec l’authentification mTLS, le certificat client associé à une clé privée joue le même rôle qu’un Secret client dans un flux OAuth/OIDC pour vérifier l’identité de l’application. Si une application est déjà authentifiée à la couche réseau, il n’est pas nécessaire d’utiliser un Secret client à la couche applicative. De plus, les certificats d’application peuvent être utilisés avec plusieurs serveurs pour prouver l’identité d’une application à un serveur de ressources. Notez qu’il existe d’autres approches pour résoudre les problèmes ci-dessus, notamment [Private Key JWT](/fr-CA/docs/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 applications envoient un certificat mTLS au point de terminaison TLS sur le réseau de périphérie du client lors de l’établissement de la connexion TLS. Avant que le serveur d’autorisation traite la demande, il doit d’abord vérifier le certificat mTLS de l’application.
mTLS peut aussi, en option, servir à garantir qu’un jeton d’accès est utilisé uniquement par la partie prévue, ce qu’on appelle Sender Constraining ou Token Binding. Lorsque l’application appelle le point de terminaison `/oauth/token` sur le serveur d’autorisation au moyen 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 de l’application correspond à celui associé au jeton d’accès.
**Remarque** : l’authentification d’application mTLS et la liaison de jeton mTLS peuvent être utilisés indépendamment l’un de l’autre. L’authentification d’application mTLS peut être utilisée sans liaison de jeton mTLS, et la liaison de jeton mTLS peut être utilisée avec d’autres formes d’authentification de l’application, comme le Secret client ou Private Key JWT. Même si d’autres formes d’authentification de l’application sont utilisées, l’application envoie quand même le certificat client au serveur d’autorisation pour la liaison de jeton mTLS.
## mTLS chez Auth0
Le mTLS pour Auth0 s’appuie sur les [domaines personnalisés](/fr-CA/docs/customize/custom-domains) et utilise l’infrastructure mTLS existante du client pour assurer le provisionnement et la vérification des certificats.
Les appels authentifiés de l’application vers Auth0 qui nécessitent normalement un Secret client sont d’abord envoyés à la périphérie du client. C’est déjà le cas pour les domaines personnalisés qui utilisent des certificats gérés par le client. La périphérie du client effectue la négociation mTLS avec l’application et valide le certificat client. Une fois le certificat client vérifié, la requête est ensuite acheminée vers le domaine de périphérie du locataire sur 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 de l’application et à l’association du jeton d’accès, l’application 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 les détails de configuration du serveur d’autorisation, l’application 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 de l’application par 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 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 qui prennent en charge les alias de points de terminaison mTLS exposent une nouvelle propriété, `mtls_endpoint_aliases`, qui contient une liste des points de terminaison compatibles avec mTLS. Pour les applications qui prennent en charge mTLS, les points de terminaison listé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 appels mTLS est celui indiqué 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 répertorié dans `mtls_endpoint_aliases`, utilisez le même point de terminaison indiqué à l’extérieur de `mtls_endpoint_aliases`. Dans l’exemple ci-dessus, `pushed_authorization_request_endpoint` n’est pas répertorié dans `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 points 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’une application reçoit un jeton d’accès, elle peut accéder à des ressources protégées auprès d’un serveur de ressources. Si la liaison de jeton mTLS est activée, le serveur d’autorisation renvoie le document de découverte OIDC qui contient la propriété `tls_client_certificate_bound_access_tokens`.
Lorsque l’application appelle le serveur de ressources avec un jeton d’accès lié à mTLS, le serveur de ressources demande un certificat mTLS à l’application pendant la négociation TLS. Le serveur de ressources doit rejeter les requêtes dont le jeton d’accès ne correspond pas au certificat client, avec un code d’état HTTP 401 et un code d’erreur `invalid_token`. Pour en savoir plus, consultez [Configurer le serveur de ressources pour le sender constraining](/fr-CA/docs/secure/sender-constraining/configure-sender-constraining/configure-resource-server-for-sender-constraining).
## En savoir plus
* [Configurer l’authentification mTLS](/fr-CA/docs/get-started/applications/configure-mtls)