Authentifier une application avec mTLS

Découvrez comment authentifier une application à l’aide de 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 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 et DPoP, 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 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://<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 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 :

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

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

​

En savoir plus

• Configurer l’authentification mTLS