I’ve been reading Identity, Unlocked... Explained | Episode 1.
The problem statement was that access tokens, when stolen, can be used by an attacker freely (within the validity time of the token).
To prevent that, one of the solutions is to use a DPoP proof - another JWT that would be sent to the Resource Server together with an access token to prove that the caller is the right entity.
However, I don’t understand how it fixes the initial problem. Initially, we were worried what happens if someone steals an access token. Now, didn’t we just change the problem into “what happens if someone steals a pair of access token and dpop proof”?
As I understand it, if I somehow possess someone’s pair of access token and dpop, I can use it freely.
Hi there! Capturing AT and DPOP proof only allows repeating the exact same call, as soon as HTTP method and URI change (as it is common in REST API) the DPOP proof is no longer usable and cannot be replayed. Compare this with classic bearer use of an AT, where holding the AT allows calling the API with no limitations.
See draft-ietf-oauth-dpop-13 for more details about the choice of focusing on HTTP method and URI, and how to add extra elements in case the scenario calls for it. draft-ietf-oauth-dpop-13
