3

In RFC7009 - section 2.1, it is stated that:

The authorization server first validates the client credentials (in case of a confidential client) and then verifies whether the token was issued to the client making the revocation request. If this validation fails, the request is refused and the client is informed of the error by the authorization server as described below.

And then in section 2.2

The authorization server responds with HTTP status code 200 if the token has been revoked successfully or if the client submitted an invalid token.

Returning an error in this case (and not the standard 200 HTTP status) would leak to another client that the token exists and is actually valid, which seems to me a security flaw, even though scanning for tokens is hard (but not impossible) if tokens are generated with enough entropy.

What do you think?

Improve this question
3
  • I don't see why this calls for different responses depending on whether or not the token exists. If it exists and has been issued by the requesting client, return OK. Otherwise don't. You don't have to distinguish between "token doesn't exist at all" and "token exists but has been issued to another client".
    – Peter
    May 22 '19 at 16:10
  • No, according to the specification it's like: if the token exists and was issued to the client: return HTTP 200 if the token doesn't exist: return HTTP 200 if the token does exist, but was issued to another client: return an error (which one - it's unclear)
    – Tangui
    May 22 '19 at 16:20
  • 2
    The paragraph you quoted doesn't say that, but it is indeed clarified in Section 2.2.
    – Peter
    May 22 '19 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.