Unknown token_type_hint should be ignored

[rozagerardo]

Describe the bug
IMO we're using the unsupported_token_type response wrongly. Currently, we're retrieving this error response if we pass a token_type_hint request parameter value different to access_token or refresh_token. As I understand the specs, the Authorization Server should just ignore the token_type_hint param if it doesn't match the token type:

If the server is unable to locate the token using the given hint, it MUST extend its search across all of its supported token types. An authorization server MAY ignore this parameter, particularly if it is able to detect the token type automatically.

---

An invalid token type hint value is ignored by the authorization server and does not influence the revocation response.

Furthermore, the unsupported_token_type error response should be used only if the authorization server explicitly doesn't allow revoking a particular token type:

unsupported_token_type: The authorization server does not support the revocation of the presented token type. That is, the client tried to revoke an access token on a server not supporting this feature.

Also note that this is not really related to the token_type_hint parameter, for example, we could pass a refresh_token as token_type_hint request parameter, but find that the token actually corresponds to an access_token. At that point, if the server is configured not to revoke access_tokens, then it would retrieve the corresponding error response.

To Reproduce
Send a request as follows:

curl --location --request POST 'http://localhost:9000/oauth2/revoke' \
--header 'Authorization: Basic bWVzc2FnaW5nLWNsaWVudDpzZWNyZXQ=' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'token=<token>' \
--data-urlencode 'token_type_hint=whatever'

Server responds with 400 Bad Request:

{
    "error": "unsupported_token_type"
}

Expected behavior
Token should be revoked anyway, and the service should respond with 200 OK.

[jgrandja]

Thanks for the report @rozagerardo ! This is now fixed via 7f8aff7