Authentification avec mTLS

Les flux OAuth/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, 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 et DPoP 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.

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.

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 JWT. 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 pour Auth0 s'appuie sur des domaines personnalisés 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.

É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://<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 :

{
  ...
  "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 :

{
  ...
  "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 :

{
  ...
  "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.

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.

• Configurer l’authentification mTLS