I recently wrote a sentence I need to correct: “DPoP stops replay. The gap most teams miss is revocation lag once the token walked.” The second half points at a real problem. The first half is too loose. If only the token walked, a correctly implemented DPoP flow should make it useless to the thief. The harder problem begins when the attacker has the token and its proof key, can execute inside the client process, controls the device, or is already riding the live session. At that point the question is no longer who holds the token. It is how quickly the whole system can stop honoring its authority.
This distinction matters because token theft and stale authority are separate security axes. Sender-constraining makes a credential harder to carry away. Revocation is what happens after the credential, client or underlying decision can no longer be trusted. One mechanism limits portability. The other has to change reality across a distributed system.
A token can be cryptographically valid and operationally unauthorized.
First, what DPoP actually buys
A bearer token works like cash: whoever presents it can spend it. The resource server validates the signature, issuer, audience, expiry and scope, but it does not know whether the presenter is the client to which the token was issued. A token copied from a log, browser, proxy or telemetry pipeline can be replayed from another machine.
