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

[Todd W Lainhart <[e-mail]>]

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

I see - you're saying that requiring client credentials on the end point 
is the problem?





Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[e-mail]




From:   Prabath Siriwardena <[e-mail]>
To:     Justin Richer <[e-mail]>, 
Cc:     "[e-mail] WG" <[e-mail]>
Date:   02/06/2013 10:31 AM
Subject:        Re: [OAUTH-WG] A question on token revocation.
Sent by:        [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] 

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


_______________________________________________
OAuth mailing list
[e-mail]
https://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_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth