An early draft of the revocation spec had this token type field, for
this purpose. From an early conversation on the list with Torsten, we
decided that most of the time it didn't matter, as different classes of
token would be recognizable as different by the AS. In some
implementations (like ours), this means checking different token stores
in parallel for a given token value. In other implementations, they can
key on something in the token to make the search more simple.
But one of the reasons behind not having a "token type" parameter any
more is that OAuth core defines two token classes: access and refresh.
OpenID Connect adds another type, the id token. UMA adds a whole range
of other types, from host access tokens and onward. Even dynamic
registration adds a new class, the registration access token. So the
problem is how do we manage all of these classes? Right now, the answer
is "punt" by not having the field and putting the weight on the AS. But
maybe we can revisit this decision with a bit more deployment experience.
The way I see it, we've got a few options:
1) Leave it as-is, with no field. Client/RS/whoever just sends the token
over and it's the AS's problem.
2) Define a required field with "access" and "refresh" value semantics,
and state that other values MAY be accepted by a given AS, or defined by
extension protocols. These extension values MUST be fully qualified URIs.
3) Same as #2, but with IANA registry to allow for non-collision of
short names.
4) Define an optional field that the client MAY send as a hint to the
AS, and it's up to the AS to figure out if it makes any sense in the
context of the request. All bets are off as to the content of this
field, other than "it's a string".
There may be other approaches as well.
-- Justin
On 11/30/2012 04:28 PM, Anganes, Amanda L wrote:
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
