Re: [OAUTH-WG] Few questions about client_credentials

"Richer, Justin P." <> Thu, 01 March 2012 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C77121F8849 for <>; Thu, 1 Mar 2012 09:00:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.586
X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XS04I+hcAEe9 for <>; Thu, 1 Mar 2012 09:00:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BBC4F21E82A6 for <>; Thu, 1 Mar 2012 09:00:44 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 4AD1F21B1541; Thu, 1 Mar 2012 12:00:43 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG ( []) by (Postfix) with ESMTP id F0DDA21B19A1; Thu, 1 Mar 2012 12:00:42 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([]) by IMCCAS03.MITRE.ORG ([]) with mapi id 14.01.0339.001; Thu, 1 Mar 2012 12:00:42 -0500
From: "Richer, Justin P." <>
To: Sergey Beryozkin <>
Thread-Topic: [OAUTH-WG] Few questions about client_credentials
Thread-Index: AQHM98nrRaaDgg3Qr0KgBitLVeQMQJZV/ekA
Date: Thu, 01 Mar 2012 17:00:42 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<>" <>
Subject: Re: [OAUTH-WG] Few questions about client_credentials
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Mar 2012 17:00:48 -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:

> 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]
> _______________________________________________
> OAuth mailing list