Sergey, This thread is a lot like another thread titled "Securing APIs with OAuth 2.0". You might read the comments there for further clarification: http://www.ietf.org/mail-archive/web/oauth/current/msg08472.html
Regards, Andre DeMarre On Thu, Mar 1, 2012 at 2:33 PM, Zeltsan, Zachary (Zachary) <[email protected]> wrote: >>Are you saying that this can include the resources of possibly different end >>users ? > Yes. The specification does not limit a number of the users whose resources a > client may access using the client credentials flow. > > Zachary > > > -----Original Message----- > From: Sergey Beryozkin [mailto:[email protected]] > Sent: Thursday, March 01, 2012 5:17 PM > To: Zeltsan, Zachary (Zachary) > Cc: 'Richer, Justin P.'; '<[email protected]>' > Subject: Re: [OAUTH-WG] Few questions about client_credentials > > Hi, > On 01/03/12 19:23, Zeltsan, Zachary (Zachary) wrote: >> In the case of the Client Credentials Grant, an authorization servers knows >> what resources the client is authorized to access (this includes the >> resources that are not owned by the client). The specification explains that >> authorization of access to the resources "has been previously arranged with >> the authorization server (the method of which is beyond >> the scope of this specification)". >> > Are you saying that this can include the resources of possibly different > end users ? Or only of a specific single end-user ? > > >> I have nothing to add to Justin's answer to the second question. > > OK > > Thanks > > Sergey > >> >> Zachary >> >> >> Zachary >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Richer, Justin P. >> Sent: Thursday, March 01, 2012 12:01 PM >> To: Sergey Beryozkin >> Cc:<[email protected]> >> Subject: Re: [OAUTH-WG] Few questions about client_credentials >> >> If there's a fully trusted relationship between the client and the server, >> then the client may in fact be accessing data on behalf of another resource >> owner. It's a useful pattern when a three-legged flow like the Auth Code is >> not available. But it's kind of splitting hairs because the client has been >> granted a blanket access to the resource ahead of time, by virtue of its >> registration. Showing up to get a token is a method of limiting exposure and >> power of the client credentials, and making it easier to support both >> direct-client access and delegated-client access simultaneously with most of >> the same tooling. >> >> To your second question, no -- scopes do not have to be ignored in this >> case. In fact, a well-designed client and server can make use of scopes to >> let the client request an access token that's only good for whatever the >> current transaction is, as opposed to something that's representative of all >> of the client's capabilities. This is a method known as "downscoping" and >> it's a very powerful pattern that OAuth enables. Of course, if you want, you >> are fully allowed to leave the scope out entirely, then it's up to the >> Authorization Server alone to figure out what the token is really good for. >> >> Hope this clears things up, >> >> -- Justin >> >> >> >> On Mar 1, 2012, at 11:39 AM, Sergey Beryozkin wrote: >> >>> Hi, >>> >>> I have few questions about the client_credentials grant type. >>> Section 4.4 [1] says: "...client is requesting access to the protected >>> resources under its control, or those of another resource owner..." >>> >>> What I do not understand is the latter part of the above statement, how to >>> establish a link between the client authentication (which is an actual >>> grant in this case) and different resource owners given that the only thing >>> we have is the client authentication. As far as I can see it is only >>> possible to get a one to one link with the end user in this case. >>> >>> Can someone please clarify what is meant by "those of another resource >>> owner" phrase ? >>> >>> The other question is about an optional scope parameter. It has to be >>> ignored in case of the client requesting a token for accessing its own >>> resources, right ? >>> >>> Thanks, Sergey >>> >>> >>> >>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4 >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
