Keep replacement tokens tied to the right holder
08When 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.
The public refresh token is bound to the original DPoP key A.
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 refresh-request proof passes, and the issuer returns token_type=DPoP. All ordinary refresh and separate client-login checks are assumed passed.
Key idea: A protected refresh token does not automatically make its replacement access token DPoP-protected.
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 protected refresh token does not automatically make its replacement access token DPoP-protected.
These reference examples may differ from the selected experiment.
- A public client’s refresh token issued after a valid DPoP proof MUST be bound to that public key, and later refresh requests MUST prove the same key.
- Confidential-client refresh tokens are already constrained by client_id and required client authentication; this RFC does not bind them to the DPoP key. This example assumes the separate client authentication and all ordinary refresh checks succeed.
- An issuer MAY reply token_type=Bearer instead of DPoP, while a public refresh token remains bound. An app that deems DPoP access-token protection important MUST discard a non-DPoP response.
- dpop_signing_alg_values_supported advertises signing algorithms. Client metadata dpop_bound_access_tokens defaults false; if true, the issuer MUST reject token requests missing the DPoP header.
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.