L’application d’une contrainte d’émetteur aux jetons à l’aide de Demonstrating Proof-of-Possession (DPoP) est actuellement en accès anticipé. Pour demander l’accès à cette fonctionnalité, communiquez avec votre représentant Auth0.
- La clé publique (
jwk) du client. - La charge utile se rapportant à la requête de jeton d’accès, incluant la méthode (
htm) et l’URI (htu). - Une signature créée à l’aide de la clé privée du client.
- Un id unique (
jti) pour prévenir les attaques par rejeu. - Pour chaque requête à une API, un hachage SHA-256 encodé en base64url (
ath) du jeton d’accès. - Facultatif : pour les , une revendication
noncepour garantir que l’application cliente a généré récemment le JWT de preuve DPoP.
Cas d’utilisation courants
- Applications monopages (SPA) et applications mobiles : En tant que clients publics, les SPA et les applications mobiles n’ont pas d’environnement fiable et confidentiel, comme un serveur backend, pour stocker de façon sécuritaire les , ce qui les rend vulnérables au vol de jetons. DPoP atténue cette vulnérabilité de sécurité en liant les jetons d’accès à la clé publique de l’application cliente, ce qui crée un JWT de preuve DPoP. L’application cliente signe le JWT de preuve DPoP avec sa clé privée et l’envoie dans une requête d’autorisation. Le Serveur d’autorisation Auth0 valide le JWT de preuve DPoP et, s’il est valide, lie le jeton d’accès émis à la clé publique du client.
- Intégrations d’API tierces : Si un agent d’IA intégré à votre application cliente appelle une API tierce pour le compte de l’utilisateur en utilisant un JWT de preuve DPoP, alors le peut vérifier cryptographiquement que la requête provient de l’agent d’IA et non d’un tiers non autorisé.
Types d’octroi d’autorisation d’application pris en charge
| Type d’octroi | Description |
|---|---|
authorization_code | Octroi par code d’autorisation |
client_credentials | Octroi par identifiants de Client |
password | Octroi par mot de passe du propriétaire des ressources |
refresh_token | Octroi par Jeton d’actualisation |
urn:ietf:params:oauth:grant-type:device_code | Octroi d’autorisation de dispositif |
http://auth0.com/oauth/grant-type/password-realm | Utiliser un octroi d’extension semblable à l’octroi par mot de passe du propriétaire des ressources, qui permet d’indiquer un realm spécifique |
http://auth0.com/oauth/grant-type/passwordless/otp | Requête d’octroi pour l’authentification sans mot de passe |
http://auth0.com/oauth/grant-type/mfa-oob | Requête d’octroi d’authentification multifacteur (AMF (MFA)) hors bande (OOB) |
http://auth0.com/oauth/grant-type/mfa-otp | Requête d’octroi d’authentification multifacteur (AMF (MFA)) par OTP |
http://auth0.com/oauth/grant-type/mfa-recovery-code | Requête d’octroi d’authentification multifacteur (AMF (MFA)) par code de récupération |
urn:ietf:params:oauth:grant-type:token-exchange | Requête d’octroi d’échange de jeton personnalisé |
urn:okta:params:oauth:grant-type:webauthn | Requête d’octroi WebAuthn |
Fonctionnement

- Lors de la demande d’un jeton d’accès auprès du Serveur d’autorisation Auth0, l’application cliente génère une paire de clés cryptographiques unique et utilise la clé publique pour prouver qu’elle possède la clé privée.
- L’application cliente génère le DPoP Proof JWT et l’envoie au point de terminaison /token du Serveur d’autorisation Auth0.
- Le Serveur d’autorisation Auth0 vérifie le DPoP Proof JWT et, s’il est valide, émet le jeton d’accès et le lie à la clé publique du client.
- Avant d’appeler l’API Customer, l’application cliente génère un nouveau DPoP Proof JWT pour prouver qu’elle possède la clé privée associée au jeton. L’application cliente envoie le DPoP Proof JWT et le jeton d’accès restreint à l’émetteur au serveur de ressources.
- Le serveur de ressources vérifie le DPoP Proof JWT afin de s’assurer que seul le propriétaire légitime du jeton, ou l’application cliente d’origine, peut l’utiliser pour accéder aux ressources protégées. Pour obtenir un jeton d’accès à partir d’un jeton d’actualisation, l’application cliente génère un nouveau DPoP Proof JWT, ce qui garantit que le jeton d’actualisation est lié à la clé publique du client.
Restreindre les jetons à l’expéditeur à l’aide de DPoP dans Auth0

- Prérequis
- Étape 1 : l’application cliente génère une paire de clés DPoP
- Étape 2 : l’application cliente crée un JWT de preuve DPoP
- Étape 3 : l’application cliente demande un jeton lié à DPoP
- Étape 4 : le Serveur d’autorisation Auth0 valide le JWT de preuve DPoP
- Étape 5 : l’application cliente appelle l’API avec le jeton lié à DPoP et le JWT de preuve DPoP
- Étape 6 : gérer l’actualisation du jeton avec DPoP
Prérequis
- Configurer la contrainte d’expéditeur pour votre application cliente et votre serveur de ressources.
Step 1: Client application generates a DPoP key pair
Étape 2 : L’application cliente crée un JWT de preuve DPoP
/token du Serveur d’autorisation Auth0, votre application cliente doit créer un JWT de preuve DPoP. Un JWT de preuve DPoP est un JSON Web Token (JWT) signé avec la clé privée de votre client qui sert de « preuve de possession ».
Le JWT de preuve DPoP se compose d’un en-tête JWT et d’une charge utile JWT qui contiennent des revendications liées à la requête de jeton :
Revendications d’en-tête JWT
| Revendication JWT de preuve DPoP | Description |
|---|---|
typ | Doit être défini sur dpop+jwt. |
alg | L’algorithme de signature asymétrique utilisé, comme RS256 ou ES256. |
jwk | Une représentation JSON Web Key (JWK) de la clé publique de votre client. |
Déclarations (claims) du payload JWT
| Déclaration JWT de preuve DPoP | Description |
|---|---|
jti | Identifiant unique du JWT pour empêcher les attaques par rejeu. |
htm | Méthode HTTP de la requête pour laquelle la preuve DPoP est utilisée, par exemple POST pour les requêtes de jeton et GET pour les appels d’API. |
htu | URI HTTP de la requête pour laquelle le JWT de preuve DPoP est utilisé, sans le fragment ni les paramètres de requête. Par exemple : https://api.example.com/data?param=1#section1 devient https://api.example.com/data. |
iat | Horodatage de création du JWT. |
ath | Pour les appels d’API avec un jeton d’accès, un hachage SHA-256 encodé en base64url du jeton d’accès. |
nonce | Pour les clients publics nécessitant un nonce, une valeur de nonce fournie par le serveur. |
Step 3: Client application requests a DPoP-bound token
/token endpoint, it includes the DPoP Proof JWT in the HTTP header of the request:
- Populates the DPoP HTTP header with a signed DPoP Proof JWT.
- Sends the DPoP HTTP header with a signed DPoP Proof JWT in an access token request to the
/tokenendpoint. - Processes the response from the Auth0 Authorization Server.
Clients publics
/token et n’inclut pas de valeur nonce dans l’en-tête HTTP DPoP, Auth0 répond avec un code HTTP 400 et un message d’erreur semblable au suivant :
DPoP-Nonce dans les en-têtes de réponse. Vous devez utiliser la valeur de l’en-tête DPoP-Nonce, régénérer la preuve DPoP (comme à l’étape 2), inclure une revendication nonce avec cette valeur, puis soumettre de nouveau la requête au point de terminaison /token.
L’exemple de code suivant montre le flux de bout en bout lors de l’envoi, puis de la nouvelle tentative d’exécution d’une requête /token avec une revendication nonce à partir d’un client public :
- Extracts the DPoP Proof JWT, its public key, and signature.
- Verifies the signature using the provided public key.
- Validates the
htm,htu,jti,andiatclaims. - If valid, it issues an access token. The Auth0 Authorization Server includes a confirmation claim,
cnf, in the access token. Thecnfclaim contains the thumbprint (hash) of the public key taken from the DPoP Proof JWT. By including it in the access token, the Auth0 Authorization Server binds the access token to that specific public key, or “sender-constrains” the access token. - Sets the
token_typein theAuthorizationheader toDPoPinstead ofBearerin the token response. Traditionally, when the access token is passed in theAuthorizationheader, it is set toBearer. However, because we’re passing an access token bound to a public key using DPoP, it is set toDPoPinstead. - The Auth0 Authorization Server then issues the DPoP sender-constrained access token to your client application.
Step 5: Client application calls API with the DPoP-bound token and DPoP Proof JWT
- Generates a new DPoP Proof JWT with the following claims:
- The
htmclaim is the API request’sHTTPmethod, such asGETorPOST. - The
htuclaim is the API request’s URI. - The
athclaim is the base64url-encoded SHA-256 hash of the DPoP-bound access token you received in Step 3.
- Cryptographically signs the new DPoP Proof JWT with the client’s private key.
-
Includes the DPoP-bound access token in the
Authorizationheader using theDPoPauthentication scheme:
- Includes the newly generated DPoP Proof JWT in the
DPoPHTTP header:
DPoP HTTP header must include an additional ath claim. The ath claim is a base64url encoded SHA256 hash of the issued access token.
The resource server:
- Receives the API request and extracts the access token, DPoP JWT proof, public key, and signature.
- Verifies the DPoP Proof JWT’s signature using the public key from its
jwkheader. - Validates the
htm,htu,jti,iat, andathclaims. - Verifies that the public key indicated in the DPoP Proof JWT via its
jwkheader matches the public key bound to the access token via thecnf.jktclaim in the access token.
/userinfo endpoint using a DPoP-bound access token:
Étape 6 : Gérer l’actualisation des jetons avec DPoP
- Envoie une requête de jeton d’actualisation au point de terminaison
/tokendu Serveur d’autorisation Auth0. - Génère un JWT de preuve DPoP pour la requête de jeton d’actualisation (semblable à l’étape 2, avec
htmcommePOSTethtucomme URI du ). - Inclut le JWT de preuve DPoP dans l’en-tête HTTP
DPoP.
- Valide le JWT de preuve DPoP (comme à l’étape 4) et émet un nouveau jeton d’accès lié à DPoP.
Important considerations
- Private key security: The security of your DPoP implementation depends on the security of your client’s private key, so you must protect it from unauthorized access. Private keys should be generated and stored in a hardware-backed medium and marked as non-exportable.
- Replay protection (
jti** anddpop-nonce):** Thejticlaim in the DPoP Proof JWT helps prevent replay attacks for protected resources, such as the/userinfoendpoint. The Auth0 Authorization Server currently does not checkjtireuse on the/userinfoendpoint. The Auth0 Authorization Server issues aDPoP-NonceHTTP header in its response, which public clients must include as anonceclaim in subsequent DPoP Proof JWTs for enhanced replay protection. - Error handling: You are responsible for implementing logic to handle DPoP-specific errors from the Auth0 Authorization Server or resource server, such as
invalid_dpop_prooforuse_dpop_nonce. - Client types: Use DPoP for public clients, such as Single Page Applications (SPAs) or mobile apps that cannot securely store a client secret. For , such as backend services with client secrets, DPoP adds a layer of security, but they already have other sender-constraining mechanisms.
- Performance: Because generating and signing DPoP Proof JWTs for every API call adds a small overhead, ensure your client application’s cryptographic operations are efficient.
- Key rotation: Implement a strategy for rotating your DPoP key pairs for enhanced security. Make sure you use the same key pair for the same session.
- Persistence: For client applications that need to maintain a session and reuse DPoP-bound access tokens, such as long-lived SPAs, securely persist and retrieve the original generated key pair across application reloads. If a new key pair is generated or a different key pair is used, the DPoP-bound access token becomes invalid, as it is cryptographically tied to the public key of the original pair. You can persist the key pair, for example, in a browser’s
IndexedDBor a mobile app’s secure storage.