Implement OAuth 2.0 DPoP (RFC 9449) sender-constrained tokens end to end

Verified steps

1. Generate an asymmetric key pair (ES256 or RS256) in the client at startup or per session; this key is the DPoP key — never reuse it across users
2. For each request to the authorization server's token endpoint, create a DPoP proof JWT: header {typ: 'dpop+jwt', alg, jwk (public key)}, payload {jti (unique per proof), htm (HTTP method), htu (URL without query), iat, nonce if required}
3. Send the proof as a DPoP header in the token request; the AS validates the proof and issues a token with a cnf.jkt claim containing the SHA-256 thumbprint of the DPoP public key
4. For API requests, include both the Bearer/DPoP access token (Authorization: DPoP <token>) and a new DPoP proof JWT with ath (hash of the access token) in the payload
5. Handle the DPoP nonce challenge: if the AS returns a use_dpop_nonce error with a DPoP-Nonce header, retry the request including the nonce in the proof JWT payload
6. At the resource server, verify the DPoP proof signature, check that htm/htu match the current request, validate iat recency (max ~60 seconds), confirm the access token's cnf.jkt matches the JWK thumbprint in the proof