Section 7 of the DPoP specification [1] says that a "DPoP proof MUST include the ath claim with a valid hash of the associated access token". One reason for that requirement is given in the second paragraph of that section:
> Binding the token value to the proof in this way prevents a proof to be used with multiple different access token values across different requests. The paragraph continues and gives an example of what can go wrong: > For example, if a client holds tokens bound to two different resource owners, AT1 and AT2, and uses the same key when talking to the AS, it's possible that these tokens could be swapped. Without the ath field to bind it, a captured signature applied to AT1 could be replayed with AT2 instead, changing the rights and access of the intended request. This example does not describe how the swapping of access tokens is supposed to happen. Is it reasonable to assume, then, that the same problem could occur with refresh tokens used for a token request by use of some similar swapping mechanism (either forced by some attacker or by accident)? If so, then why does the same requirement, i.e. the inclusion of a refresh token hash in the DPoP-proof JWT payload (perhaps in some "rth" claim), not apply to token requests? For example, say there is a (public) client that holds two refresh tokens that are bound to the same public key but belong to two different resource owners R1 and R2. If the client now makes a token request to refresh R1's access token using R1's refresh token, but that refresh token is somehow swapped for R2's refresh token, then the client associates R1's session with an access token for R2's resources. It seems to me that several arguments that are made for the addition of the "ath" claim could be applied to some "rth" claim as well. [1] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop#section-7 Kind regards Alexander
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
