I personally don’t agree with this errata. Token Revocation was never meant to act as a protected resource, but rather as a function of the AS. The client is known to the AS and so authentication is expected here.
— Justin > On Aug 22, 2021, at 5:14 AM, RFC Errata System <rfc-edi...@rfc-editor.org> > wrote: > > The following errata report has been submitted for RFC7009, > "OAuth 2.0 Token Revocation". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6663 > > -------------------------------------- > Type: Technical > Reported by: Ashvin Narayanan <ashvinnaraya...@gmail.com> > > Section: 2.1 > > Original Text > ------------- > 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. > > Corrected Text > -------------- > 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 tok > ens, 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. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7009 (draft-ietf-oauth-revocation-11) > -------------------------------------- > Title : OAuth 2.0 Token Revocation > Publication Date : August 2013 > Author(s) : T. Lodderstedt, Ed., S. Dronia, M. Scurtescu > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
