Passer au contenu principal
Pour utiliser les fonctionnalités Highly Regulated Identity, vous devez disposer d’un plan Enterprise avec l’option Highly Regulated Identity. Consultez Auth0 Pricing pour en savoir plus.
La contrainte de l’expéditeur est un mécanisme de sécurité qui lie de façon cryptographique les jetons d’accès et les à l’application cliente qui les a demandés. Cela garantit que seule l’application légitime qui a obtenu le peut l’utiliser pour accéder à des ressources protégées, offrant une protection robuste contre le vol de jetons et les attaques par rejeu. La contrainte de l’expéditeur mTLS, soit les jetons d’accès liés au certificat client Mutual TLS (mTLS), permet d’établir cette liaison en s’appuyant sur le certificat TLS de l’application. Avec mTLS, le jeton d’accès de l’application est lié à son certificat client unique, ce qui le rend inutilisable par toute autre partie.

​
Prérequis

Pour implémenter la contrainte de l’expéditeur mTLS, vous devez :
  • Disposer d’un plan Enterprise avec l’option Highly Regulated Identity pour votre locataire Auth0.
  • Configurer la contrainte de l’expéditeur pour votre application cliente et votre dans Auth0.
  • Vous assurer que votre application cliente est un , car seuls les clients confidentiels prennent en charge la contrainte de l’expéditeur mTLS.

​
Fonctionnement

Cette section présente le processus d’obtention et d’utilisation d’un jeton d’accès lié à mTLS.

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

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

  • Avant de demander un jeton d’accès, votre application cliente entame une négociation TLS avec le point de terminaison /token du Auth0.
  • Pendant cette négociation, l’application cliente présente son certificat client au serveur d’autorisation 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 de jeton OAuth 2.0 standard, par exemple avec grant_type=client_credentials ou authorization_code, au point de terminaison /token du serveur d’autorisation Auth0.
  • La requête de jeton ne comprend aucun en-tête DPoP particulier ni aucun supplémentaire comme preuve pour le mTLS. La preuve de possession découle directement de la connexion mTLS.

​
Étape 3 : le serveur d’autorisation Auth0 traite la demande et associe le jeton

Lorsque le serveur d’autorisation Auth0 reçoit la demande de jeton sur une connexion mTLS et que le certificat client est validé avec succès :
  1. Extrait le certificat : Le serveur d’autorisation Auth0 extrait le certificat client utilisé lors de l’établissement de la connexion mTLS.
  2. Calcule l’empreinte : Le serveur d’autorisation Auth0 calcule un hachage unique (empreinte) du certificat client.
  3. Associe le jeton : Le serveur d’autorisation Auth0 associe l’empreinte de ce certificat client au jeton d’accès émis en incluant une revendication de confirmation (cnf) dans le payload du jeton d’accès.
    • La revendication cnf contient le paramètre x5t#S256, qui correspond à l’empreinte SHA-256 du certificat client encodée en Base64url.
  4. Définit token_type** :** Le serveur d’autorisation Auth0 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 : Le serveur d’autorisation Auth0 émet le jeton d’accès mTLS à contrainte d’expéditeur à votre application cliente.
L’exemple de code suivant montre un exemple de payload d’un jeton d’accès lié à un certificat mTLS : 
{
  "iss": "https://server.example.com",
  "sub": "ty.webb@example.com",
  "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 lié à un certificat client mTLS dont l’empreinte SHA-256 est bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2.

​
Phase 2 : Appeler une API avec un jeton d’accès lié à mTLS

​
Étape 4 : L’application cliente appelle une API

  • Lorsque votre application cliente doit appeler une API qui applique la contrainte de l’expéditeur 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 associé à mTLS dans l’en-tête Authorization de la requête API à l’aide du 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 d’accès liés à mTLS, Auth0 recommande d’utiliser DPoP pour imposer des jetons d’accès liés à mTLS. Cela indique explicitement au serveur de ressources qu’il doit s’attendre à un jeton lié de façon cryptographique.

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

Lorsque le serveur de ressources reçoit la requête 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 son payload pour trouver la revendication cnf (confirmation), plus précisément la valeur x5t#S256 (l’empreinte du certificat lié).
  3. Calcule l’empreinte actuelle du certificat : 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, réussissent, 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 de la contrainte de l’expéditeur mTLS, tenez compte des éléments suivants :
  • Clients confidentiels uniquement : La contrainte de l’expéditeur mTLS est conçue et prise en charge uniquement pour les clients confidentiels, comme les services backend, qui peuvent gérer de façon sécurisée des certificats clients et établir des connexions mTLS. 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 sur la façon dont vous provisionnez, gérez et faites la rotation des certificats clients.
  • Exigences d’infrastructure : La mise en œuvre de mTLS nécessite une infrastructure précise, y compris des serveurs proxy, des répartiteurs de charge et des API capables de terminer les connexions mTLS et de transmettre les renseignements sur le certificat client à l’application ou au serveur de ressources.
  • Contrôle par le serveur de ressources : Lorsque vous activez la contrainte de l’expéditeur mTLS pour une API dans Auth0, le serveur de ressources doit effectuer la vérification de l’empreinte, 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 avec mTLS activé pour les clients compatibles avec mTLS. Vous pouvez aussi implémenter une logique sur un seul domaine pour distinguer les requêtes mTLS des requêtes non mTLS.
  • Gestion des erreurs : Mettez en œuvre une gestion robuste des erreurs côté client et côté serveur de ressources afin de gérer correctement les cas où des certificats sont absents, invalides ou ne correspondent pas.

​
En savoir plus