The direct answer
A DPoP proof must agree with the presented access token, its bound key and the actual protected-resource request. Validate the complete selected protocol, then independently authorize the current object and operation. A valid signature or nonce does not approve a request body, authenticate a trustworthy client, or guarantee a single business effect.
Start at the resource receiver, not the login callback
Invent a notes-reading resource R-A and connector C-A. The connector requests permitted note N-A using token-reference T-A and proof-reference P-1. K-A identifies the expected proof key; U-A identifies the resource target. These are worksheet labels, not a URI, credential, key, proof or HTTP message.
This example covers one RFC 9449 protected-resource receiver over HTTPS. It does not implement token issuance, refresh rotation or an OAuth redirect. A separately trusted access-token validator must establish validity, intended resource, permitted operations and reliable DPoP key-binding information before release. A caller-supplied claim of validation is insufficient.
Choose a DPoP-required route. Do not silently accept a bound token through a bearer-only compatibility path. If deployment support, token evidence or the actual request context is unknown, stop admission rather than trying a looser receiver.
Keep proof validation distinct from access-token validation
RFC 9449 sections 4.3 and 7 require one well-formed proof, required claims, typ=dpop+jwt, an allowed supported asymmetric algorithm, a verifying signature and a public-only jwk. Match htm and htu; verify freshness and any required nonce. For resource access, ath is base64url-encoded SHA-256 of the token's ASCII value, and the proof key must match the token binding.
The proposed receiver treats these as separate gates: proof structure/type, cryptographic verification, trusted token validity/binding, request association and freshness. An issuer signature on an access token is not the proof signature, and decoding either token cannot replace verification. Select and independently review an implementation of the complete standard before deployment; this guide supplies no crypto routine or tested verifier.
Compare the real request, with a defined URI procedure
DPoP compares the target without query or fragment and recommends RFC 3986 syntax- and scheme-based normalization. RFC 3986 sections 6.2.2–6.2.3 distinguish component-specific case rules, unreserved percent-encoding, dot segments and scheme rules. Lowercasing the whole URI or decoding reserved separators indiscriminately is not equivalent.
For R-A, document one normalization/comparison procedure shared with the receiver's actual external-target reconstruction. Trust only deployment-controlled proxy and routing evidence; the proof or an arbitrary forwarded header cannot choose that target. Hold ambiguous rewrites or unavailable reconstruction evidence.
Separately resolve N-A and its current owner through trusted application state. Because query parameters are outside the DPoP target comparison, matching U-A is not approval of a note selector carried there. The same separation applies to a body and other request headers. Keep exact action approval outside this proof gate.
Choose a freshness, replay and nonce policy
RFC 9449 sections 9 and 11.1 define resource-server nonce challenges and discuss bounded proof lifetime and jti tracking. A resource nonce challenge uses 401, a DPoP authentication challenge and DPoP-Nonce; nonce origin matters. A nonce can cover multiple proofs, so it is not a single-use action key.
Our illustrative R-A policy requires its own recent unpredictable nonce and an acceptable creation time. For concreteness, propose an age allowance of 60 seconds and future-clock allowance of 5 seconds. A nonce expires 60 seconds after its recorded server issuance in this proposed profile. These invented choices require deployment review; they are not RFC defaults or measured safe values.
Propose an atomic check-and-record replay decision, rather than a read followed by a later insert, keyed by receiver context, proof-key identity, normalized target and proof identifier. Retain it for every period in which that proof could still be admitted, including allowed skew and nonce validity. All replicas must share the effective decision; unavailable coordination, unknown clock bounds or premature eviction denies admission. No replay store or clock has been tested here.
Eight proposed receiver admission cards
Each card is PROPOSED_UNRUN. Record a case ID, receiver-policy revision, proof/token-binding decision category, request association, replay disposition and current object decision. Do not put reusable tokens, complete proofs, nonce values or customer text into ordinary evidence.
| Invented case | Proposed receiver decision |
|---|---|
| 1. Ordinary permitted read: P-1/T-A/K-A/U-A agree; fresh unused proof, accepted R-A nonce and current N-A rights. | Admit only that authorized read after every real verification gate. This is the intended positive, not a cryptographic observation. |
| 2. Multiple DPoP headers, wrong type, forbidden algorithm or invalid signature. | Deny the selected protocol. Do not search unrelated keys or reinterpret it as a different JWT purpose. |
| 3. Proof verifies under K-B while trusted token evidence binds K-A. | Deny key association; proof possession does not rewrite the access-token binding. |
| 4. Method or normalized target differs from the admitted external request. | Deny association. A familiar host label or client-provided reconstruction cannot repair the mismatch. |
| 5. Proof carries the token-hash label for T-B while T-A is presented. | Deny token association even if the proof key and method match. |
| 6. Creation time is outside policy, identifier was already admitted, or shared replay evidence is unavailable. | Deny under this stricter application policy; do not infer safety from one healthy replica or a nonce alone. |
| 7. Required nonce is absent, stale or issued by another server. | Deny admission and use the selected resource challenge contract as appropriate; never disable nonce checking as a retry repair. |
| 8. Protocol gates pass but N-A rights expired, the query/body asks for something else, or client key use is compromised. | Apply independent object/action checks and record the remaining threat. A valid proof is not evidence of trustworthy intent. |
Keep security claims and business outcomes separate
A fresh proof may still accompany a repeated business request. Do not turn replay admission into an exactly-once operation claim; independent action-state and effect coordination remain necessary. A denied request also does not prove who attempted it.
RFC 9449's security discussion excludes protection against hostile code able to use the client's signing context and does not provide general body/header integrity. Key exposure and XSS remain separate risks, even when a key cannot be exported.
Only documentation was read. No token, proof, key, nonce, header, endpoint, cryptographic verification, network request experiment, store, clock or model call was created or exercised. Boundary is prelaunch; its planned request policies and separate synthetic action demo do not implement this DPoP receiver.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.