2. Objectives

The primary aim of DPoP is to prevent unauthorized or illegitimate parties from using leaked or stolen access tokens, by binding a token to a public key upon issuance and requiring that the client proves possession of the corresponding private key when using the token. This constrains the legitimate sender of the token to only the party with access to the private key and gives the server receiving the token added assurances that the sender is legitimately authorized to use it.

Access tokens that are sender-constrained via DPoP thus stand in contrast to the typical bearer token, which can be used by any party in possession of such a token. Although protections generally exist to prevent unintended disclosure of bearer tokens, unforeseen vectors for leakage have occurred due to vulnerabilities and implementation issues in other layers in the protocol or software stack (see, e.g., Compression Ratio Info-leak Made Easy (CRIME) [CRIME], Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) [BREACH], Heartbleed [Heartbleed], and the Cloudflare parser bug [Cloudbleed]). There have also been numerous published token theft attacks on OAuth implementations themselves ([GitHub.Tokens] is just one high-profile example). DPoP provides a general defense in depth against the impact of unanticipated token leakage. DPoP is not, however, a substitute for a secure transport and MUST always be used in conjunction with HTTPS.

The very nature of the typical OAuth protocol interaction necessitates that the client discloses the access token to the protected resources that it accesses. The attacker model in [SECURITY-TOPICS] describes cases where a protected resource might be counterfeit, malicious, or compromised and plays received tokens against other protected resources to gain unauthorized access. Audience-restricted access tokens (e.g., using the JWT [RFC7519] aud claim) can prevent such misuse. However, doing so in practice has proven to be prohibitively cumbersome for many deployments (despite extensions such as [RFC8707]). Sender-constraining access tokens is a more robust and straightforward mechanism to prevent such token replay at a different endpoint, and DPoP is an accessible application-layer means of doing so.

Due to the potential for cross-site scripting (XSS), browser-based OAuth clients bring to bear added considerations with respect to protecting tokens. The most straightforward XSS-based attack is for an attacker to exfiltrate a token and use it themselves completely independent of the legitimate client. A stolen access token is used for protected resource access, and a stolen refresh token is used for obtaining new access tokens. If the private key is non-extractable (as is possible with [W3C.WebCryptoAPI]), DPoP renders exfiltrated tokens alone unusable.

XSS vulnerabilities also allow an attacker to execute code in the context of the browser-based client application and maliciously use a token indirectly through the client. That execution context has access to utilize the signing key; thus, it can produce DPoP proofs to use in conjunction with the token. At this application layer, there is most likely no feasible defense against this threat except generally preventing XSS; therefore, it is considered out of scope for DPoP.

Malicious XSS code executed in the context of the browser-based client application is also in a position to create DPoP proofs with timestamp values in the future and exfiltrate them in conjunction with a token. These stolen artifacts can later be used independent of the client application to access protected resources. To prevent this, servers can optionally require clients to include a server-chosen value into the proof that cannot be predicted by an attacker (nonce). In the absence of the optional nonce, the impact of pre-computed DPoP proofs is limited somewhat by the proof being bound to an access token on protected resource access. Because a proof covering an access token that does not yet exist cannot feasibly be created, access tokens obtained with an exfiltrated refresh token and pre-computed proofs will be unusable.

Additional security considerations are discussed in Section 11.