No explainer written for this spec yet. The summary, relations and documented support below are maintained.
Binds tokens to a key the client holds and proves possession with a signed header on each request, at the application layer.
DPoP
Binds tokens to a key the client holds and proves possession with a signed header on each request, at the application layer.
How it relates to other specs
Relations diagram
flowchart LR s_dpop["DPoP"] s_oauth2["OAuth 2.0"] s_mtls["Mutual-TLS Client Authentication and Certificate-Bound Tokens"] s_wpt["WIMSE Workload Proof Token"] s_fapi2["FAPI 2.0 Security Profile"] style s_dpop stroke-width:3px s_dpop -->|Extends| s_oauth2 s_dpop -.-|Alternative to| s_mtls s_wpt -.-|Alternative to| s_dpop s_fapi2 -->|Builds on| s_dpop
Documented support
Adoption lists only support stated in official documentation (the vendor's or project's own, or a standards body's page naming it), and a weekly check confirms the cited phrase is still on that page. Experimental, alpha and beta support is counted separately as preview.
Products, identity providers and services
- Okta (Identity provider): DPoP sender-constrained access tokens, based on RFC 9449 source (verified 2026-11-11)
- Auth0 (Identity provider): DPoP sender constraining for supported grant types source (verified 2026-11-11)
- Keycloak (Identity provider): DPoP is listed as a supported server feature source (verified 2026-11-11)
Open-source implementations
- Duende IdentityServer (Library): DPoP (RFC 9449) is listed in its supported specifications source (verified 2026-11-11)
Activity
Revisions from the Datatracker, explanations from this site's daily runs, and mailing-list subjects naming the draft.
Nothing collected about this spec yet.