I'm a big fan of not arbitrarily adding security to paths that don't require it. The more complicated it is to do what you want without a concrete reason, the more likely there will be an introduced vulnerability.
Consistency on adding requirements to endpoints that don't need it also makes them harder to use. In this case, I challenge that if the attacker could intercept login to get both a valid token and steal the DPoP key, that preventing refresh token revocation is meaningless. Being able to revoke the refresh token doesn't decrease the vulnerable surface, so adding protections there is unwise. I'm not saying it is defined on all the necessary endpoints already, but let's be deliberate on which ones get it. On Thu, Feb 10, 2022, 01:19 Dmitry Telegin <dmitryt= 40backbase....@dmarc.ietf.org> wrote: > Could we perhaps be a little bit more specific on the relationship between > DPoP and OAuth 2.0 Token Revocation (RFC 7009)? > > I believe that if we constrain *some* token lifecycle events (issuance, > refresh), we should constrain *all*, revocation included (please correct > me if I'm wrong). > > There seem to be no direct attack vectors here, but indirect ones might be > possible. For example, by revoking an exfiltrated refresh token, thus > killing the session, the attacker could force the user to reauthenticate at > the moment the attacker would be ready to steal credentials. > > Dmitry > Backbase / Keycloak > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
