See where the protection ends
10Try a stolen token, a stolen key or malicious code inside the app. A key-bound note narrows one attack, but cannot turn a compromised app into a trustworthy one.
Assume the token itself has the permissions needed in the worked example.
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.
A token alone cannot supply the matching key proof at a DPoP-aware service.
Key idea: DPoP constrains token use; it is not encryption, client identity or a cure for hostile code.
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
DPoP constrains token use; it is not encryption, client identity or a cure for hostile code.
These reference examples may differ from the selected experiment.
- Non-exportable keys stop extraction of the key, but malicious code in the client context can still use it to make proofs. Defending against XSS remains necessary.
- A DPoP-aware resource supporting Bearer and DPoP MUST reject a DPoP-bound token received as Bearer. A legacy DPoP-unaware service may accept it without enforcing binding, losing that protection.
- DPoP does not protect general request headers or body integrity and MUST be used with HTTPS. A matching proof is not a substitute for token issuer, time, audience, permission and application checks.
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.