Here is my review of the Toke Revocation draft (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
Section 1. Introduction First paragraph has the following definition in it: "A token is the external representation of an access grant issued by a resource owner to a particular client." This seems a bit odd to me. The OAuth2 spec [1] defines "access token" as "An access token is a string representing an authorization issued to the client." (section 1.4) and "refresh token" as "credentials used to obtain access tokens (section 1.5). Should this spec borrow similar language to be more consistent? Paragraph 2 "From an end-user's perception" should be "From an end-user's perspective". Section 2. Token Revocation What is the reason for requiring the service provider to detect the token type automatically? For our implementation, Access Tokens, Refresh Tokens, and ID Tokens are all structured tokens (with unique structures across the three types), and as such are stored in 3 separate database tables. In order to "detect" the token type, we would need to run a get-by-value query across all three tables, check if any of those queries returned anything, and then proceed to revoke the token (if one was found). This does not seem ideal to me. The spec says that "The authorization server first validates the client credentials (in case of a confidential client) and verifies whether the client is authorized to revoke the particular token." What does this verification entail? Does it just mean that 1) the client credentials must validate and 2) the token must belong to the client requesting the revocation? If so I think the text should be clarified to reflect that. Or are you thinking of a case where a client might not be allowed to revoke its own tokens, via some kind of scoping? 2.1 Cross Origin Support Formatting looks a little off here, otherwise this section looks fine. 5. Security Considerations Paragraph 3 (Malicious clients…): "Appropriate countermeasures, which should be in place for the token endpoint as well, MUST be applied to the revocation endpoint." These countermeasures should be referenced to the proper section(s) of the OAuth core spec or Threat Model document. Paragraph 4 reads a bit oddly. Suggest following rewording: "A malicious client may attempt to guess valid tokens on this endpoint by making revocation requests against potential token strings. According to this specification, a client's request must contain a valid client_id, in the case of a public client, or valid client credentials, in the case of a confidential client. The token being revoked must also belong to the requesting client. 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 and will need to prompt the user again. No further damage is done and the guessed token is now worthless." References: [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31 -- Amanda Anganes Info Sys Engineer, G061 The MITRE Corporation 781-271-3103 aanga...@mitre.org
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
