Hi Torsten, Thanks for your insight. I agree, a sender constraint token, such as when using certificate bound tokens from RFC 8705, cannot be used by an attacker. It makes sense to only allow the owner to revoke them, probably using the same mechanism as by which they are bound to the client. For bearer tokens, we will simply skip the validation of the client credentials.
Best regards, Emond Papegaaij On Thu, Aug 20, 2020 at 12:52 PM Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > > Hi Emond, > > I tend to agree with your assessment. Revoking bearer tokens without client > authentication seems to be better than leaving the attacker the option to use > them to invoke resources. > > However, if the attacker cannot use the access tokens (e.g. because they are > sender constrained), the attacker could revoke tokens issued to a > confidential client as a kind of DoS attack. > > best regards, > Torsten. > > > On 20. Aug 2020, at 11:02, Emond Papegaaij <emond.papega...@gmail.com> > > wrote: > > > > Hi all, > > > > We are currently implementing the token revocation endpoint (RFC 7009) > > on our authorization server and do not understand why it requires > > client authentication. When a party (a valid client or not) gets hold > > of a valid access token in whatever way, the least damaging it could > > do with it, is to revoke it. The current spec allows an attacker to > > misuse this token for access to the resource server, but forbids it to > > revoke it. This seems strange to me. > > > > Section 5 of RFC 7009 does not help in this either. It starts to > > explain that this authentication is needed to prevent malicious > > clients from guessing tokens, but ends with the fact that if this were > > possible, much worse damage could be done by using the guessed token > > on the resource server. We plan to skip the authentication all > > together and simply revoke any valid token presented. How would you > > recommend we deal with this? > > > > Best regards, > > Emond Papegaaij > > Topicus KeyHub > > > > _______________________________________________ > > 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
