1. Introduction
1. Introduction
Démontrer la preuve de possession (Demonstrating Proof of Possession - DPoP) est un mécanisme de niveau applicatif permettant de contraindre l'émetteur (sender-constraining) des jetons d'accès et d'actualisation OAuth [RFC6749]. Il permet aux clients de démontrer la possession d'une paire de clés publique/privée en incluant un en-tête DPoP dans une requête HTTP. La valeur de l'en-tête est un jeton Web JSON (JWT) [RFC7519] qui permet au serveur d'autorisation de lier les jetons émis à la partie publique de la paire de clés du client. Les destinataires de ces jetons sont ensuite en mesure de vérifier le lien entre le jeton et la paire de clés que le client a démontré détenir via l'en-tête DPoP, fournissant ainsi l'assurance que le client présentant le jeton possède également la clé privée. En d'autres termes, le détenteur légitime du jeton est contraint d'être l'émetteur qui détient et démontre la possession de la partie privée de la paire de clés.
Le mécanisme spécifié ici peut être utilisé dans les cas où d'autres méthodes de contrainte de l'émetteur utilisant des éléments de la couche de transport sécurisée sous-jacente (telle que [RFC8705] ou [TOKEN-BINDING]) ne sont pas disponibles ou souhaitables. Par exemple, aucune de ces méthodes ne peut être utilisée si le client OAuth est une application téléchargée dynamiquement et exécutée dans un navigateur Web (parfois appelée « application monopage ») en raison d'une expérience utilisateur médiocre pour l'authentification client TLS dans les agents utilisateurs et de l'absence de prise en charge pour HTTP Token Binding. De plus, les applications installées et exécutées directement sur un appareil utilisateur sont bien placées pour bénéficier de jetons liés par DPoP afin d'empêcher l'utilisation abusive de jetons compromis par des ressources malveillantes ou compromises. Ces applications disposent généralement d'un stockage sécurisé dédié pour les clés cryptographiques.
DPoP peut être utilisé pour contraindre l'émetteur des jetons d'accès quelle que soit la méthode d'authentification du client utilisée, mais DPoP n'est pas utilisé pour l'authentification du client en soi. DPoP peut également être utilisé pour contraindre l'émetteur des jetons d'actualisation émis aux clients publics (c'est-à-dire les clients sans identifiants d'authentification associés à un client_id).
1.1. Conventions et terminologie
Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsqu'ils apparaissent en toutes lettres, comme indiqué ici.
Cette spécification utilise la notation Augmented Backus-Naur Form (ABNF) de la [RFC5234].
Cette spécification utilise les termes « jeton d'accès », « jeton d'actualisation », « serveur d'autorisation », « serveur de ressources », « point de terminaison d'autorisation », « demande d'autorisation », « réponse d'autorisation », « point de terminaison de jeton », « type d'autorisation » (grant type), « demande de jeton d'accès », « réponse de jeton d'accès », « client », « client public » et « client confidentiel » définis par le « cadre d'autorisation OAuth 2.0 » [RFC6749].
Les termes « requête », « réponse », « champ d'en-tête » et « URI cible » sont tirés de la [RFC9110].
Les termes "JOSE" et "JOSE Header" sont tirés de la [RFC7515].
Ce document contient des exemples non normatifs de messages HTTP partiels et complets. Quelques exemples utilisent une barre oblique inversée unique pour indiquer le retour à la ligne des valeurs longues, conformément à la [RFC8792]. La barre oblique inversée de retour à la ligne ainsi que la nouvelle ligne suivante et l'espace de début ne font pas partie de la valeur.