Passer au contenu principal
Pour utiliser les fonctionnalités de l’identité très réglementée (HRI), vous devez disposer d’un plan Enterprise avec le module complémentaire Identité très réglementée. Consultez Tarification Auth0 pour plus de détails.
La restriction de l’expéditeur (aussi connu sous le nom de liaison par jeton), favorise la liaison des jetons d’accès aux clés cryptographiques, telles qu’une clé privée. Elle garantit que seule l’application qui a demandé le jeton d’accès puisse l’utiliser pour accéder à la ressource associée, réduisant ainsi le risque de vol et les attaques par réinsertion. L’identité très réglementée offre des capacités de restriction de jeton via des Jetons d’accès liés par un certificat Mutual-TLS Client, également connus sous le nom de mTLS Token Binding (Liaison par jeton mTLS). Pour apprendre à configurer la restriction de l’expéditeur, lisez les articles suivants :

​
Comment les jetons d’accès sont liés à un certificat

Seuls les clients confidentiels prennent en charge la liaison de jeton pour le protocole mTLS.
Après avoir configuré votre application pour mTLS, votre application peut utiliser mTLS pour demander un jeton d’accès. Le serveur d’autorisation lie le certificat du client au jeton d’accès délivré en incluant la demande de confirmation (cnf) dans la charge utile du jeton d’accès. Le cnf contient un hachage représentant l’empreinte du certificat du client. L’exemple de code suivant représente la charge utile d’un jeton d’accès lié à un certificat : 
{
  "iss": "https://server.example.com",
  "sub": "ty.webb@example.com",
  "exp": 1493726400,
  "nbf": 1493722800,
  "cnf":{
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
  }
}

​
Vérification du jeton

Lorsque la liaison par jeton mTLS est activée, les jetons d’accès sont limités à l’application qui les a demandés (c’est-à-dire l’application « expéditrice »). Le serveur de ressources est chargé de vérifier que le certificat du client envoyé dans la demande a la même empreinte que celle incluse dans le jeton d’accès, ce qui est également connu sous le nom de vérification de la preuve de possession. Pour vérifier que l’application est autorisée à utiliser le jeton d’accès lié à un certificat, le serveur de ressources doit générer l’empreinte du certificat client utilisé dans la demande et la comparer à l’empreinte figurant dans la demande cnf. Pour plus d’informations sur le format de la demande cnf et sur la manière de générer l’empreinte d’un certificat, consultez la section du RFC 8705 sur la JWT Certificate Thumbprint Confirmation Method (Méthode de confirmation de l’empreinte du certificat ). Si l’application n’envoie pas le certificat du client dans la requête, ou si l’empreinte du certificat du client ne correspond pas, le serveur de ressources rejette la requête en utilisant un code d’état HTTP 401 et un code d’erreur invalid_token. Le tableau suivant indique si les jetons d’accès émis sont limités par l’expéditeur en fonction de la configuration mTLS pour l’application ( client ) et l’API (serveur de ressources OAuth). Le tableau couvre les scénarios suivants :
  • Le type d’ demandée : userinfo uniquement ou une audience personnalisée pouvant inclure userinfo.
  • Si la contrainte d’expéditeur est required (requise) par le client.
  • Si la contrainte d’expéditeur est configurée pour le serveur de ressources :
    • none : La contrainte d’expéditeur n’a pas été configurée pour le serveur de ressources.
    • allowed : La contrainte d’expéditeur a été configurée pour le serveur de ressources en définissant mTLS comme méthode de limitation de l’expéditeur.
    • required : La contrainte d’expéditeur est requise pour le serveur de ressources, ce qui signifie que les jetons d’accès doivent être soumis à une contrainte d’expéditeur pour une application. Exige une méthode de contrainte d’expéditeur.
  • Si l’application cliente a envoyé une assertion de preuve de possession dans la demande de jeton.
null
⌘I