But what is the motivation for a malicous client to request to revoke remaining access tokens?
Justin Richer <jric...@mitre.org> 写于 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, zhou.suj...@zte.com.cn 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 <prab...@wso2.com> 写于 2013-02-07 15:25:02: > > > > > > On Thu, Feb 7, 2013 at 12:49 PM, <zhou.suj...@zte.com.cn> 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 > > > > > > > > > > > > oauth-boun...@ietf.org 写于 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 < > > tors...@lodderstedt.net > > > > 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 <prab...@wso2.com>: > > > > > > > > > > On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart <lainh...@us.ibm.com> > 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) > > > lainh...@us.ibm.com > > > > > > > > > > > > > > > > > > > > From: Prabath Siriwardena <prab...@wso2.com> > > > To: Justin Richer <jric...@mitre.org>, > > > Cc: "oauth@ietf.org WG" <oauth@ietf.org> > > > Date: 02/06/2013 10:31 AM > > > Subject: Re: [OAUTH-WG] A question on token revocation. > > > Sent by: oauth-boun...@ietf.org > > > > > > > > > > > > > > > > On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer <jric...@mitre.org> wrote: > > > > > > On 02/06/2013 10:13 AM, Prabath Siriwardena wrote: > > > > > > > > > On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <jric...@mitre.org> 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 : +94 71 809 6732 > > > > > > http://blog.facilelogin.com > > > http://RampartFAQ.com > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > > > > -- > > > Thanks & Regards, > > > Prabath > > > > > > Mobile : +94 71 809 6732 > > > > > > http://blog.facilelogin.com > > > http://RampartFAQ.com > > > > > > > > > > > > > > > -- > > > Thanks & Regards, > > > Prabath > > > > > > Mobile : +94 71 809 6732 > > > > > > http://blog.facilelogin.com > > > http://RampartFAQ.com_______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > -- > > > Thanks & Regards, > > > Prabath > > > > > > Mobile : +94 71 809 6732 > > > > > > http://blog.facilelogin.com > > > http://RampartFAQ.com > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > -- > > > Thanks & Regards, > > > Prabath > > > > > > Mobile : +94 71 809 6732 > > > > > > http://blog.facilelogin.com > > > http://RampartFAQ.com_______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > -- > > Thanks & Regards, > > Prabath > > > > Mobile : +94 71 809 6732 > > > > http://blog.facilelogin.com > > http://RampartFAQ.com > _______________________________________________ > 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
