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:
{
"issuer": "https://attacker.com",
"authorization_endpoint": "https://honest.com/authorize",
"token_endpoint": "https://honest.com/token",
"userinfo_endpoint": "https://attacker.com/userinfo" # ← attacker
}
Attack:
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.
If a user's browser is online and an attacker has injected JavaScript code into the client's SPA, the attacker can use the token without exfiltrating it first. There is most likely no defense against this threat except preventing XSS.
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.
We should think about requiring/allowing for a server-sent nonce via the WWW-Authenticate header.
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!