Skip to main content

​
mTLS dans OAuth/OIDC

Les flux /OIDC par défaut ne sont pas toujours sécurisés pour les raisons suivantes :
  • L’utilisation d’un partagé comme mécanisme d’authentification du client.
  • La possibilité qu’un soit utilisé par des tiers non autorisés.
En 2020, l’Internet Engineering Task Force (IETF) a publié RFC 8705, 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 . Notez qu’il existe d’autres approches pour résoudre les problèmes ci-dessus, à savoir Private Key JWT et DPoP, 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 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 . 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 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 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://<custom-domain>/.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 :
Si mTLS Token Binding est activé, le document de découverte OIDC définit la propriété 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 :
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 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.

​
En savoir plus