Contrainte de l’expéditeur

Découvrez comment appliquer une contrainte d’expéditeur aux jetons dans Auth0.

La contrainte de l’expéditeur est un mécanisme de sécurité d’OAuth 2.0 et d’OpenID Connect (OIDC) qui lie cryptographiquement les jetons d’accès et les jetons d’actualisation à l’application qui les a demandés, ce qui empêche le vol et l’utilisation abusive des jetons.

Traditionnellement, les jetons d’accès OAuth 2.0 sont des jetons au porteur, ce qui signifie que quiconque « détient » ou possède le jeton peut l’utiliser. Si un jeton au porteur est volé ou divulgué, un attaquant peut le présenter à un serveur de ressources (API) et obtenir un accès non autorisé en se faisant passer pour l’application cliente ou l’utilisateur légitime.

La contrainte de l’expéditeur garantit que l’application cliente qui présente le jeton d’accès à un serveur de ressources en est bien la propriétaire légitime. Si l’application cliente n’est pas la propriétaire légitime du jeton d’accès, le serveur de ressources rejette la requête API.

​

Fonctionnement

Vous pouvez implémenter la contrainte de l’expéditeur de l’une des deux façons suivantes :

• Liaison de certificat Mutual-TLS (mTLS) dans la couche de transport :

  • Mécanisme : Lorsque l’application cliente demande un jeton d’accès au serveur d’autorisation Auth0, elle établit une connexion TLS mutuelle (mTLS), dans laquelle l’application cliente et le serveur présentent et vérifient tous deux leurs certificats X.509 respectifs.
  • Liaison : Le serveur d’autorisation Auth0 inclut une revendication de confirmation (cnf) contenant l’empreinte du certificat de l’application cliente directement dans le jeton d’accès émis.
  • Preuve de possession : Lorsque l’application cliente utilise le jeton d’accès lié à mTLS pour accéder à un serveur de ressources, elle doit de nouveau établir une connexion mTLS en utilisant le même certificat. Le serveur de ressources vérifie que le certificat présenté par l’application cliente correspond à celui lié au jeton d’accès. S’ils ne correspondent pas, le serveur de ressources rejette la requête.
  • Avantage : Même si un attaquant vole le jeton d’accès, il ne peut pas l’utiliser, car il ne possède pas la clé privée et le certificat correspondants requis pour établir la bonne connexion mTLS. La contrainte de l’expéditeur par mTLS est généralement utilisée par des applications confidentielles, comme les applications côté serveur, qui peuvent stocker et gérer en toute sécurité des certificats X.509 et leurs clés privées.

• Démonstration de preuve de possession (DPoP) dans la couche applicative :

  • Mécanisme : DPoP fonctionne dans la couche applicative et ne nécessite pas mTLS. L’application cliente génère plutôt sa propre paire de clés cryptographiques (clé privée/clé publique).
  • Liaison : Lorsqu’elle demande un jeton d’accès, l’application cliente crée un JSON Web Token (JWT) appelé DPoP Proof JWT. Ce JWT de preuve contient la clé publique de l’application cliente et est signé avec sa clé privée. L’application cliente envoie le DPoP Proof JWT avec la demande de jeton d’accès. Le serveur d’autorisation Auth0 valide le DPoP Proof JWT, puis lie le jeton d’accès émis à la clé publique.
  • Preuve de possession : Lorsque l’application cliente utilise le jeton d’accès lié à DPoP pour appeler un serveur de ressources, elle génère un autre DPoP Proof JWT signé avec sa clé privée pour cette requête d’API. L’application cliente envoie le DPoP Proof JWT dans un en-tête avec le jeton d’accès. Le serveur de ressources vérifie que le jeton d’accès est lié à la clé publique contenue dans le DPoP Proof JWT et que le DPoP Proof JWT lui-même a été signé avec la clé privée correspondante au moyen d’une revendication de confirmation (cnf).
  • Avantage : DPoP est plus flexible que mTLS, car il ne nécessite pas d’infrastructure à clé publique. Divers types d’applications peuvent l’utiliser, y compris des applications publiques comme les SPA et les applications mobiles.

​

mTLS vs. DPoP

Le tableau suivant résume les principales différences entre mTLS et DPoP pour les jetons avec contrainte d’expéditeur :

Attribut	mTLS	DPoP
Couche de fonctionnement	Couche de transport (TLS/SSL)	Couche applicative (en-têtes HTTP)
Cryptographie	Utilisation d’une infrastructure à clé publique (certificats X.509)	Utilisation de clés asymétriques (paires de clés générées par l’application)
Preuve de possession	Négociation TLS et validation du certificat	Preuve DPoP (JWT signé dans l’en-tête HTTP pour chaque requête)
Type d’application	Applications confidentielles	Applications publiques (SPA, applications mobiles)

Pour en savoir plus, consultez contrainte de l’expéditeur mTLS et démonstration de la preuve de possession (DPoP).

​

Pour commencer

Pour commencer avec la contrainte d’expéditeur dans Auth0, consultez les ressources suivantes :

À lire	Pour en savoir plus
Contrainte de l’expéditeur mTLS	Découvrez le fonctionnement de la contrainte de l’expéditeur mTLS dans Auth0, étape par étape.
Démonstration de la preuve de possession (DPoP)	Découvrez le fonctionnement de DPoP dans Auth0, étape par étape.
Configurer la contrainte d’expéditeur	Comment configurer la contrainte d’expéditeur pour une application et un serveur de ressources dans Auth0.

​

Pour en savoir plus

• Contrainte de l’expéditeur mTLS
• Démonstration de la preuve de possession (DPoP)
• Configurer la contrainte de l’expéditeur