RFC 9449 / START HERE
DPoP key-bound tokens, before the details
DPoP means Demonstrating Proof of Possession. It adds a signed request note to OAuth, the framework apps use to obtain permission to use a service.
An access token is a permission note. The app keeps a secret private key and shows its shareable public key. A DPoP-aware service asks for a separately signed proof tied to the token and this request, so copying the token alone is not enough.
Why it exists
Ordinary bearer tokens can be used by whoever holds them. RFC9449 defines application-level proof, key and token bindings, freshness checks and optional server challenges. It complements HTTPS and ordinary OAuth checks; it does not identify a registered app by itself or sign every request byte.
A familiar example
A photo app gets permission to fetch pictures. A copier takes its token but cannot make the matching key proof. Changing a destination needs a new proof; replacing a token changes its signed token hash. Malicious code inside the app may still misuse its signing key, even if the key cannot be exported.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- A copied permission note should not open the doorA photo app wants to fetch pictures. Someone copies its permission note. See why a separate, freshly signed request matters.→
- Check the signature before trusting the noteThe 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.→
- Tie the permission note to a public keyThe issuer attaches a short fingerprint of the app’s public key to its token. Changing an optional key label should not change the key’s identity.→
- Match both the key and the permission noteThe picture service receives a token and a signed proof. Check which key signed it and exactly which token the proof names.→
- Which changes does this signed note notice?A proof names an action and a destination. Change one part of a request to see what that small note covers, and what HTTPS must still protect.→
- Notice an old note or a repeated identifierThe server checks when a proof was made. It can also remember identifiers it has already accepted, so a copied proof cannot simply be used twice.→
- Answer the right server’s fresh challengeA 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.→
- Keep replacement tokens tied to the right holderWhen a token expires, the app may bring a refresh token to the issuer for a replacement. Public and confidential clients have different refresh-binding rules.→
- Keep the same key from permission request to tokenAn 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.→
- See where the protection endsTry 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.→
This introduction explains RFC 9449 (2023). Read the original RFC ↗