Re: [OAUTH-WG] Securing APIs with OAuth 2.0

Sergey Beryozkin <> Mon, 05 March 2012 12:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F01621F857F for <>; Mon, 5 Mar 2012 04:04:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oIkp2MxudN12 for <>; Mon, 5 Mar 2012 04:04:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 306AA21F8578 for <>; Mon, 5 Mar 2012 04:04:45 -0800 (PST)
Received: by bkuw5 with SMTP id w5so3577201bku.31 for <>; Mon, 05 Mar 2012 04:04:45 -0800 (PST)
Received-SPF: pass ( domain of designates as permitted sender) client-ip=;
Authentication-Results:; spf=pass ( domain of designates as permitted sender); dkim=pass
Received: from ([]) by with SMTP id gf13mr10697861bkc.15.1330949085040 (num_hops = 1); Mon, 05 Mar 2012 04:04:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bHv3Jmqryd+w7IZ1z4wjrRK4Xxz4HEwcyn3e+sDQTNY=; b=P8k+5CbqHukbRhR+CPSI+ZHH10UWalxlpFBr8h3EPtDNQo+FtajcI0E4dZyjObnXo1 cHy/831NHwZ625zcJXSCenDiTH6mGI9jtU3i5XLeWsanp87zAQdcH+2mcKMwHbu3C9A3 0C2pSvemVl0cAW3dotfUdAFV2Z1BWpWQce5EyqA2TkOUVl3BDucudqgJtor9JWOJsByI IMbgoW739AZQjiCkvJY6k+1MV28MXD3x8xh3QiUIKkOEwgyoQknc8chblC2Ig0rTwdsh tVFL9XmkrZARPaAF86rYlVkmnXrafk0RS+vY2MoechcakMaOA7w4tbzkUCFcXmKV4cUi R1+A==
Received: by with SMTP id gf13mr8488262bkc.15.1330949084907; Mon, 05 Mar 2012 04:04:44 -0800 (PST)
Received: from [] ([]) by with ESMTPS id jc4sm24906589bkc.7.2012. (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 04:04:44 -0800 (PST)
Message-ID: <>
Date: Mon, 05 Mar 2012 12:04:43 +0000
From: Sergey Beryozkin <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0
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: Mon, 05 Mar 2012 12:04:47 -0000

On 01/03/12 22:24, André DeMarre wrote:
> Pete,
> Shane is right; the way you described your problem, the client
> credential grant type may be appropriate. That's especially true if
> the client will be accessing resources that don't necessarily belong
> to specific users. But if the client (web site) will be using the API
> (OAuth auth/resource server) to access user-specific resources, then
> the authorization code grant type is a better fit. It doesn't matter
> that the OAuth server trusts the client without needing user
> authorization.
> The authorization code flow offers a solution for user identification
> that is absent in the client credential flow. In other words, even
> though the OAuth server trusts the client and will comply with all API
> requests, how is the client x supposed to identify a user so it can
> request the right resource from the resource server?
> By using an authorization code grant, the client can acquire an access
> token that is bound to a specific user. This is makes the
> authorization code flow suitable for single sign-on implementations,
> whereas the client credential flow is not appropriate for user
> authentication.
> Don't worry about the fact that the client does not need to be
> authorized by the user. You can still use the authorization code flow,
> and the authorization server will not need to prompt the user for
> authorization because you will have pre-authorized the client for all
> users.

Can the authorization server return a (pre-authorized) token immediately 
in this case, despite the fact the client is specifying 
"response_type=code" ?
If the authorization code, to be exchanged later for this token, has to 
be returned, how reasonable is it to expect that the authorization code 
will be bound to the pre-authorized access token (example, the access 
token's key/id will be returned as the authorization code) ?

I suspect it may not be a good idea given the spec is saying the 
authorization code should be short-lived, thus the codes and actual 
tokens will have different life-cycles, however the fact the end user 
has pre-authorized the client adds some uncertainty to it...

thanks, Sergey

> As an added bonus, this sets you up perfectly for when you add new
> clients which are not pre-authorized and need user authorization.
> I hope that helps.
> Regards,
> Andre DeMarre
> On Wed, Feb 29, 2012 at 6:59 PM, Shane B Weeden<>  wrote:
>> 1. Yes, client credentials sounds right for what you described. Think of it
>> as lightweight b2b authentication in that sense (but two steps - one to get
>> a token, and another to use it).
>> 2. Can't help you with source - but do have a product-based solution :)
>> 3. Absolutely it should for the resource server, but the answer may depend
>> have same dependency on the implementation you use.
>> Regards,
>> Shane.
>> From:   Pete Clark<>
>> To:     ""<>
>> Date:   29/02/2012 06:50 PM
>> Subject:        [OAUTH-WG] Securing APIs with OAuth 2.0
>> Sent by:
>> Hey all, I've joined the list because I'd like to use OAuth 2 to implement
>> security for a new set of REST APIs I'm developing for a client.  I'm
>> coding with PHP, but my questions are more general.  Right now, there will
>> be only one web site that uses the APIs, in a server-to-server fashion, and
>> currently we don't have a need for a third party application to gain access
>> to user data, such that a user would need to authorize that app.  We do,
>> however, want to have that ability down the road.  My question is, can I
>> still use OAuth 2 in some way to implement our first phase?  From what I've
>> read, it seems like the "client credentials" flow is the one I want to use
>> for now.  Can someone:
>> 1) Confirm that that's what I should use for this first phase?
>> 2) Point me to an implementation of this flow (in any language) that I
>> could use or port to PHP?  I've found some libraries for php but can't
>> really tell, being new, if they offer the "client credentials" flow
>> 3) Answer one more question.. Will using the client credentials flow now
>> allow me to move to one of the user-authorizes-external-app flows down the
>> road without having to reimplement or throw away the client credentials
>> flow code?
>> I apologize for all the questions, but these would really help point me in
>> the right direction.. Thank you for reading!
>> Sincerely,
>> Pete
>> _______________________________________________
>> OAuth mailing list
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list