mTLS sender constraining

Liez les jetons d’accès au certificat mTLS d’un client afin que seul le détenteur de ce certificat puisse utiliser le jeton pour envoyer une requête à un serveur de ressources.

Pour utiliser les fonctionnalités de Highly Regulated Identity, vous devez avoir un Enterprise Plan avec le module complémentaire Highly Regulated Identity. Consultez Auth0 Pricing pour en savoir plus.

La restriction de l’émetteur est un mécanisme de sécurité OAuth 2.0 qui lie de manière cryptographique les jetons d’accès et les jetons d’actualisation à l’application cliente qui les a demandés. Cela garantit que seule l’application cliente légitime qui a obtenu le jeton d’accès peut l’utiliser pour accéder à des ressources protégées, offrant ainsi une solide protection contre le vol de jetons et les attaques par rejeu.

Les jetons d’accès liés à un certificat client Mutual-TLS (mTLS), ou la mTLS sender constraining, assurent cette liaison au moyen du certificat TLS du client. Avec mTLS, le jeton d’accès du client est lié à son certificat client unique, ce qui rend ce jeton inutilisable par toute autre partie.

​

Prérequis

Pour mettre en place le mTLS sender constraining, vous devez :

• Disposer d’un plan Enterprise avec le module complémentaire Highly Regulated Identity pour votre tenant Auth0.
• Configurer sender constraining pour votre application cliente et votre serveur de ressources dans Auth0.
• Vous assurer que votre application cliente est un client confidentiel, puisque seuls les clients confidentiels prennent en charge le mTLS sender constraining.

​

Fonctionnement

Cette section explique comment obtenir et utiliser un jeton d’accès lié à mTLS.

​

Phase 1 : Demander un jeton d’accès associé à mTLS

​

Étape 1 : L’application cliente établit une connexion mTLS

• Avant de demander un jeton d’accès, votre application cliente amorce une négociation TLS avec le point de terminaison /token du serveur d’autorisation d’Auth0.
• Pendant cette négociation, l’application cliente présente son certificat client au serveur d’autorisation d’Auth0 dans le cadre du processus d’authentification TLS mutuelle.

​

Étape 2 : L’application cliente demande un jeton d’accès

• L’application cliente envoie une requête OAuth 2.0 standard pour obtenir un jeton, par exemple en utilisant grant_type=client_credentials ou authorization_code, au point de terminaison /token du serveur d’autorisation Auth0.
• La requête de jeton n’inclut aucun en-tête DPoP particulier ni aucune preuve JWTs supplémentaire pour mTLS. La preuve de possession provient directement de la connexion mTLS.

​

Étape 3 : Auth0 Authorization Server traite la requête et associe le jeton

Lorsque Auth0 Authorization Server reçoit la requête de jeton via une connexion mTLS et que le certificat client est validé avec succès :

1. Extrait le certificat : Auth0 Authorization Server extrait le certificat client utilisé lors de l’échange mTLS.

2. Calcule l’empreinte : Auth0 Authorization Server calcule un hachage unique (empreinte) du certificat client.

3. Associe le jeton : Auth0 Authorization Server associe l’empreinte de ce certificat client au jeton d’accès émis en incluant une revendication de confirmation (cnf) dans la charge utile du jeton d’accès.

   • La revendication cnf contient le paramètre x5t#S256, soit l’empreinte SHA-256 du certificat client encodée en Base64url.

4. Définit token_type** :** Auth0 Authorization Server définit token_type sur DPoP. Cela diffère des jetons Bearer traditionnels et indique que le jeton est lié à une clé précise.

5. Émet le jeton : Auth0 Authorization Server émet le jeton d’accès mTLS à contrainte d’émetteur à votre application cliente.

L’exemple de code suivant présente une charge utile de jeton d’accès lié à un certificat mTLS :

{
  "iss": "https://server.example.com",
  "sub": "[e-mail]",
  "exp": 1493726400,
  "nbf": 1493722800,
  "cnf": {
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
  }
}

Dans l’exemple de jeton d’accès lié à un certificat mTLS, x5t#S256 indique que le jeton d’accès est associé à un certificat client mTLS dont l’empreinte SHA-256 est bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2.

​

Phase 2 : Effectuer une requête à une API avec un jeton d’accès associé à mTLS

​

Étape 4 : L’application cliente appelle l’API

• Lorsque votre application cliente doit appeler une API qui applique la contrainte d’émetteur mTLS, elle doit établir une nouvelle connexion mTLS avec le serveur de ressources.
• Lors de cette négociation mTLS, l’application cliente présente de nouveau le même certificat client que celui utilisé pour obtenir le jeton d’accès.
• L’application cliente inclut ensuite le jeton d’accès lié à mTLS dans l’en-tête Authorization de la requête d’API en utilisant le schéma d’authentification DPoP :

Authorization: DPoP {your_mtls_bound_access_token}

Bien que la RFC 8705 autorise un schéma Bearer avec des jetons liés à mTLS, Auth0 recommande d’utiliser DPoP pour faire respecter l’utilisation de jetons d’accès liés à mTLS. Cela indique explicitement au serveur de ressources qu’il doit s’attendre à un jeton lié cryptographiquement.

​

Étape 5 : Le serveur de ressources vérifie le jeton et le certificat

Lorsque le serveur de ressources reçoit la requête d’API via une connexion mTLS :

1. Demande le certificat client : Le serveur de ressources récupère le certificat client à partir de la connexion mTLS établie.

2. Extrait le jeton et la revendication cnf : Le serveur de ressources extrait le jeton d’accès de l’en-tête Authorization et décode sa charge utile pour trouver la revendication cnf (confirmation), plus précisément la valeur x5t#S256 (l’empreinte du certificat associé).

3. Calcule l’empreinte du certificat actuel : Le serveur de ressources calcule l’empreinte SHA-256 du certificat client reçu dans la connexion mTLS en cours.

4. Compare les empreintes (vérification de la preuve de possession) : Le serveur de ressources compare l’empreinte nouvellement calculée à l’empreinte x5t#S256 de la revendication cnf du jeton d’accès.

5. Autorise ou rejette la requête :

   • Si les empreintes correspondent et que les autres validations du jeton, comme l’expiration, l’audience et l’émetteur, sont concluantes, la requête est autorisée.
   • Si le certificat client n’a pas été envoyé, ou si son empreinte ne correspond pas à celle de la revendication cnf, le serveur de ressources rejette la requête avec un code d’état HTTP 401 Unauthorized et un code d’erreur invalid_token.

Pour comprendre comment l’empreinte est calculée et le format de la revendication cnf, consultez la RFC 8705 : Mutual-TLS Client Certificate-Bound Access Tokens.

​

Considérations importantes

Lors de la mise en œuvre du mTLS sender constraining, tenez compte des éléments suivants :

• Clients confidentiels uniquement : le mTLS sender constraining est conçu et pris en charge uniquement pour les clients confidentiels, comme les services backend, qui peuvent gérer de façon sécuritaire des certificats clients et établir des connexions mTLS. Les clients publics, comme les SPA et les applications mobiles, devraient utiliser DPoP.
• Gestion des certificats : la sécurité de votre mise en œuvre de mTLS repose en grande partie sur vos pratiques de gestion des certificats, notamment la façon dont vous provisionnez, gérez et renouvelez les certificats clients.
• Exigences en matière d’infrastructure : la mise en œuvre de mTLS exige une infrastructure précise, y compris des proxys, des équilibreurs de charge et des API capables de terminer les connexions mTLS et de transmettre les informations du certificat client à l’application ou au serveur de ressources.
• Application par le serveur de ressources : lorsque vous activez le mTLS sender constraining pour une API dans Auth0, le serveur de ressources doit effectuer la vérification de l’empreinte numérique comme décrit à l’Étape 5.
• Stratégies de migration : si vous migrez progressivement des clients vers mTLS, envisagez d’exposer votre API sur deux domaines : un domaine non mTLS pour les clients existants et un domaine compatible avec mTLS pour les clients qui peuvent l’utiliser. Sinon, vous pourriez implémenter une logique sur un seul domaine pour différencier les requêtes mTLS et non mTLS.
• Gestion des erreurs : implémentez une gestion robuste des erreurs sur le client et le serveur de ressources afin de gérer adéquatement les cas où des certificats sont manquants, invalides ou ne correspondent pas.

​

Pour en savoir plus

• Configurer Sender Constraining