Attempting to revoke an invalid token responds with an error

[JoshNorthrup]

Steps to reproduce

When making a properly formed revocation request (POST /oauth/revoke) with an invalid token, a 403 is returned. This seems to disagree with https://tools.ietf.org/html/rfc7009#section-2.2 which states

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

Expected behavior

Given a properly formed request with an invalid token, TokensController#revoke should respond with 200

[JoshNorthrup]

@nbulaj Thoughts on this? I can put together a PR

[nbulaj]

Hi @JoshNorthrup . I thought we have a proper implementation. Don't we have a specs for it in tests? 🤔

If not - would be great to see a PR! Thanks!
P.S. Sorry, boo busy to review everything

[nbulaj]

Ah, read this please: #1252

Or just 2.1. Revocation Request or original RFC 7009:

The client also includes its authentication credentials as described
in Section 2.3. of [RFC6749].
...
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.

So actually Doorkeeper works as expected:

• authorized? checks if Applications is confidential or not (it's "in case of a confidential client" point from above)
  • if confidential - then it check's authorization and in case it's invalid - informs client with error as stated in RFC
  • if public - authoirzation bypassed
• then Doorkeeper tries to revoke the token (calls revoke_token)
• and renders 200 in any case (revoked or not)

[nbulaj]

Hm, or actually current authorization must be changed and it must be more complex. Let me continue with this tomorrow with a fresh head...

[nbulaj]

Re-reviewed RFC and create a PR to fix the issue @JoshNorthrup , you could check #1370

[nbulaj]

Fixed, thanks @JoshNorthrup