Subject: [OAUTH-WG] Few questions about client_credentials

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 01 Mar 2012 16:39:11 +0000

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 1 Mar 2012 17:00:42 +0000

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:

> 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
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 1 Mar 2012 13:23:45 -0600

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)".

I have nothing to add to Justin's answer to the second question.

Zachary

Zachary 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richer, Justin P.
Sent: Thursday, March 01, 2012 12:01 PM
To: Sergey Beryozkin
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] Few questions about client_credentials

 -- Justin

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 01 Mar 2012 22:14:07 +0000

Thanks for the comments,

> 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-legg…

It does make sense. What I'm still missing is how an access token 
returned as part of the client_credentials flow can 'link' to more than 
a single resource owner. The authorization server can establish the fact 
that a specific end user pre-authorized the client, but how to manage 
the case where many end users have pre-authorized the same client ? The 
returned access token won't uniquely identify the end user which have 
pre-authorized this client...

> 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…
Sure - I can see why it is very useful for an authorization code flow.
Still a bit unclear why the scope can be needed in case where a client 
is accessing its own resources, but do see it can be useful when the 
access to the end user's resources is also thought...

many thanks
Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 01 Mar 2012 22:17:07 +0000

Hi,
>   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

> Cc:<[email-masked]>

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 1 Mar 2012 16:33:31 -0600

>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-masked]] 
Sent: Thursday, March 01, 2012 5:17 PM
To: Zeltsan, Zachary (Zachary)
Cc: 'Richer, Justin P.'; '<[email-masked]>'
Subject: Re: [OAUTH-WG] Few questions about client_credentials

Hi,

OK

Thanks

Sergey

---

From: Paul Madsen <[email-masked]>
Date: Thu, 01 Mar 2012 17:36:19 -0500

RO =/= end-user

---

From: André DeMarre <[email-masked]>
Date: Thu, 1 Mar 2012 15:42:53 -0800

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

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 02 Mar 2012 09:44:15 +0000

Hi Andre

> http://www.ietf.org/mail-archive/web/oauth/current/msg08472.html

Indeed, I was just reading it :-)

thanks to all for the comments
Sergey

---

From: Eran Hammer <[email-masked]>
Date: Wed, 7 Mar 2012 17:01:43 -0700

> From: Songhaibin [mailto:[email-masked]]
> Sent: Friday, February 17, 2012 12:53 AM
> To: Justin Richer
> Cc: [email-masked]; [email-masked]; Martin
> Stiemerling; [email-masked]; [email-masked]
> Subject: RE: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
> 
> Hi Justin,
> 
> Thank you for the clarification. See in line.
> 
> > From: Justin Richer [mailto:[email-masked]]
> > Sent: Wednesday, February 15, 2012 9:44 PM
> > To: Songhaibin
> > Cc: [email-masked]; [email-masked]; Martin
> > Stiemerling; [email-masked]; [email-masked]
> > Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
> >
> > On 02/15/2012 04:33 AM, Songhaibin wrote:
> > > I've reviewed this document as part of the transport area
> > > directorate's ongoing
> > effort to review key IETF documents. These comments were written
> > primarily for the transport area directors, but are copied to the
> > document's authors for their information and to allow them to address
> > any issues raised. The authors should consider this review together with
> any other last-call comments they receive.
> > Please always CC [email-masked] if you reply to or forward this review.
> > >
> > > First, I should apologize for the delay in this review, I should
> > > have finished it two
> > days ago. I have some common security knowledge but not an expert.
> > >
> > > Summary
> > >
> > > This draft is basically ready for publication, but has nits that
> > > should be fixed
> > before publication.
> > >
> > > General issues need discussion:
> > >
> > > 1. Section 1.3.3 and 1.3.4 discuss two authorization grant type:
> > > resource owner
> > password credentials, and client credentials. These two have the same
> > flow and many in common, and they are significantly different than the
> > authorization code grant type and implicit grant type described in
> > previous sections. And in section 1.3.4, it also says " Client
> > credentials are used as an authorization grant typically when the
> > client is acting on its own behalf (the client is also the resource
> > owner),...". Is it better to combine these two grant types as one "client
> credentials" grant type where the client can be the resource owner?
> >
> > No, they are quite distinct -- It all comes down to what you're
> > authenticating. The Resource Owner Password Credentials flow *also*
> > includes client credentials which are distinct from the resource
> > owner's own credentials. The client's credentials are going to be the
> > same for a given client across many different users, while the
> > Resource Owner's credentials are going to be different across
> > different users, but the same across different clients (for the same
> > resource owner). In most flows, the client's credentials identify just
> > the client, and the resource owner is identified through some other
> > means (a direct password, a redirected login to the authz endpoint).
> > In the Client Credentials flow, the client's credentials are the only ones that
> you have.
> >
> 
> Okay, in the Resource Owner Password Credentials flow, it adds client
> credentials, but any client who was issued credentials from the authorization
> server can pass. How much security does the client credential in this flow
> add?

It can allow the server to enforce policies, but more importantly, client authentication is part of every access token request make to this endpoint as part of the overall architecture.

> > > 2. Two concepts confused me in section 2.4, I don't know if I am the
> > > only person
> > who is confusing here. One is user-agent-based application and another
> > is native application, why are they executed on the device used by the
> > resource owner? I think they can run on any device used by resource
> > consumer instead of resource owner. Resource owner is only used to grant
> access to resources.
> >
> > OAuth's main 3-legged pattern allows what's called "Alice-to-Alice
> > sharing", in that the Client is consuming on behalf of the resource
> > owner. In cases where you have an in-user-agent app or a native app,
> > the end user (resource owner) is going to be the one running it, and
> > the one authorizing it.
> >
> 
> Yes, I understand that. But the document seems like resource owner is the
> "only" one who can run the UA app or native app? Or I missed something?

It is the only one. Only the resource owner can grant access.

EH

> 
> Thanks,
> -Haibin
> 
> >
> > Thanks for your feedback, and I hope this can help clear up the intent
> > of the working group here. If you can suggest language that will
> > solidify these points further, it can help make sure this doesn't
> > further confuse people.
> >
> >   -- Justin

---

From: Eran Hammer <[email-masked]>
Date: Wed, 7 Mar 2012 17:15:56 -0700

Thanks Haibin.

> Sent: Wednesday, February 15, 2012 1:33 AM

> Nits:
> 1. Section 3.1, paragraph 4, the last sentence is confusing, is it the
> authorization server who sends the request to the authorization endpoint?
> Or is it the resource owner?

The client. Added clarification in section 3.

> 2. Section 3.1.1, paragraph 3, "...where the order of values does not matter.."
> I think a little clarification on the reason for this would be better for people
> like me.

I don't think we need to explain it, but it's to meet typical developers' expectations.

> 3. Section 3.2, paragraph 4, the last sentence is confusing, is it the
> authorization server who sends request to the token endpoint?

Same as #1.

> 4. Section 10.12, paragraph 4, should the terminology "end-user" be changed
> to "resource owner"? There are same issues in other places of this
> document.

Changed some. Clarified end-user in the intro.

> 5. Section 10.6, paragraph 2, second sentence, When the attacker is sent
> to.../ When the authorization code request is sent to...

Not sure what you mean.

EH

---

From: Songhaibin <[email-masked]>
Date: Thu, 08 Mar 2012 02:10:39 +0000

> > to.../ When the authorization code request is sent to...

I mean you may have to change "the attacker is sent to..." to "the authorization code is sent to...".

BR,
-Haibin

> From: Eran Hammer [mailto:[email-masked]]
> Sent: Thursday, March 08, 2012 8:16 AM
> To: Songhaibin; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; Martin Stiemerling
> Subject: RE: tsv-dir review of draft-ietf-oauth-v2-23
> 
> Thanks Haibin.
>

---

From: Songhaibin <[email-masked]>
Date: Thu, 08 Mar 2012 02:20:44 +0000

OK. I understand. Then I have no questions. 

Thank you for the answer.
-Haibin

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Eran Hammer
> Sent: Thursday, March 08, 2012 8:02 AM
> To: Songhaibin; Justin Richer
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Martin Stiemerling
> It can allow the server to enforce policies, but more importantly, client
> authentication is part of every access token request make to this endpoint as
> part of the overall architecture.
>

---

From: Eran Hammer <[email-masked]>
Date: Wed, 7 Mar 2012 22:29:39 -0700

Should simple read "the attacker's user-agent is sent to".

EH

> Sent: Wednesday, March 07, 2012 6:11 PM
> To: Eran Hammer; [email-masked]; [email-masked]
> > > 5. Section 10.6, paragraph 2, second sentence, When the attacker is
> > > sent to.../ When the authorization code request is sent to...
> >
> > Not sure what you mean.
> 
> > > 1. Section 3.1, paragraph 4, the last sentence is confusing, is it
> > > the authorization server who sends the request to the authorization
> endpoint?
> > > I think a little clarification on the reason for this would be
> > > better for people like me.
> >
> > > 3. Section 3.2, paragraph 4, the last sentence is confusing, is it
> > > the authorization server who sends request to the token endpoint?
> >
> > Same as #1.
> >
> > > 4. Section 10.12, paragraph 4, should the terminology "end-user" be
> > > changed to "resource owner"? There are same issues in other places
> > > of this document.
> >
> > > 5. Section 10.6, paragraph 2, second sentence, When the attacker is
> > > sent to.../ When the authorization code request is sent to...
> >
> > Not sure what you mean.
> >
> > EH
> >