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

André DeMarre <andredemarre@gmail.com> Thu, 01 March 2012 22:24 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 D083921E836D for <oauth@ietfa.amsl.com>; Thu, 1 Mar 2012 14:24:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.039
X-Spam-Level:
X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=0.260, 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 3x-34iaVxspR for <oauth@ietfa.amsl.com>; Thu, 1 Mar 2012 14:24:44 -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 D78CA21E809C for <oauth@ietf.org>; Thu, 1 Mar 2012 14:24:36 -0800 (PST)
Received: by dakl33 with SMTP id l33so1460110dak.31 for <oauth@ietf.org>; Thu, 01 Mar 2012 14:24:36 -0800 (PST)
Received-SPF: pass (google.com: domain of andredemarre@gmail.com designates 10.68.132.198 as permitted sender) client-ip=10.68.132.198;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of andredemarre@gmail.com designates 10.68.132.198 as permitted sender) smtp.mail=andredemarre@gmail.com; dkim=pass header.i=andredemarre@gmail.com
Received: from mr.google.com ([10.68.132.198]) by 10.68.132.198 with SMTP id ow6mr6584840pbb.161.1330640676708 (num_hops = 1); Thu, 01 Mar 2012 14:24:36 -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=QdltoJ2crwxwllBgLr1hPl7y0INrLgsKcV3gKFQ257A=; b=nlm7Xm9OT3+HNa8SiGThYJs7ItOo88pI/YS9QRl7gsivinusMWW/5eFFrM2kUy7W9q KGEet+42zVfC5AUGSDJ+/i/ArZpqw7QAqL+TM/GSAeC01O3KkyiokTI5nsp4iJyJNcco uHxyIKFzGy/yeF43CBiDqAp6nRP2MTtoIsiFDRQGwDagqFtAsdGEu2R4zU2tEiX252jF SgpOBCemTOXeUijLgNFGa8UToLaIzJ2QTW6BjQInSEnP3di8o3J4q5xapMiJVs7wtOrF tg6WNAgOdkAZGXP8JMhgNXagYi4tuMGMD2tqq4dfb/FX47ehEBZbhSKg7A9snYXD98JM UikQ==
MIME-Version: 1.0
Received: by 10.68.132.198 with SMTP id ow6mr5374539pbb.161.1330640676595; Thu, 01 Mar 2012 14:24:36 -0800 (PST)
Received: by 10.68.233.230 with HTTP; Thu, 1 Mar 2012 14:24:36 -0800 (PST)
In-Reply-To: <OF00AD6E13.25AA51DD-ON4A2579B4.00101F47-882579B4.00106E50@au1.ibm.com>
References: <B691F720-809F-4A9E-8C8E-6BF98EE68F07@appmuscle.com> <OF00AD6E13.25AA51DD-ON4A2579B4.00101F47-882579B4.00106E50@au1.ibm.com>
Date: Thu, 1 Mar 2012 14:24:36 -0800
Message-ID: <CAEwGkqD-1AkQHv47XVpA31NiQ2uTrTvptS0Pp0NqnL9LkvTcZw@mail.gmail.com>
From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= <andredemarre@gmail.com>
To: Pete Clark <pete@appmuscle.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: Thu, 01 Mar 2012 22:24:46 -0000

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