7. Protected Resource Access

Pour accéder aux ressources protégées avec DPoP, la requête doit contenir à la fois la preuve DPoP décrite à la section 4 et le jeton d'accès décrit à la section 7.1. La preuve DPoP DOIT inclure la revendication ath avec une valeur de hachage valide pour le jeton d'accès associé.

Lier la valeur du jeton à la preuve de cette manière empêche la preuve d'une requête d'être utilisée dans une autre requête avec une valeur de jeton d'accès différente. Par exemple, si un client détient les jetons AT1 et AT2 liés à deux propriétaires de ressources différents et utilise la même clé pour les interactions avec le serveur d'autorisation, ces jetons pourraient être échangés. Sans la liaison via le champ ath, une signature capturée pour AT1 pourrait être rejouée avec AT2, changeant potentiellement les autorisations et l'accès de la requête prévue. Pour les jetons d'accès qui font l'objet d'une rotation au sein de la même combinaison client et propriétaire de ressource, une telle prévention de substitution reste efficace car la valeur du jeton rotté nécessite le calcul d'une nouvelle preuve. Cette liaison garantit également qu'une preuve destinée à être utilisée avec un jeton d'accès ne peut pas être utilisée sans ce jeton, et vice-versa.

Le serveur de ressources DOIT calculer le hachage de la valeur du jeton présenté et vérifier qu'il est identique à la valeur de hachage fournie dans le champ ath (voir la section 4.3). La valeur du champ ath étant couverte par la signature de la preuve DPoP, son inclusion lie la valeur du jeton d'accès au propriétaire de la clé utilisée pour générer la signature.

Notez que le champ ath seul ne protège pas contre le rejeu de la preuve DPoP et ne fournit pas de liaison à la requête avec laquelle la preuve est présentée. La fenêtre de vérification de la preuve et les paramètres de message inclus, tels que htm et htu, sont toujours importants.

7.1. Le schéma d'authentification DPoP

Un jeton d'accès lié à DPoP est envoyé à l'aide du champ d'en-tête de requête Authorization avec le schéma d'authentification DPoP conformément à la section 11.6.2 de la [RFC9110]. La syntaxe du champ d'en-tête Authorization pour le schéma DPoP utilise la syntaxe token68 définie dans la section 11.2 de la [RFC9110] pour les informations d'identification, reproduite ci-dessous par commodité. La syntaxe de notation ABNF pour les informations d'identification du schéma d'authentification DPoP est la suivante :

token68    = 1*( ALPHA / DIGIT /
                 "-" / "." / "_" / "~" / "+" / "/" ) *"="

credentials = "DPoP" 1*SP token68

              Figure 12: ABNF du schéma d'authentification DPoP

Pour un tel jeton d'accès, un serveur de ressources DOIT vérifier qu'une preuve DPoP est également reçue dans le champ d'en-tête HTTP DPoP de la requête HTTP, vérifier la preuve DPoP selon les règles de la section 4.3 et vérifier que la clé publique de la preuve DPoP correspond à la clé publique à laquelle le jeton d'accès est lié conformément à la section 6.

Le serveur de ressources NE DOIT PAS donner accès à la ressource à moins que toutes les vérifications ne soient couronnées de succès.

La Figure 13 montre un exemple de requête à une ressource protégée avec un jeton d'accès lié à DPoP dans l'en-tête Authorization et la preuve DPoP dans l'en-tête DPoP. L'exemple utilise "\" pour le retour à la ligne, conformément à la [RFC8792]. Le contenu décodé de cette preuve DPoP est présenté à la Figure 14. Le JSON de l'en-tête JWT et de la charge utile est affiché, mais la partie signature est omise. Comme d'habitude, des sauts de ligne et une indentation sont inclus pour le formatage et la lisibilité.

GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRtIj\
 oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z\
 WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOCwiYXRoIjoiZlVIeU8ycjJaM0RaNTNF\
 c05yV0JiMHhXWG9hTnk1OUlpS0NBcWtzbVFFbyJ9.2oW9RP35yRqzhrtNP86L-Ey71E\
 OptxRimPPToA1plemAgR6pxHF8y6-yqyVnmcw6Fy1dqd-jfxSYoMxhAJpLjA

              Figure 13: Requête de ressource protégée avec DPoP

{
  "typ":"dpop+jwt",
  "alg":"ES256",
  "jwk": {
    "kty":"EC",
    "x":"l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
    "y":"9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
    "crv":"P-256"
  }
}
.
{
  "jti":"e1j3V_bKic8-LAEB",
  "htm":"GET",
  "htu":"https://resource.example.org/protectedresource",
  "iat":1562262618,
  "ath":"fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo"
}

    Figure 14: Contenu décodé du JWT de preuve DPoP de la Figure 13

Lors de la réception d'une requête sans informations d'identification valides ou avec des informations d'accès insuffisantes pour une ressource protégée au sein d'un espace de protection nécessitant une authentification DPoP, le serveur PEUT envoyer une réponse contenant un défi (challenge) pour solliciter des informations d'authentification DPoP de la part du client. Ce défi est envoyé en utilisant le code d'état de réponse 401 (Non autorisé) ([RFC9110] Section 15.5.2) et le champ d'en-tête WWW-Authenticate ([RFC9110] Section 11.6.1). Le serveur MAY inclure l'en-tête WWW-Authenticate en réponse à d'autres conditions également.

Dans de tels défis :

Le nom du schéma est DPoP.
Le paramètre d'authentification realm PEUT être inclus pour indiquer la portée de la protection de la manière décrite dans la [RFC9110], section 11.5.
Le paramètre d'authentification scope défini dans la [RFC6750], section 3, PEUT être inclus.
Le paramètre error ([RFC6750], section 3) DEVRAIT être inclus pour indiquer la raison pour laquelle la requête a été refusée, si la requête incluait un jeton d'accès mais a échoué à l'authentification. Les valeurs du paramètre error décrites dans la [RFC6750], section 3.1, sont applicables, ainsi que toutes les valeurs appropriées définies par des extensions. La valeur use_dpop_nonce peut être utilisée pour signaler qu'un nonce est requis dans les preuves DPoP des requêtes suivantes, comme décrit dans la section 9. De plus, invalid_dpop_proof est utilisé pour indiquer que la preuve DPoP elle-même a été jugée invalide selon les critères de la section 4.3.
Le paramètre error_description ([RFC6750], section 3) PEUT être inclus avec le paramètre error pour fournir une explication lisible par l'homme destinée aux développeurs, qui n'est pas destinée à être affichée aux utilisateurs finaux.
Un paramètre algs DEVRAIT être inclus pour signaler au client les algorithmes JWS qui peuvent être utilisés pour les JWT de preuve DPoP. La valeur de ce paramètre est une liste de valeurs d'en-tête alg (algorithme) JWS séparées par des espaces ([RFC7515], section 4.1.1).
D'autres paramètres d'authentification peuvent être utilisés ; les paramètres inconnus DOIVENT être ignorés par le destinataire.

La Figure 15 illustre une réponse à une requête pour une ressource protégée sans authentification.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP algs="ES256 PS256"

Figure 15: Réponse HTTP 401 à une requête de ressource protégée sans authentification

La Figure 16 illustre une réponse à une requête de ressource protégée qui a été rejetée en raison de l'échec de la vérification de la liaison DPoP du jeton d'accès. L'exemple utilise "\" pour le retour à la ligne, conformément à la [RFC8792].

HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP error="invalid_token", \
   error_description="Invalid DPoP key binding", algs="ES256"

  Figure 16: Réponse HTTP 401 à une requête de ressource protégée avec un jeton invalide

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 WWW-Authenticate et de l'utiliser, le serveur doit la mettre à la disposition de l'application en incluant WWW-Authenticate dans la valeur de la liste d'en-têtes de réponse Access-Control-Expose-Headers.

Ce schéma d'authentification est destiné uniquement à l'authentification du serveur d'origine. Par conséquent, ce schéma d'authentification NE DOIT PAS être utilisé avec les champs d'en-tête Proxy-Authenticate ou Proxy-Authorization.

Notez que la syntaxe du champ d'en-tête Authorization pour ce schéma d'authentification suit l'utilisation du schéma Bearer défini dans la [RFC6750], section 2.1. Bien que ce ne soit pas la syntaxe d'informations d'identification préférée de la [RFC9110] section 11.4, elle est compatible avec le cadre d'authentification général qui y figure et est utilisée pour assurer la cohérence et la familiarité avec le schéma Bearer.

7.2. Compatibilité avec le schéma d'authentification Bearer

Les ressources protégées prenant en charge à la fois les schémas DPoP et Bearer doivent mettre à jour les procédures d'évaluation des jetons Bearer pour empêcher l'utilisation dégradée (downgrade) des jetons liés à DPoP. Plus précisément, une telle ressource protégée DOIT rejeter un jeton d'accès lié à DPoP reçu en tant que jeton Bearer (conformément à la [RFC6750]).

La [RFC9110] section 11.6.1 permet à une ressource protégée d'indiquer la prise en charge de plusieurs schémas d'authentification (c'est-à-dire Bearer et DPoP) via le champ d'en-tête WWW-Authenticate d'une réponse 401 (Non autorisé).

Une ressource protégée ne prenant en charge que la [RFC6750] et ignorant DPoP acceptera probablement un jeton d'accès lié à DPoP comme un jeton Bearer (JWT [RFC7519] indique que les revendications non reconnues sont ignorées, Introspection [RFC7662] indique que d'autres paramètres peuvent être présents mais n'a aucune exigence fonctionnelle quant à leur présence, et la [RFC6750] est effectivement muette sur le contenu du jeton d'accès en ce qui concerne la validité). Un client peut donc envoyer un jeton d'accès lié à DPoP en utilisant le schéma Bearer lorsqu'il reçoit un défi WWW-Authenticate: Bearer d'une ressource protégée (ou à tout moment, s'il a une connaissance préalable des capacités de la ressource protégée). Cela peut simplifier la logistique pour une mise à niveau progressive vers la prise en charge de DPoP par les ressources protégées ou les déploiements mixtes à long terme de prise en charge des types de jetons par les ressources protégées.

Si une ressource protégée prenant en charge à la fois les schémas Bearer et DPoP choisit de répondre avec plusieurs défis WWW-Authenticate, il convient de veiller à ce que le défi transmette les informations d'erreur réelles. Il est recommandé de suivre les règles suivantes :

Si la requête ne contenait aucune information d'identification, les défis ne devraient pas inclure de codes d'erreur ou d'autres informations d'erreur comme décrit dans la section 3.1 de la [RFC6750] (Figure 17).
Si le mécanisme avec lequel l'authentification a été tentée peut être clairement établi, le défi correspondant devrait être utilisé pour transmettre les informations d'erreur (Figure 18).
Sinon, les deux défis Bearer et DPoP peuvent être utilisés pour transmettre des informations d'erreur (Figure 19).

Les exemples suivants utilisent "\" pour le retour à la ligne, conformément à la [RFC8792].

GET /protectedresource HTTP/1.1
Host: resource.example.org

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer, DPoP algs="ES256 PS256"

 Figure 17: Réponse HTTP 401 à une requête de ressource protégée sans authentification

GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: Bearer INVALID_TOKEN

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token", \
    error_description="Invalid token", DPoP algs="ES256 PS256"

  Figure 18: Réponse HTTP 401 à une requête de ressource protégée avec une authentification invalide

GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: Bearer Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU

HTTP/1.1 400 Bad Request
WWW-Authenticate: Bearer error="invalid_request", \
 error_description="Multiple methods used to include access token", \
 DPoP algs="ES256 PS256", error="invalid_request", \
 error_description="Multiple methods used to include access token"

  Figure 19: Réponse HTTP 400 à une requête de ressource protégée avec une authentification ambiguë

7.3. Considérations relatives au client

Les demandes d'autorisation contenant des preuves DPoP risquent de ne pas être idempotentes (en fonction de l'application par le serveur des revendications jti, iat et nonce), ce qui rend les requêtes vers des ressources protégées qui étaient auparavant idempotentes, potentiellement plus idempotentes. Il est suggéré que les clients génèrent des preuves DPoP uniques même pour les tentatives de requêtes idempotentes en réponse à ce qui est généralement compris comme des erreurs HTTP transitoires.

Les clients rencontrant fréquemment des erreurs réseau peuvent être confrontés à des défis supplémentaires lors de l'interaction avec des serveurs mettant en œuvre une validation de nonce plus stricte.