The client generates a key pair (usually ES256), sends a DPoP header containing a JWT with typ dpop+jwt, the public key in the jwk header, and claims jti, htm (HTTP method), htu (URL without query and fragment), iat and, when presenting an access token, ath (its SHA-256 hash). The authorization server binds the issued token to the key's thumbprint (cnf.jkt), and resource servers check the proof on every call; servers can demand a server-supplied nonce to limit pre-computed proofs.
DPoP works at the application layer, so it survives TLS-terminating proxies and suits browsers and mobile apps, unlike mTLS-bound tokens (RFC 8705). Resource servers must check jti uniqueness within a short window, the method and URL, and that the proof key matches the token. The DPoP inspector validates a proof and its token binding.