Re: [OAUTH-WG] A question on token revocation.

[Prabath Siriwardena <[e-mail]>]

On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer <[e-mail]> wrote:

>
> On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:
>
>
>
> On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <[e-mail]> wrote:
>
>>  These are generally handled through a user interface where the RO is
>> authenticated directly to the AS, and there's not much need for a
>> "protocol" here, in practice.
>>
>
>  Why do you think leaving access token revocation by RO to a proprietary
> API is a good practice ? IMO this an essential requirement in API security.
>
> I think it makes more sense in the same way that having a "proprietary"
> UI/API for managing the user consent makes sense: unless you're doing a
> fully dynamic end-to-end system like UMA, then there's not much value in
> trying to squeeze disparate systems into the same mold, since they won't be
> talking to each other anyway.
>

This is required in distributed setup for each API platform from different
vendors to perform in an interop manner.


>
> And since you refer to it as an "API", what will the RO be using to call
> this API? Is there a token management client that's separate from the OAuth
> client?
>

I didn't get your question right... If you meant the how to invoke
revocation end point, the the resource owner needs to know the consumer key
(represents the OAuth Client app) & scope to revoke the access token for a
given client.


>
>  IMHO token revocation done my RO is more practical than token revocation
> done by the Client.
>
> They're both valid but require different kinds of protocols and
> considerations. This token revocation draft is meant to solve one problem,
> and that doesn't mean it can or should solve other seemingly related
> problems.
>
> If you would like to see the RO-initiated token revocation go through (not
> grant revocation, mind you -- that's related, but different), then I would
> suggest that you start specifying exactly how that works. I predict it will
> be problematic in practice, though, as the RO often doesn't actually have
> direct access to the token itself.
>

Resource owner needs to know the consumer key (represents the OAuth Client
app) & scope to revoke the access token for a given client.



>
>
>
>> There are larger applications, like UMA, that have client and PR
>> provisioning that would allow for this to be managed somewhat
>> programmatically, but even in that case you're still generally doing token
>> revocation by a "client" in some fashion. In UMA, though, several different
>> pieces can play the role of a "client" at different parts of the process.
>>
>> Revoking a scope is a whole different mess. Generally, you'd want to just
>> revoke an existing token and make a new authorization grant with lower
>> access if you don't want that client getting that scope anymore. If you
>> just want to downscope for a single transaction, you can already do that
>> with either the refresh token or token chaining approaches, depending on
>> where in the process you are. The latter of these are both client-focused,
>> though, and the RO doesn't have a direct hand in it at this point.
>>
>
>  Why do you think it a mess. If you revoke the entire token then Client
> needs to go through the complete OAuth flow - and also needs to get the
> user consent. If RO can  downgrade the scope, then we restrict API access
> by the client at RS end and its transparent to the client.
>
>
> Downgrading the scope of tokens in the wild is hardly transparent to the
> client (stuff that it expects to work will suddenly start to fail, meaning
> that most clients will throw out the token and try to get a new one), and
> in a distributed system you've got to propagate that change to the RS. If
> you bake the scopes into the token itself (which many do) then you actually
> *can't* downgrade a single token, anyway.
>

Yes.. that is the expected behavior. I mean the process is transparent.
Client will notice at runtime.

Thanks & regards,
-Prabath


>
>  -- Justin
>
>
>  Thanks & regards,
> -Prabath
>
>
>>
>>
>>  -- Justin
>>
>>
>> On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:
>>
>>  I am sorry if this was already discussed in this list..
>>
>>  Looking at [1] it only talks about revoking the access token from the
>> client.
>>
>>  How about the resource owner..?
>>
>>  There can be cases where resource owner needs to revoke an authorized
>> access token from a given client. Or revoke an scope..
>>
>>  How are we going to address these requirements..? Thoughts
>> appreciated...
>>
>>  [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04
>>
>>  --
>> Thanks & Regards,
>> Prabath
>>
>>  Mobile : [phone] <%2B94%2071%20809%206732>
>>
>> http://blog.facilelogin.com
>> http://RampartFAQ.com
>>
>>
>>   _______________________________________________
>> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
>
>  --
> Thanks & Regards,
> Prabath
>
>  Mobile : [phone]
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
>
>
>


-- 
Thanks & Regards,
Prabath

Mobile : [phone]

http://blog.facilelogin.com
http://RampartFAQ.com