DPoP is not satisfied merely because a request carries a signed proof. The proof must be signed by the key bound to the access token. That distinction matters because a client can produce a perfectly structured proof with a different key and still be presenting the wrong proof for that token.
This article is about a concrete QA observation of that control. It is not a claim of a newly shipped fix or a production finding.
The problem: possession of some key is not enough
Use two symbolic keys: keyA and keyB. Suppose a token was issued with a binding to keyA. A client then sends that token with a DPoP proof created and signed using keyB. The request has a DPoP header, and the proof may be cryptographically well-formed, but it does not demonstrate possession of the key associated with the token.
If a resource server accepted that combination, the token’s proof-of-possession boundary would be weakened. The relevant question is not only “is there a proof?” but also “is this the proof made with the token’s bound key?”
What the recorded QA did
The recorded QA first established a signed-in appointment-listing baseline: the same appointments.list POST returned HTTP 200. That successful response is useful context, but it is not the key-binding result by itself.
A missing-proof negative control sent the token without a DPoP proof and received HTTP 401 with invalid_dpop_proof and the description, “A single DPoP header is required.” This shows that the endpoint rejected the absence of the required proof.
The key-binding case then generated an independent EC P-256 key, represented here as keyB, and called the same listing action with the token. The test code supplied that second key as the DPoP JWK. The service returned HTTP 401 with invalid_dpop_proof and the specific description, “The proof's key is not the key this token is bound to.” That is the important observation: the client generated and signed a proof with a second key, and the service rejected the mismatch.
The evidence does not establish an internal validation order, nor does it claim that signature verification independently passed as a separately observed stage. It records the externally visible enforcement result.
The working control
The observed control is token-to-proof key binding. A valid request needs more than a DPoP-shaped header: the proof key must correspond to the key for which the token was issued. The missing-proof case and the wrong-key case are complementary regression checks. The first catches an absent proof; the second catches a proof that is present but bound to the wrong key.
This is deliberately not a replay analysis; replay behavior is a separate concern. It is also not an owner-authorization test. A request can use the correct proof key and still require independent authorization checks for the resource.
RFC 9449 section 4.3 describes resource-server validation of a DPoP proof, including matching the proof key to the key bound to the access token. RFC 9449 section 7.1 explains the sender-constraining model. The proof protects the request context; it does not mean the request body is signed.
Bounded lesson
When testing DPoP enforcement, keep a known-good 200 baseline, a missing-proof negative control, and a wrong-proof-key case. The strongest result is not a generic “401”; it is a refusal that identifies the token/proof key mismatch. That is what the recorded QA verified: an existing control rejected keyB when the token was bound to keyA.
Disclosure: This article is published by the Allowfy team. AI-generated from recorded Allowfy QA observations and RFC 9449 references. The evidence was limited to the cited sandbox/source excerpts; no private key material or production claims are included, and no human authorship is implied.
Top comments (0)