Found 1 record.

Status: Reported (1)

RFC 7009, "OAuth 2.0 Token Revocation", August 2013

Errata ID: 6663
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ashvin Narayanan
Date Reported: 2021-08-22

Section 2.1 says:

The client constructs the request by including the following
   parameters using the "application/x-www-form-urlencoded" format in
   the HTTP request entity-body:

   token   REQUIRED.  The token that the client wants to get revoked.

   token_type_hint  OPTIONAL.  A hint about the type of the token
           submitted for revocation.  Clients MAY pass this parameter in
           order to help the authorization server to optimize the token
           lookup.  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.  This specification defines two
           such values:

           * access_token: An access token as defined in [RFC6749],
             Section 1.4

           * refresh_token: A refresh token as defined in [RFC6749],
             Section 1.5

           Specific implementations, profiles, and extensions of this
           specification MAY define other values for this parameter
           using the registry defined in Section 4.1.2.

   The client also includes its authentication credentials as described
   in Section 2.3. of [RFC6749].

   For example, a client may request the revocation of a refresh token
   with the following request:

     POST /revoke HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

     token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token

   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.

It should say:

The client calls the revocation endpoint using an HTTP
   POST [RFC7231] request with the following parameters sent as
   "application/x-www-form-urlencoded" data in the request body:

   token   REQUIRED.  The token that the client wants to get revoked.

   token_type_hint  OPTIONAL.  A hint about the type of the token
           submitted for revocation.  Clients MAY pass this parameter in
           order to help the authorization server to optimize the token
           lookup.  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.  This specification defines two
           such values:

           * access_token: An access token as defined in [RFC6749],
             Section 1.4

           * refresh_token: A refresh token as defined in [RFC6749],
             Section 1.5

           Specific implementations, profiles, and extensions of this
           specification MAY define other values for this parameter
           using the registry defined in Section 4.1.2.

   The client MUST also include in the request, the access token it received 
   from the authorization server. It must do so in the same way as it  would  
   when accessing a protected resource, as describe in [RFC6749], Section 7.

   The following is a non-normative example request in which the client uses 
   its access token to revoke the associated refresh token:

     POST /revoke HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW

     token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token

   The following is a non-normative example request in which the client uses 
   its access token to revoke the same access token:

     POST /revoke HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW

     token=czZCaGRSa3F0MzpnWDFmQmF0M2JW&token_type_hint=access_token

   The authorization server MUST validate the access token used by the        
   client to authorize its call to the revocation endpoint, including 
   ensuring that it is not expired or revoked. 
   Additionally, the authorization server MUST also validate whether the
   access token used for authorization is part of the same grant  as the 
   token being revoked. If validation fails, the request is  refused and 
   the client is informed of the error by the authorization server. 
   In the case of a bearer token, the authorization server SHOULD respond  
   with an HTTP 401 code as described in OAuth 2.0 Bearer Token Usage 
   [RFC6750], Section 3. 
   Errors based on other types of tokens are beyond the scope of this 
   specification.
    

Notes:

It appears as though the authors of RFC7009 have failed to consider that requests to revoke are likely to come from non-confidential clients and such, would lack authentication credentials. Regardless of the type of client however, authentication should not be required. The OAuth 2.0 specification (RFC6749) does not specify verifying that the access token belongs to the client accessing protected resources, of which revocation is one. It is the role of the access token alone to signify authorization required to make requests to protected resources. If this is an issue for revocation, then it is an issue for all protected resources and counter measures may be proposed in a separate RFC rather than broadening the scope of this particular RFC. As per the original text itself, "This specification in general does not intend to provide countermeasures against token theft and abuse." Additionally, "If an attacker is able to successfully guess a public client's client_id and one of their tokens, or a private client's credentials and one of their tokens, they could do much worse damage by using the token elsewhere than by revoking it. If they chose to revoke the token, the legitimate client will lose its authorization grant and will need to prompt the user again. No further damage is done and the guessed token is now worthless."
Note that the client_id is not meant to be private information to begin with, so relying on an attacker "guessing" it should not be seen as a security countermeasure. This section of RFC7009 will be referenced in a subsequent errata.

Report New Errata