Subject: [OAUTH-WG] Client authentication on token revocation

From: Emond Papegaaij <[email-masked]>
Date: Thu, 20 Aug 2020 11:02:12 +0200

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 20 Aug 2020 12:52:19 +0200

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 <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Emond Papegaaij <[email-masked]>
Date: Thu, 20 Aug 2020 14:18:11 +0200

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