This document outlines attacker models considered for DPoP.
Note: DPoP is still an IETF working group draft. This is not a normative document and the final attacker model for DPoP might look different to the one presented here!
A resource endpoint is misconfigured. For example, if OAuth Metadata is used, the following configuration can lead to the userinfo endpoint being under the control of the attacker:
Note that the userinfo endpoint points to an attacker-controlled site.
One of multiple resource servers can become compromised or act maliciously for other reasons.
If TLS termination is done at a separate component at the resource server, that component can become compromised, for example by exploting a buffer overflow attack in the reverse proxy:
An attacker can leverage an XSS attack to exfiltrate the access token from a single page application. The attacker then tries to use the token. It is not required that the victim is still online for this attack.
Note: It is in general hard or impossible to defend against this threat. It should therefore be considered out of the scope of DPoP.
If the attacker is able to precompute DPoP tokens, or is able to exfiltrate the secret key needed for generating DPoP proofs along with the access token, DPoP does not protect the access token if no server-generated nonce is used in the proof.
Recommendation: Requiring/allowing for a server-sent nonce via the WWW-Authenticate header would improve the security of DPoP.
Attacks on TLS might allow for the recovery of strings in encrypted messages that are repeated in multiple messages. One example would be the BREACH attacks against HTTP compression.
Update 1: Added the correct variant of Online XSS; renamed the one that was previously there to “Precomputed proofs”; added “Exfiltration from Otherwise Secure Channel”. Thanks, Neil!