2. Objectives
2. Objectives
L'objectif principal de DPoP est d'empêcher l'utilisation non autorisée ou illégitime de jetons d'accès divulgués ou volés par des parties non autorisées, en liant le jeton à une clé publique lors de son émission et en exigeant que le client prouve la possession de la clé privée correspondante lors de l'utilisation du jeton. Cela contraint l'émetteur légitime du jeton à être uniquement la partie détenant la clé privée, donnant au serveur recevant le jeton l'assurance que l'émetteur est légitimement autorisé à l'utiliser.
Les jetons d'accès contraints par l'émetteur via DPoP contrastent donc avec les jetons au porteur (Bearer) typiques, qui peuvent être utilisés par toute partie en possession de ce jeton. Bien qu'il existe généralement des protections pour empêcher la divulgation par inadvertance de jetons au porteur, des vecteurs de fuite imprévus se sont produits en raison de vulnérabilités et de problèmes d'implémentation dans d'autres couches de la pile protocolaire ou logicielle (par exemple, Compression Ratio Info-leak Made Easy (CRIME) [CRIME], Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) [BREACH], Heartbleed [Heartbleed] et le bug du parseur Cloudflare [Cloudbleed]). Les implémentations OAuth elles-mêmes ont également subi de nombreuses attaques de vol de jetons rendues publiques ([GitHub.Tokens] n'est qu'un exemple notable). DPoP fournit un mécanisme général de défense en profondeur pour se prémunir contre les conséquences de telles fuites accidentelles de jetons. DPoP ne remplace cependant pas un transport sécurisé et doit toujours être utilisé en conjonction avec HTTPS.
La nature des interactions protocolaires OAuth typiques exige que le client divulgue le jeton d'accès à la ressource protégée à laquelle il accède. Le modèle d'attaquant dans [SECURITY-TOPICS] décrit le cas où la ressource protégée est contrefaite, malveillante ou compromise et utilise le jeton reçu sur d'autres ressources protégées pour obtenir un accès non autorisé. Les jetons d'accès limités à une audience (par exemple, en utilisant la revendication aud d'un JWT [RFC7519]) peuvent empêcher une telle utilisation abusive. En pratique, cependant, cela s'avère trop lourd pour de nombreux déploiements (malgré des extensions comme [RFC8707]). La contrainte de l'émetteur des jetons d'accès est un mécanisme plus robuste et direct pour empêcher le rejeu de tels jetons sur différents points de terminaison, DPoP étant l'un des moyens viables au niveau applicatif.
Les clients OAuth basés sur un navigateur apportent des considérations supplémentaires concernant la protection des jetons en raison du risque potentiel de Cross-Site Scripting (XSS). L'attaque basée sur XSS la plus directe est celle où l'attaquant dérobe le jeton et l'utilise de manière totalement indépendante du client légitime. Les jetons d'accès volés sont utilisés pour accéder aux ressources protégées, et les jetons d'actualisation volés sont utilisés pour obtenir de nouveaux jetons d'accès. Si la clé privée est stockée de manière à ne pas être exportable (comme cela peut être activé par [W3C.WebCryptoAPI]), DPoP rend les jetons volés inutiles par eux-mêmes.
Une vulnérabilité XSS permet également à un attaquant d'exécuter du code dans le contexte de l'application cliente basée sur un navigateur et d'utiliser le jeton de manière malveillante indirectement via le client. Ce contexte d'exécution a accès aux clés de signature ; par conséquent, il peut produire des preuves DPoP à utiliser en conjonction avec le jeton. Il n'existe probablement aucune défense viable contre cette menace à cette couche applicative, autre que la prévention générale des XSS ; cela est donc considéré comme hors de portée de DPoP.
Un code XSS malveillant s'exécutant dans le contexte de l'application cliente basée sur un navigateur peut également créer des preuves DPoP avec des valeurs d'horodatage futures et les exfiltrer avec des jetons. Ces artefacts volés peuvent ensuite être utilisés indépendamment de l'application cliente pour accéder aux ressources protégées. Pour empêcher cela, un serveur peut choisir d'exiger du client qu'il inclue dans la preuve une valeur choisie par le serveur (un nonce) imprévisible pour l'attaquant. En l'absence d'un nonce optionnel, l'impact des preuves DPoP pré-calculées est limité par la liaison de la preuve au jeton d'accès lors de l'accès à la ressource protégée. Comme il n'est pas possible de créer de manière réaliste une preuve couvrant un jeton d'accès qui n'existe pas encore, un jeton d'accès obtenu à l'aide d'un jeton d'actualisation volé et d'une preuve pré-calculée ne sera pas utilisable.
D'autres considérations de sécurité sont abordées dans la section 11.