3. Concept

La principale structure de données introduite par cette spécification est le JWT de preuve DPoP (DPoP proof JWT), envoyé en tant qu'en-tête dans une requête HTTP, comme détaillé ci-dessous. Le client utilise un JWT de preuve DPoP pour prouver qu'il détient la clé privée correspondant à une certaine clé publique.

Grosso modo, une preuve DPoP est une signature sur :

certaines données de la requête HTTP à laquelle elle est attachée,
un horodatage,
un identifiant unique,
un nonce optionnel fourni par le serveur, et
un hachage du jeton d'accès associé, lorsqu'un jeton d'accès est présent dans la requête.

+--------+                                          +---------------+
|        |--(A)-- Demande de jeton ---------------->|               |
| Client |        (Preuve DPoP)                     | Serveur       |
|        |                                          | d'autorisation|
|        |<-(B)-- Jeton d'accès lié à DPoP ---------|               |
|        |        (token_type=DPoP)                 +---------------+
|        |
|        |
|        |                                          +---------------+
|        |--(C)-- Jeton d'accès lié à DPoP -------->|               |
|        |        (Preuve DPoP)                     | Serveur       |
|        |                                          | de ressources |
|        |<-(D)-- Ressource protégée ---------------|               |
|        |                                          +---------------+
+--------+

                      Figure 1: Flux DPoP de base

Les étapes de base d'un flux OAuth avec DPoP (sans le nonce optionnel) sont illustrées à la Figure 1.

A. Dans une demande de jeton, le client envoie une autorisation (par exemple, un code d'autorisation, un jeton d'actualisation, etc.) au serveur d'autorisation pour obtenir un jeton d'accès (et éventuellement un jeton d'actualisation). Le client attache une preuve DPoP à la demande dans un en-tête HTTP.

B. Le serveur d'autorisation lie (contraint l'émetteur) le jeton d'accès à la clé publique que le client a revendiquée dans la preuve DPoP ; c'est-à-dire que le jeton d'accès ne peut pas être utilisé sans prouver la possession de la clé privée correspondante. Si un jeton d'actualisation est émis à un client public, il est également lié à la clé publique de la preuve DPoP.

C. Pour utiliser le jeton d'accès, le client doit prouver la possession de la clé privée en ajoutant à nouveau un en-tête contenant une preuve DPoP de la demande à la demande. Le serveur de ressources doit recevoir des informations sur la clé publique à laquelle le jeton d'accès est lié. Ces informations peuvent être encodées directement dans le jeton d'accès (pour les jetons d'accès structurés JWT) ou fournies via le point de terminaison d'introspection de jeton (non représenté). Le serveur de ressources vérifie que la clé publique à laquelle le jeton d'accès est lié correspond à la clé publique de la preuve DPoP. Il vérifie également que le hachage du jeton d'accès dans la preuve DPoP correspond au jeton d'accès présenté dans la demande.

D. Si la vérification de la signature échoue ou si les données de la preuve DPoP sont incorrectes (par exemple, si l'URI cible ne correspond pas à la revendication URI dans le JWT de preuve DPoP), le serveur de ressources refuse de servir la demande. Le jeton d'accès lui-même doit, bien entendu, également être valide à tous autres égards.

Le mécanisme DPoP proposé ici n'est pas une méthode d'authentification client. En fait, l'un des principaux cas d'utilisation de DPoP concerne les clients publics (par exemple, les applications monopages et les applications sur les appareils des utilisateurs) qui n'utilisent pas d'authentification client. Néanmoins, DPoP est conçu pour être compatible avec private_key_jwt et toutes les autres méthodes d'authentification client.

DPoP n'assure pas directement l'intégrité des messages, mais s'appuie sur la couche TLS à cette fin. Voir la section 11 pour plus de détails.

3. Concept​

3. Concept