Hi Dmitry, Sender-constrained access tokens via Client certificate (MTLS) likewise do not require mtls to be used for revocation or introspection (unless it's for client authentication).
- Filip On Thu, 10 Feb 2022 at 09:08, Warren Parad <wparad= [email protected]> wrote: > 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= > [email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
