Answer the right server’s fresh challenge
07A server can send an unpredictable value for the app to echo inside its next signed proof. Keep the token issuer’s value separate from the picture service’s value.
All other proof checks are assumed passed. Fictional nonce labels are readable teaching values, not secure random nonce generation.
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 app copies this server’s opaque value into a fresh signed proof. Its jti is new; the nonce itself need not be single-use.
Key idea: Once a server supplies a DPoP nonce, do not drop it or borrow another server’s value.
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
Once a server supplies a DPoP nonce, do not drop it or borrow another server’s value.
These reference examples may differ from the selected experiment.
- Verified editorial erratum 7646 corrects authentication server to authorization server in §4.2. The issuer returns HTTP400 use_dpop_nonce with DPoP-Nonce when requiring a nonce; the resource server uses HTTP401 with a DPoP WWW-Authenticate challenge.
- No more than one DPoP-Nonce response header is allowed. Clients use a recently supplied value and must use a replacement supplied in a successful response for following requests until another is supplied. Responses carrying it should be uncacheable.
- A nonce is opaque and server-specific; it need not change on every request. A server MUST NOT accept a proof omitting nonce after providing one. For browser cross-origin use, DPoP-Nonce and needed WWW-Authenticate response headers must be exposed, in addition to the rest of the required CORS configuration.
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.