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

[[e-mail]]

But what is the motivation for a malicous client to request to revoke 
remaining access tokens?


Justin Richer <[e-mail]> 写于 2013-02-08 00:06:07:

> This, I think, points out that the RO is generally more concerned 
> with revoking an authorization grant than a token itself, with the 
> latter potentially encompassing several tokens. The revocation draft
> isn't really intended to solve that problem, as Torsten points out 
below.
> 
>  -- Justin

> On 02/07/2013 03:46 AM, [e-mail] wrote:
> 
> During the four grant types of Oauth, 
>   1. authorization code: RO knows the authorization code upon which 
> access-tokens-to-be-revoked are issued 
>   2. implicite flow: RO knows the access-tokens-to-be-revoked 
>   3. password and client credential types: RO has no way of knowing 
> access tokens. 
> 
> So,IMO,  it is not proper for RO to revoke an each access token 
individually,
> rather it could revoke some access tokens by specifying conditions, 
> such as client_id, time_period, scope 
> Comments? 
> 
> Prabath Siriwardena <[e-mail]> 写于 2013-02-07 15:25:02:
> 
> > 
> 
> > On Thu, Feb 7, 2013 at 12:49 PM, <[e-mail]> wrote: 
> > 
> > I guess RO could initiate access token revocation for a client by 
> > including authorization code in the request to AS. 
> > Comments? 
> > 
> > That creates a dependency on the grant type. 
> > 
> > Thanks & regards, 
> > -Prabath 
> > 
> > 
> > 
> > 
> > 
> > [e-mail] 写于 2013-02-07 02:32:28:
> > 
> > > Hi Torsten, 
> > > 
> > > Thanks for your feedback.. I will submit a draft... 
> > > 
> > > Thanks & regards, 
> > > -Prabath
> > 
> > > On Wed, Feb 6, 2013 at 11:55 PM, Torsten Lodderstedt <
> > [e-mail]
> > > > wrote: 
> > > Hi Prabath, 
> > > 
> > > we tried to address both use cases in the first revisions of the 
> > > draft. The API was well suited for client-driven revocation but not 
> > > the resource owner - driven use case. There are definitely 
> > > differences with respect to the protocol design, at least regarding 
> > > authentication and authorization of the respective actors. This made
> > > the spec more complex and caused ambiguities and confusion. 
> > > Moreover, the working group seemed not convinced by the the 
> latteruse case.
> > > 
> > > Therefore the working group decided to focus on the single use cases
> > > of the revocation by clients. This makes a lot of sense since this 
> > > interface is most important with respect to interoperability. 
> > > 
> > > I'm focusing right now on finishing this draft. And the open issues 
> > > discussed on the list in the last couple of weeks illustrate that 
> > > even this poses a considerable amount of work. So I'm very reluctant
> > > to add support for a whole new use case at that point of the 
process. 
> > > 
> > > If you feel this is an important use case worth an RFC, don't 
> > > hesitate to publish a new I-D. 
> > > 
> > > regards, 
> > > Torsten. 
> > > 
> > > Am 06.02.2013 um 16:37 schrieb Prabath Siriwardena 
<[e-mail]>:
> > 
> > > 
> > 
> > > On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart 
<[e-mail]>
> wrote:
> > > > Resource owner needs to know the consumer key (represents the 
> > > OAuth Client app) & scope to revoke the access token for a 
givenclient. 
> > 
> > > I see - you're saying that requiring client credentials on the end 
> > > point is the problem? 
> > > 
> > > In fact what I meant was - when RO authorizes the an access token 
> > > for client for particular scope. Those information are kept at the 
AS. 
> > > 
> > > Now - if the RO want to revoke access from the client - the RO needs
> > > to authenticate him self to the AS and pass the consumer key and the
> > > scope. So AS can revoke access. 
> > > 
> > > Thanks & regards, 
> > > -Prabath 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 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
> > 
> > > 
> > 
> > > 
> > > -- 
> > > 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_______________________________________________
> > > OAuth mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/oauth 
> > 
> 
> > 
> > -- 
> > Thanks & Regards,
> > Prabath 
> > 
> > Mobile : [phone] 
> > 
> > http://blog.facilelogin.com
> > http://RampartFAQ.com 

> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth