Hi Paul
On 11/05/12 15:10, Paul Madsen wrote:
Hi Sergey, the point I was trying to make is that the end-user is not
always the 'owner' of the resource being accessed by the client.
In the archetypical consumer-centric application of OAuth, the user is
indeed the resource owner.
But, in other OAuth applications (enterprise to cloud, TV Everywhere,
etc) the owner of the resource may be some other entity (the employee's
enterprise, the video content owner, etc)
Clearer now :-), thanks
Sergey
paul
On 5/11/12 10:04 AM, Sergey Beryozkin wrote:
Hi
On 01/03/12 22:36, Paul Madsen wrote:
RO =/= end-user
Can you please elaborate on the difference a bit more ? I do not see
the main OAuth specification saying anything about it, and
OpenId-Connect seems to use both terms interchangeably, example:
http://openid.net/specs/openid-connect-standard-1_0.html#art_res_ok
When would you recommend to pay the specific attention to this
distinction, when someones reads or implements OAuth2 ?
Thanks, Sergey
On 3/1/12 5:33 PM, Zeltsan, Zachary (Zachary) 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
