Keep the same key from permission request to token
09An optional early key fingerprint can clip the permission request’s code to the app’s key before the app redeems that code for a token.
The example assumes ordinary OAuth permission, PKCE and client checks pass.
Offline worked example. Signature fixtures and key/token hashes can be checked locally; ordinary OAuth, TLS and deployment policy checks remain separate. This is not a production validator.
What happens if you change this?
Predict whether the request will pass. Change one choice to see why; use Restart to restore the original example.
The early fingerprint and later proof refer to the same key A. This check complements the rest of OAuth and PKCE.
Key idea: An early code-to-key binding stops a later request using a different key.
Terms
- DPoP
- A separately signed note proving use of a key for a particular request. It accompanies, rather than replaces, the access token.
- Public key and private key
- The shareable key checks signatures. The matching secret key makes them. A public key is not a registered app identity by itself.
Rules & examples
An early code-to-key binding stops a later request using a different key.
These reference examples may differ from the selected experiment.
- dpop_jkt optionally binds an authorization code to the SHA-256 JWK thumbprint, checked against the later token-request proof. A mismatch MUST be rejected.
- With PAR, use dpop_jkt in the POST body or a checked DPoP proof header. Servers supporting PAR and DPoP MUST support both approaches. If both are supplied, their key thumbprints MUST agree; otherwise reject the pushed request before issuing a code.
- dpop_jkt complements PKCE; it is not an unconditional replacement. Similar injection protection requires a unique DPoP key per authorization request. This model assumes all other OAuth/PKCE checks pass.
Bounded offline worked example, not a production OAuth, TLS or general JWT validator. Cryptographic signature fixtures and public-key/token hashes are independently checked.
Sources
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.