2026-09-01 · 8 min read
- jwt
- oauth
- security
DPoP sender-constrains OAuth tokens by requiring a client to sign a fresh JWT proof for an HTTP request. The proof binds a public key, method, target URI, issued-at time, and unique identifier; a resource server can then require the access token to reference the same key.
This reduces the usefulness of a stolen token, but only when proof validation is strict and consistent across token endpoints, resource servers, gateways, and retries. Decoding the proof is diagnostic; cryptographic verification and replay controls belong on trusted servers.
Validate the protected header and signature
Require the DPoP JWT type and an asymmetric algorithm allowed by policy. Validate the signature with the public JWK carried in the protected header, reject private key material and unsupported key parameters, then calculate its standards-defined thumbprint.
- Never accept a symmetric proof algorithm.
- Apply key type, curve, and strength requirements.
- Reject unsupported critical header parameters.
- Bind the thumbprint to the access token cnf claim.
Bind each proof to one request
Compare htm with the actual HTTP method and htu with the normalized target URI form required by the profile. Query and fragment handling is defined by the protocol; do not improvise canonicalization or compare a browser display string.
Validate iat within a short configured window and store jti values long enough to prevent replay within that window. For token-bound resource requests, validate the access-token hash claim when the selected profile requires it.
Handle nonces and proxies deliberately
A server can challenge the client with a nonce. The retry must contain the latest nonce in a newly signed proof with a fresh jti; clients should cap challenge loops and handle concurrent nonce updates predictably.
- Reconstruct the public URI from a fixed trusted-proxy configuration.
- Ignore forwarded headers received from untrusted network paths.
- Define default-port and host normalization consistently.
- Preserve method and destination across authorized retries and redirects.
Create interoperable fixtures
Use Flashman's JWT tool for synthetic proof inspection, URL tool for URI components, timestamp converter for iat windows, hash tool for public-key thumbprint fixtures, and JSON formatter for redacted error metadata. Never paste active access tokens into shared tools or tickets.
Test valid proofs, wrong method or URI, direct and proxied requests, clock boundaries, duplicate jti, nonce rotation, key and cnf mismatch, unsupported algorithms, redirects, default ports, malformed JWKs, and concurrent client retries.