DPoP (RFC 9449)

DPoP fixes a real weakness in how most OAuth 2.0 tokens work: an ordinary access token is a bearer token, whoever holds the string gets to use it, full stop, with nothing checked about whether they're the party it was originally issued to (see Bearer Token). Steal one out of a log file, a proxy, or a leaky browser extension, and it works exactly as well for the thief as for the legitimate holder, until it expires.

DPoP, "Demonstrating Proof-of-Possession", closes that gap without requiring the heavier machinery of mutual TLS. The client generates its own public/private key pair, and attaches a fresh, self-signed DPoP proof, a small JWT, to every request. That proof states the HTTP method and URL being called (htm, htu), a timestamp, a one-time-use ID (jti), and the client's own public key. When the authorization server issues an access token to that client, it binds the token to the proof's public key by embedding a hash of it, a cnf.jkt claim, inside the token itself. From then on, a resource server checking that token has to also see a fresh, valid DPoP proof, signed by the same key, before accepting the request. A stolen access token, presented without the matching private key, is worthless.

Where it comes from

DPoP is RFC 9449, published by the IETF OAuth Working Group in September 2023, genuinely recent, as internet standards go. Its authors, including Daniel Fett, Brian Campbell, John Bradley, Takahiko Kawasaki, and Aaron Parecki, come out of the same OAuth security community that spent years documenting the class of token-theft and replay attacks DPoP is designed to close (much of that documented in the OAuth 2.0 Security Best Current Practice). Solidus designed none of it.

Solidus today

auth.solidus.network implements RFC 9449 end to end for its Solid-OIDC flow: proof verification checks the signature, the htm/htu binding, a freshness window, and rejects replayed jti values via a replay guard; successful verification mints an ES256-signed access token, and, for offline_access, a DPoP-bound refresh token, carrying the client's key thumbprint in cnf.jkt. This is real, tested code (RFC section numbers are cited directly in the source comments), not a stub. What it isn't yet: universal. Solidus's other OAuth clients, the ones not doing Solid-OIDC, still get ordinary Bearer Tokens today. All of it sits on Solidus's public testnet, unaudited.

See also

OIDC and Solid-OIDC are the protocols DPoP is layered onto here. JWT is the token format a DPoP proof itself is written in. Bearer Token is the weaker default DPoP is an upgrade over. Refresh Token covers the DPoP-bound refresh variant.