Hi Andre
On 01/03/12 23:42, André DeMarre wrote:
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
Indeed, I was just reading it :-)
thanks to all for the comments
Sergey
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
