Qu'est-ce que mTLS pour OAuth 2.0 ?

mTLS en bref#

Dans une connexion HTTPS ordinaire, seul le serveur présente un certificat : le navigateur vérifie qu’il parle bien au bon site, mais le site ne sait rien du client. En TLS mutuel (mutual TLS, mTLS), le client présente lui aussi un certificat X.509, et prouve qu’il détient la clé privée correspondante pendant la négociation TLS.

RFC 8705 applique ce mécanisme à OAuth 2.0, pour deux usages distincts qui se combinent bien :

• l’authentification du client auprès du serveur d’autorisation, par son certificat plutôt que par un secret ;
• les jetons liés à un certificat (certificate-bound access tokens) : un jeton émis pour un client n’est accepté par l’API que si l’appel arrive sur une connexion TLS établie avec le même certificat.

Ce que mTLS résout#

Un client confidentiel s’authentifie le plus souvent avec un secret partagé. Ce secret circule à chaque appel, se retrouve dans des fichiers de configuration et doit être renouvelé à la main. S’il fuit, n’importe qui peut se faire passer pour le client.

Les jetons bearer ont la même faiblesse : celui qui détient le jeton peut l’utiliser. Un access token volé dans un journal, un cache ou une mémoire compromise reste valable jusqu’à son expiration.

mTLS remplace ces deux secrets transportables par une preuve de possession : la clé privée du client ne quitte jamais sa machine, et c’est elle qui est vérifiée à chaque connexion. Un jeton lié à un certificat, s’il est volé, est inutilisable sans la clé privée.

L’authentification du client#

RFC 8705 définit deux méthodes, que le client déclare comme token_endpoint_auth_method.

Pour tls_client_auth, le client enregistre exactement une valeur d’identification : le nom distinctif du sujet (tls_client_auth_subject_dn) ou un nom alternatif du sujet de type DNS, URI, adresse IP ou adresse e-mail. Le renouvellement du certificat ne demande alors aucune modification côté serveur, tant que le sujet reste le même.

Pour self_signed_tls_client_auth, le changement de certificat passe par la mise à jour du JWKS du client, idéalement publié à une adresse jwks_uri que le serveur relit.

Les jetons liés au certificat#

Quand un client s’authentifie par mTLS, le serveur d’autorisation peut inscrire dans le jeton l’empreinte du certificat utilisé. C’est la claim de confirmation cnf, avec le membre x5t#S256 : l’empreinte SHA-256 du certificat, encodée en base64url.

{
  "iss": "https://login.example.fr/tosiam/oauth2/clients",
  "sub": "releves-bancaires",
  "aud": "https://api.example.fr",
  "exp": 1790499600,
  "scope": "comptes:lecture",
  "cnf": {
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
  }
}

L’API lit l’empreinte dans le jeton JWT ou dans la réponse d’introspection, calcule celle du certificat présenté sur la connexion, et refuse l’appel si elles diffèrent. La comparaison elle-même ne coûte qu’un calcul de hachage.

La liaison ne dépend pas de la méthode d’authentification : un client public peut aussi présenter un certificat, seulement pour lier ses jetons. RFC 8705 définit par ailleurs deux métadonnées de découverte : tls_client_certificate_bound_access_tokens, pour annoncer la prise en charge des jetons liés, et mtls_endpoint_aliases, pour publier des adresses dédiées au TLS mutuel.

Bonnes pratiques#

• Terminez le TLS mutuel là où le certificat peut être vérifié. Si un proxy inverse s’en charge, il doit transmettre le certificat au serveur d’autorisation dans un en-tête qu’il est seul à pouvoir poser : supprimez cet en-tête de toutes les requêtes entrantes.
• Pour tls_client_auth, n’acceptez que les autorités de certification prévues pour vos clients, et non tout le magasin de confiance du système.
• Identifiez les clients par une valeur précise (un DN complet, un nom DNS exact) plutôt que par un motif trop large.
• Faites vérifier l’empreinte cnf par chaque API : un jeton lié n’apporte rien si l’API l’accepte comme un simple bearer.
• Préparez la rotation des certificats : même sujet pour tls_client_auth, publication anticipée du nouveau certificat dans le JWKS pour self_signed_tls_client_auth.

mTLS dans TOSIAM#

Les deux méthodes. Dans la fiche d’un client OAuth 2.0, le champ « Méthode d’authentification au point d’accès des jetons » propose tls_client_auth et self_signed_tls_client_auth, à côté des méthodes par secret et de private_key_jwt. Le document de découverte les annonce dans token_endpoint_auth_methods_supported. L’authentification s’applique partout où TOSIAM authentifie un client, par exemple aux endpoints de jeton, d’introspection et PAR.

tls_client_auth. La fiche du client contient les champs « Nom distinctif du sujet » et « Autres noms du sujet » de type DNS, URI, adresse électronique ou IP. Comme l’exige la norme, TOSIAM refuse une configuration qui en renseigne plusieurs catégories : il faut en remplir exactement une. Le DN est comparé sémantiquement, les noms DNS sans tenir compte de la casse (un motif simple comme *.example.fr est admis) et les adresses IP sous forme binaire. TOSIAM compare ainsi le sujet du certificat ; la chaîne de confiance est vérifiée lors de la négociation TLS, par le serveur d’applications ou le proxy qui termine la connexion.

self_signed_tls_client_auth. Le « Sélecteur de clé publique » du client doit désigner un JWKS saisi dans la fiche ou une adresse jwks_uri. TOSIAM accepte le certificat présenté s’il correspond à une clé du JWKS, par son empreinte x5t#S256 ou par la clé publique du certificat publié dans x5c.

Derrière un proxy inverse. TOSIAM lit d’abord le certificat sur la connexion TLS elle-même. À défaut, il le cherche dans l’en-tête HTTP désigné par le champ « Nom de l’en-tête HTTP du certificat mTLS » de la fiche du client. Le champ « Format de l’en-tête mTLS » accepte un PEM encodé pour URL (par défaut), un PEM brut, un DER en base64 ou l’en-tête X-Forwarded-Client-Cert produit par Envoy.

Les jetons liés. Quand un client s’est authentifié par l’une des deux méthodes mTLS, TOSIAM calcule l’empreinte x5t#S256 du certificat et l’inscrit dans la claim cnf de l’access token et du refresh token. Avec des jetons sans état, la claim figure dans le JWT ; avec des jetons stockés, l’endpoint d’introspection la renvoie. Un access token obtenu par rafraîchissement reprend la liaison du refresh token. Les jetons délivrés par le grant CIBA ne portent pas cette liaison.

Le document de découverte n’annonce pas encore tls_client_certificate_bound_access_tokens ni mtls_endpoint_aliases : les endpoints mTLS sont les endpoints habituels du royaume.

Pour aller plus loin#

• RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
• RFC 7800, la claim de confirmation cnf dans les JWT
• RFC 8446, TLS 1.3