8. Authorization Server-Provided Nonce

Cette section spécifie un mécanisme permettant d'utiliser un nonce opaque fourni par le serveur pour limiter la durée de vie des preuves DPoP. Si aucun mécanisme de ce type n'est utilisé, une partie malveillante contrôlant le client (y compris éventuellement l'utilisateur final) peut créer des preuves DPoP utilisables à n'importe quel moment dans le futur.

L'inclusion d'une valeur de nonce alimentée par le serveur d'autorisation dans la preuve DPoP PEUT être utilisée par le serveur d'autorisation pour limiter la durée de vie des preuves DPoP. Il appartient au serveur de décider quand émettre un nouveau défi de nonce DPoP et quand il en exige un, exigeant ainsi l'utilisation de la valeur de nonce dans les preuves DPoP suivantes. La logique par laquelle un serveur prend cette décision est hors de la portée de ce document.

Un serveur d'autorisation PEUT fournir une valeur de nonce que le client doit inclure dans les preuves DPoP envoyées. Il le fait en répondant à une requête sans nonce avec une réponse d'erreur HTTP 400 (Bad Request) avec use_dpop_nonce comme valeur de code d'erreur, comme spécifié dans la section 5.2 de la [RFC6749]. Le serveur d'autorisation inclut un en-tête DPoP-Nonce dans la réponse fournissant une valeur de nonce à utiliser lors de l'envoi de requêtes ultérieures. La valeur du nonce DOIT être imprévisible. Ce même code d'erreur est également utilisé pour fournir une nouvelle valeur de nonce en cas de discordance de nonce. Le client reçoit normalement une erreur use_dpop_nonce et la valeur de nonce qui l'accompagne, et réessaye la requête avec la nouvelle valeur de nonce fournie.

Par exemple, en réponse à une demande de jeton sans nonce alors que le serveur d'autorisation exige un nonce, le serveur d'autorisation peut renvoyer une valeur DPoP-Nonce telle que ce qui suit pour fournir une valeur de nonce à inclure dans la preuve DPoP :

HTTP/1.1 400 Bad Request
DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v

{
 "error": "use_dpop_nonce",
 "error_description":
   "Authorization server requires nonce in DPoP proof"
}

  Figure 20: Réponse HTTP 400 à une demande de jeton sans nonce

D'autres en-têtes HTTP ou champs JSON PEUVENT être inclus dans la réponse d'erreur, mais il NE DOIT PAS y avoir plus d'un en-tête DPoP-Nonce.

Dès réception d'un nonce, le client est censé réessayer la demande de jeton en utilisant une preuve DPoP incluant la valeur de nonce fournie dans la revendication nonce de la preuve DPoP. Voici un exemple de charge utile JWT non codée pour une telle preuve DPoP contenant le nonce :

{
 "jti": "-BwC3ESc6acc2lTc",
 "htm": "POST",
 "htu": "https://server.example.com/token",
 "iat": 1562262616,
 "nonce": "eyJ7S_zG.eyJH0-Z.HX4w-7v"
}

       Figure 21: Charge utile de preuve DPoP avec valeur de nonce

Le nonce est opaque pour le client.

Si la revendication nonce d'une preuve DPoP ne correspond pas exactement à un nonce fourni récemment au client par le serveur d'autorisation, le serveur d'autorisation DOIT rejeter la demande. La réponse de rejet PEUT inclure un en-tête HTTP DPoP-Nonce fournissant une nouvelle valeur de nonce à utiliser pour les demandes ultérieures.

L'intention est que le client n'ait besoin de conserver qu'une seule valeur de nonce et que le serveur conserve une fenêtre de nonces récents. Cela dit, il peut survenir des situations transitoires où les valeurs de nonce stockées par le serveur et le client ne sont pas synchronisées. Cependant, cette situation s'auto-corrige : avec un message de rejet, le serveur peut envoyer au client la valeur de nonce qu'il souhaite voir utilisée, que le client peut stocker et utiliser pour réessayer la demande. Même si le client ou le serveur supprime sa valeur de nonce stockée, la situation s'auto-corrige également car une nouvelle valeur de nonce peut être communiquée lors de la réponse à une demande échouée ou lors d'une nouvelle tentative.

Notez que les applications clientes basées sur un navigateur utilisant le partage de ressources cross-origin (CORS) [WHATWG.Fetch] n'auront accès qu'aux en-têtes HTTP de réponse de la liste de sécurité CORS par défaut. Pour permettre à l'application d'accéder à la valeur de l'en-tête de réponse HTTP DPoP-Nonce et de l'utiliser, le serveur doit la mettre à la disposition de l'application en incluant DPoP-Nonce dans la valeur de la liste d'en-têtes de réponse Access-Control-Expose-Headers.

8.1. Syntaxe du nonce

La syntaxe ABNF pour le nonce (qui est la même que la syntaxe scope-token) de la [RFC6749] est la suivante :

nonce = 1*NQCHAR

                        Figure 22: ABNF du nonce

8.2. Fournir une nouvelle valeur de nonce

Le serveur d'autorisation décide quand fournir une nouvelle valeur de nonce à utiliser par le client. Le client est censé utiliser un nonce fourni existant dans les preuves DPoP jusqu'à ce que le serveur fournisse une nouvelle valeur de nonce.

Le serveur d'autorisation PEUT fournir un nouveau nonce de la même manière que le nonce initial a été fourni - en utilisant un en-tête HTTP DPoP-Nonce dans une réponse. Le champ d'en-tête HTTP DPoP-Nonce utilise la syntaxe de nonce définie dans la section 8.1. Chaque fois que cela se produit, un aller-retour de protocole supplémentaire est nécessaire.

Une méthode plus efficace pour fournir une nouvelle valeur de nonce est également définie, qui consiste à inclure l'en-tête HTTP DPoP-Nonce dans la réponse HTTP 200 (OK) d'une demande précédente. Le client DOIT utiliser la nouvelle valeur de nonce fournie pour la demande de jeton suivante et toutes les demandes de jeton suivantes jusqu'à ce que le serveur d'autorisation fournisse un nouveau nonce.

Les réponses contenant un en-tête HTTP DPoP-Nonce DEVRAIENT être impossibles à mettre en cache (par exemple, en utilisant Cache-Control: no-store dans une réponse à une requête GET) pour éviter que la réponse ne soit utilisée pour servir une requête ultérieure et, par conséquent, qu'une valeur de nonce obsolète ne soit utilisée.

Voici un exemple de réponse 200 OK fournissant la valeur de nonce suivante :

HTTP/1.1 200 OK
Cache-Control: no-store
DPoP-Nonce: eyJ7S_zG.eyJbYu3.xQmBj-1

    Figure 23: Réponse HTTP 200 fournissant la valeur de nonce suivante