Passer au contenu principal
Pour utiliser les fonctionnalités Highly Regulated Identity, vous devez disposer d’un plan Enterprise avec l’add-on Highly Regulated Identity. Consultez la page Auth0 Pricing pour plus de détails.
Sender constraining 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 seul le client légitime qui a obtenu le peut l’utiliser pour accéder aux ressources protégées, offrant une protection efficace contre le vol de jetons et les attaques par rejeu. Les jetons d’accès liés au certificat client Mutual-TLS (mTLS), ou restriction de l’expéditeur mTLS, établissent cette liaison en tirant parti du certificat TLS du client. Avec mTLS, le jeton d’accès du client est lié à son certificat client unique, ce qui rend le jeton inutilisable par toute autre partie.

​
Conditions préalables

Pour mettre en œuvre la contrainte d’émetteur mTLS, vous devez :
  • Disposer d’un plan Enterprise avec le module complémentaire Highly Regulated Identity pour votre locataire Auth0.
  • Configurer la contrainte d’émetteur pour votre application cliente et le dans Auth0.
  • Veiller à ce que votre application cliente soit un , puisque seuls les clients confidentiels prennent en charge la contrainte d’émetteur mTLS.

​
Fonctionnement

Cette section décrit le processus permettant d’obtenir et d’utiliser un jeton d’accès lié à mTLS.

​
Phase 1: Request an mTLS-bound access token

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

  • Avant de demander un jeton d’accès, votre application cliente initie 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 (mTLS).

​
É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 en utilisant grant_type=client_credentials ou authorization_code, au point de terminaison /token du Serveur d’autorisation d’Auth0.
  • La requête de jeton n’inclut aucun en-tête DPoP spécial ni de de preuve supplémentaires pour mTLS. La preuve de possession est dérivée directement de la connexion mTLS.

​
Étape 3 : le Serveur d’autorisation Auth0 traite la requête et lie le jeton

Lorsque le Serveur d’autorisation Auth0 reçoit la requête 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é dans la poignée de main mTLS.
  2. Calcule l’empreinte : le Serveur d’autorisation Auth0 calcule un hachage unique (empreinte) du certificat client.
  3. Lie le jeton : le Serveur d’autorisation Auth0 lie 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, qui est 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é spécifique.
  5. Émet le jeton : le Serveur d’autorisation Auth0 émet le jeton d’accès mTLS restreint à l’expéditeur à votre application cliente.
L’exemple de code suivant illustre une charge utile de 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: Call an API with an mTLS-bound access token

​
Step 4: Client application calls API

  • When your client application needs to call an API that enforces mTLS sender constraining, it must establish a new mTLS connection with the resource server.
  • During this mTLS handshake, the client application presents the same client certificate that was used to obtain the access token again.
  • The client application then includes the mTLS-bound access token in the Authorization header of the API request using the DPoP authentication scheme:
Authorization: DPoP {your_mtls_bound_access_token}
While RFC 8705 allows for a Bearer scheme with mTLS-bound tokens, Auth0 recommends using DPoP to enforce mTLS-bound access tokens. This explicitly signals to the resource server to expect a cryptographically bound token.

​
Step 5: Resource server verifies token and certificate

When the resource server receives the API request over an mTLS connection:
  1. Requests client certificate: The resource server retrieves the client certificate from the established mTLS connection.
  2. Extracts token and cnf claim: The resource server extracts the access token from the Authorization header and decodes its payload to find the cnf (confirmation) claim, specifically the x5t#S256 value (the bound certificate’s thumbprint).
  3. Calculates current certificate thumbprint: The resource server calculates the SHA-256 thumbprint of the client certificate received in the current mTLS connection.
  4. Compares thumbprints (Proof-of-Possession verification): The resource server compares the newly calculated thumbprint with the x5t#S256 thumbprint from the access token’s cnf claim.
  5. Authorizes or rejects request:
    • If the thumbprints match and other token validations, such as the expiration, audience, and issuer, pass, the request is authorized.
    • If the client certificate was not sent, or its thumbprint does not match the one in the cnf claim, the resource server rejects the request with an HTTP 401 Unauthorized status code and an invalid_token error code.
To understand how the thumbprint is calculated and the format of the cnf claim, refer to RFC 8705: Mutual-TLS Client Certificate-Bound Access Tokens.

​
Considérations importantes

Lorsque vous mettez en œuvre la contrainte de l’émetteur mTLS, tenez compte des éléments suivants :
  • Clients confidentiels uniquement : la contrainte de l’émetteur mTLS est conçue pour et prise en charge uniquement par des clients confidentiels, comme des services backend, qui peuvent gérer de façon sécuritaire les certificats client et établir des connexions mTLS. comme les SPA et les applications mobiles doivent utiliser DPoP.
  • Gestion des certificats : la sécurité de votre implémentation mTLS dépend fortement de vos pratiques de gestion des certificats, notamment la façon dont vous provisionnez, gérez et renouvelez les certificats client.
  • Exigences d’infrastructure : la mise en œuvre de mTLS nécessite une infrastructure spécifique, y compris des proxys, des équilibreurs de charge et des API capables de terminer les connexions mTLS et de transmettre les informations relatives au certificat client à l’application ou au serveur de ressources.
  • Application par le serveur de ressources : lorsque vous activez la contrainte de l’émetteur mTLS 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 l’utilisation de mTLS, envisagez d’exposer votre API sur deux domaines : un domaine sans mTLS pour les clients existants et un domaine avec mTLS activé pour les clients compatibles 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 : implémentez une gestion robuste des erreurs sur le client et le serveur de ressources afin de gérer correctement les cas où les certificats sont manquants, non valides ou ne correspondent pas.

​
En savoir plus