Check the signature before trusting the note
02The app writes a small note about this request and signs it using its secret key. A public key checks the signature; reading the note is not checking it.
The selected public fixture names POST at the issuer’s token endpoint. It is not an access token.
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.
This checks the signed bytes with the included public key. It is separate from header-count, request, time, nonce and token checks.
The one proof has the required type and an allowed public-key signature. The remaining request/time/token checks still have separate jobs.
Key idea: A valid signature is necessary, but the proof also has to follow the DPoP rules.
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
A valid signature is necessary, but the proof also has to follow the DPoP rules.
These reference examples may differ from the selected experiment.
- There must not be more than one DPoP header. Its value must be a single well-formed JWT with all required claims.
- typ must be dpop+jwt. alg must be a supported, locally acceptable registered asymmetric signing algorithm, never none or a symmetric MAC algorithm. The public jwk must not contain a private key.
- The complete proof includes method, target URI, creation time and a suitably unique identifier; token use adds ath, and a supplied server nonce adds nonce. The browser exercise checks a public ES256 signature fixture, not all production JWT/TLS requirements.
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.