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

Justin Richer <jricher@mitre.org> Fri, 02 March 2012 15:27 UTC

Return-Path: <jricher@mitre.org>
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 17C8F21F84B6 for <oauth@ietfa.amsl.com>; Fri, 2 Mar 2012 07:27:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.436
X-Spam-Level:
X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 KuGOwkzuOkeE for <oauth@ietfa.amsl.com>; Fri, 2 Mar 2012 07:27:32 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1AA21F85B5 for <oauth@ietf.org>; Fri, 2 Mar 2012 07:27:32 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5D1E321B0E06; Fri, 2 Mar 2012 10:27:31 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 23C2021B0EB6; Fri, 2 Mar 2012 10:27:31 -0500 (EST)
Received: from [129.83.50.12] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 2 Mar 2012 10:27:30 -0500
Message-ID: <4F50E68B.9050200@mitre.org>
Date: Fri, 2 Mar 2012 10:26:03 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Andr=E9_DeMarre?= <andredemarre@gmail.com>
References: <B691F720-809F-4A9E-8C8E-6BF98EE68F07@appmuscle.com> <OF00AD6E13.25AA51DD-ON4A2579B4.00101F47-882579B4.00106E50@au1.ibm.com> <CAEwGkqD-1AkQHv47XVpA31NiQ2uTrTvptS0Pp0NqnL9LkvTcZw@mail.gmail.com>
In-Reply-To: <CAEwGkqD-1AkQHv47XVpA31NiQ2uTrTvptS0Pp0NqnL9LkvTcZw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [129.83.31.51]
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0
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: Fri, 02 Mar 2012 15:27:33 -0000

+1 to André's suggestion below.

If you find that you're going to have to add a field to your API to 
indicate the userID along with a two-legged transaction, you're likely 
doing things wrong.

We've used the auto-approve method below for several applications, and 
users don't seem to know or care what's really happening. They show up 
to the client app, they see a little waiting screen the first time 
through, and then it works. That is to say, it's nearly as transparent 
as a two-legged scenario but with better security and flexibility aspects.

The two-legged approach works best when:
   1) There's no user involved in the transaction at all (traditional 
system-to-system data exchange)
   2) You *can't* have the user present on any part of the transaction 
(it must work fully back-channel)

If you can count on the user being there at any point, even to just kick 
things off, then the code flow is likely more like what you're after.

  -- Justin

On 03/01/2012 05:24 PM, 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.
>
> 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<sweeden@au1.ibm.com>  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<pete@appmuscle.com>
>> To:     "oauth@ietf.org"<oauth@ietf.org>
>> Date:   29/02/2012 06:50 PM
>> Subject:        [OAUTH-WG] Securing APIs with OAuth 2.0
>> Sent by:        oauth-bounces@ietf.org
>>
>>
>>
>> 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@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