Re: [OAUTH-WG] Few questions about client_credentials

André DeMarre <andredemarre@gmail.com> Thu, 01 March 2012 23:42 UTC

Return-Path: <andredemarre@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0496421E83E2 for <oauth@ietfa.amsl.com>; Thu, 1 Mar 2012 15:42:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.068
X-Spam-Level:
X-Spam-Status: No, score=-3.068 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S76vrJt4+Vl6 for <oauth@ietfa.amsl.com>; Thu, 1 Mar 2012 15:42:54 -0800 (PST)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE2F21E83E1 for <oauth@ietf.org>; Thu, 1 Mar 2012 15:42:54 -0800 (PST)
Received: by dakl33 with SMTP id l33so1523513dak.31 for <oauth@ietf.org>; Thu, 01 Mar 2012 15:42:54 -0800 (PST)
Received-SPF: pass (google.com: domain of andredemarre@gmail.com designates 10.68.219.130 as permitted sender) client-ip=10.68.219.130;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of andredemarre@gmail.com designates 10.68.219.130 as permitted sender) smtp.mail=andredemarre@gmail.com; dkim=pass header.i=andredemarre@gmail.com
Received: from mr.google.com ([10.68.219.130]) by 10.68.219.130 with SMTP id po2mr8735224pbc.140.1330645374074 (num_hops = 1); Thu, 01 Mar 2012 15:42:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UYU2GzjB6JFvpXDBGEwbDmtKq7U0ebwHyMwIdaRVIqs=; b=GKhPUsAq8kL9aGyqcJhuAaPZ9GsJIbKxvXY+HSOYkV++kKEDJxitoMjHyPomsIbPLD bA+LfOQRUrAvqZaAsjq3i3nEbcRWk65eQr27pdqhcuup7cla6LfnGvXF4o5iWBmeCS0V ZPTXAleG3EImHexPwZZRMgtUU9ovQXZPyhPvVcHwGmSWqiTkMoHX3D5qzrc8Y/Re+lSb GIOo1p1GL9bf5Ozj/smUB6xAAlsnpCdE68GE5aHe1n8ef9047E+8AIR5C9clx6VV8IAm a7nKq2AForaI3M2A/k0JhbUGJ3eg8ls5imD2JgZj7AenPJ1KAbfUvr10VvxjHHv5rLVu e1HQ==
MIME-Version: 1.0
Received: by 10.68.219.130 with SMTP id po2mr7205549pbc.140.1330645373971; Thu, 01 Mar 2012 15:42:53 -0800 (PST)
Received: by 10.68.233.230 with HTTP; Thu, 1 Mar 2012 15:42:53 -0800 (PST)
In-Reply-To: <5710F82C0E73B04FA559560098BF95B1250DBA5F93@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <E33E01DFD5BEA24B9F3F18671078951F156D8F4B@szxeml534-mbx.china.huawei.com> <4F3BB6B8.1030501@mitre.org> <4F4FA62F.7010404@gmail.com> <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org> <5710F82C0E73B04FA559560098BF95B1250DBA5E89@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4F4FF563.3070806@gmail.com> <5710F82C0E73B04FA559560098BF95B1250DBA5F93@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Date: Thu, 1 Mar 2012 15:42:53 -0800
Message-ID: <CAEwGkqDrH-vuroRQXZYNum1xRCh6iAsOfBgTyf+pnLti=HBUCQ@mail.gmail.com>
From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= <andredemarre@gmail.com>
To: Sergey Beryozkin <sberyozkin@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Few questions about client_credentials
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2012 23:42:55 -0000

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)
<zachary.zeltsan@alcatel-lucent.com> 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:sberyozkin@gmail.com]
> Sent: Thursday, March 01, 2012 5:17 PM
> To: Zeltsan, Zachary (Zachary)
> Cc: 'Richer, Justin P.'; '<oauth@ietf.org>'
> 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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P.
>> Sent: Thursday, March 01, 2012 12:01 PM
>> To: Sergey Beryozkin
>> Cc:<oauth@ietf.org>
>> 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
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth