Subject: [OAUTH-WG] Token Revocation (was: Re-Chartering: What Items to work on?)

From: Marius Scurtescu <[email-masked]>
Date: Wed, 2 Feb 2011 17:01:58 -0800

Following up on the Token Revocation extension proposed at:
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/

I am suggesting three changes to this extension:

1. Either drop client authentication or make it optional. If clients
want to revoke tokens, more power to them. If it is a malicious
client, why would the authorization server deny revoking tokens?

2. Can we drop the "token_type" parameter, as suggested before?

3. "authorization server MUST also invalidate all access tokens issued
for that refresh token." can we change this MUST to a SHOULD?

In case of success, why is the server supposed to return 204 instead
of 200? Just worried that this will confuse clients.

Thanks,
Marius

On Thu, Jan 13, 2011 at 8:39 AM, Marius Scurtescu <[email-masked]> wrote:
> On Wed, Jan 12, 2011 at 4:31 PM, Torsten Lodderstedt
> <[email-masked]> wrote:
>> Am 12.01.2011 22:19, schrieb Richer, Justin P.:
>>>
>>> Yes, let the server do the work. In practice, it's going to be looking up
>>> the token based on the token value anyway (for bearer tokens, at least). All
>>> the client really cares about is asking to "revoke this token that I am
>>> sending you". If the client credentials and token are correct and
>>> verifiable, then the revoke should go through.
>>
>> What do others think?
>
> I agree with Justin's suggestion, let the server figure the token
> type. The server should be able to do that anyhow.
>
>
>>> A client wanting to revoke both a request token and an access token will
>>> have to make several calls to this, unless you want to put in a way to put
>>> multiple token values in. I don't recommend that though, as it seems to me
>>> an optimization for a problem nobody has yet.
>>
>> the token_type does not control whether the server deletes all access tokens
>> associated with a refresh token.
>>
>> This depends on the authorization servers policy.
>
> There are cases when the server cannot revoke the access tokens
> associated with a refresh token (static access tokens for example).
> That being said, I think the server SHOULD revoke all access tokens if
> possible.
>
>
> Marius
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 26 Feb 2011 14:16:10 +0100

thank you for your feedback.

> client, why would the authorization server deny revoking tokens?

The impact of an unauthorized revocation is merely inconvenience since 
the client has the go through the authorization process again. 
Nevertheless, I would like to add some protection here.
My suggestion: the authorization server should require authentication 
for clients having such credentials.

> 2. Can we drop the "token_type" parameter, as suggested before?

yes, we can. I will modify this in the next revision of the I-D.

> for that refresh token." can we change this MUST to a SHOULD?

Why? The server is only required to revoke the access tokens if it is 
capable to do so.

> of 200? Just worried that this will confuse clients.

because there is no response body (required). I'm open to change it to 
200 but what data shall be contained in the response?

regards,
Torsten.

> Thanks,
> Marius
>
>
>
> On Thu, Jan 13, 2011 at 8:39 AM, Marius Scurtescu<[email-masked]>  wrote:

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 28 Feb 2011 10:35:32 -0800

On Sat, Feb 26, 2011 at 5:16 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> The impact of an unauthorized revocation is merely inconvenience since the
> client has the go through the authorization process again. Nevertheless, I
> would like to add some protection here.

If this inconvenience is done on purpose then the token is in the
wrong hands. In which case you really want this token revoked, why
would you make that more difficult?

If the inconvenience is some error, then it will happen with or
without credentials.

I think client authentication should be optional at best.

> My suggestion: the authorization server should require authentication for
> clients having such credentials.
>

Great, thanks.

> Why? The server is only required to revoke the access tokens if it is

Because it could be expensive, or impossible, for the authorization
server to track down all access tokens associated with a refresh
token.

> because there is no response body (required). I'm open to change it to 200
> but what data shall be contained in the response?

An empty response body with 200 is illegal?

A couple more suggestions:

1. Allow GET requests as well. This helps JavaScript clients.

2. Allow JSONP requests, for JavaScript clients as well.

Marius