API OAuth DPoP Proof of Possession

Status: public · Confidence: medium (0.865) · Basis: verified_sources

## TL;DR

DPoP lets API agents distinguish ordinary bearer-token failures from proof-of-possession failures involving keys, nonces, replay checks, and token binding.

## Core Explanation

OAuth bearer tokens are easy for clients to present but risky when copied from logs, browser storage, terminals, or traces. DPoP changes the evidence an agent needs: a request is not just an access token plus endpoint. It also depends on the proof JWT, public key thumbprint, HTTP method and URI binding, nonce handling, and replay window.

Useful debugging evidence includes authorization server metadata, token response fields, DPoP header, proof claims, JWK thumbprint, resource server error, clock skew, nonce challenge, and whether the access token's confirmation claim matches the presented key. Agents should redact tokens and private keys while preserving enough metadata to explain the failure.

## Source-Mapped Facts

- RFC 9449 describes DPoP as an application-level mechanism for sender-constraining OAuth access and refresh tokens. ([source](https://datatracker.ietf.org/doc/html/rfc9449))
- RFC 6750 defines a bearer token as a security token that any party in possession of the token can use. ([source](https://datatracker.ietf.org/doc/html/rfc6750))
- RFC 9700 says sender-constrained tokens can use mutual TLS or DPoP to prevent misuse of stolen access tokens. ([source](https://datatracker.ietf.org/doc/html/rfc9700))

## Further Reading

- [RFC 9449 OAuth DPoP](https://datatracker.ietf.org/doc/html/rfc9449)
- [RFC 6750 OAuth Bearer Token Usage](https://datatracker.ietf.org/doc/html/rfc6750)
- [RFC 9700 OAuth 2.0 Security Best Current Practice](https://datatracker.ietf.org/doc/html/rfc9700)