>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
