Re: [OAUTH-WG] Securing APIs with OAuth 2.0
Sergey Beryozkin <sberyozkin@gmail.com> Mon, 05 March 2012 12:04 UTC
Return-Path: <sberyozkin@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 6F01621F857F for <oauth@ietfa.amsl.com>; Mon, 5 Mar 2012 04:04:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 oIkp2MxudN12 for <oauth@ietfa.amsl.com>; Mon, 5 Mar 2012 04:04:46 -0800 (PST)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 306AA21F8578 for <oauth@ietf.org>; Mon, 5 Mar 2012 04:04:45 -0800 (PST)
Received: by bkuw5 with SMTP id w5so3577201bku.31 for <oauth@ietf.org>; Mon, 05 Mar 2012 04:04:45 -0800 (PST)
Received-SPF: pass (google.com: domain of sberyozkin@gmail.com designates 10.205.122.77 as permitted sender) client-ip=10.205.122.77;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of sberyozkin@gmail.com designates 10.205.122.77 as permitted sender) smtp.mail=sberyozkin@gmail.com; dkim=pass header.i=sberyozkin@gmail.com
Received: from mr.google.com ([10.205.122.77]) by 10.205.122.77 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; d=gmail.com; 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 10.205.122.77 with SMTP id gf13mr8488262bkc.15.1330949084907; Mon, 05 Mar 2012 04:04:44 -0800 (PST)
Received: from [10.36.226.4] ([217.173.99.61]) by mx.google.com with ESMTPS id jc4sm24906589bkc.7.2012.03.05.04.04.44 (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 04:04:44 -0800 (PST)
Message-ID: <4F54ABDB.1050702@gmail.com>
Date: Mon, 05 Mar 2012 12:04:43 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: oauth@ietf.org
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
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: Mon, 05 Mar 2012 12:04:47 -0000
Hi, 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<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
- [OAUTH-WG] Securing APIs with OAuth 2.0 Pete Clark
- Re: [OAUTH-WG] Securing APIs with OAuth 2.0 Shane B Weeden
- Re: [OAUTH-WG] Securing APIs with OAuth 2.0 Pete Clark
- Re: [OAUTH-WG] Securing APIs with OAuth 2.0 Antonio Sanso
- Re: [OAUTH-WG] Securing APIs with OAuth 2.0 Aaron Parecki
- Re: [OAUTH-WG] Securing APIs with OAuth 2.0 Aaron Parecki
- Re: [OAUTH-WG] Securing APIs with OAuth 2.0 André DeMarre
- Re: [OAUTH-WG] Securing APIs with OAuth 2.0 Justin Richer
- Re: [OAUTH-WG] Securing APIs with OAuth 2.0 Sergey Beryozkin
- Re: [OAUTH-WG] Securing APIs with OAuth 2.0 Justin Richer
- Re: [OAUTH-WG] Securing APIs with OAuth 2.0 Sergey Beryozkin
- Re: [OAUTH-WG] Securing APIs with OAuth 2.0 Justin Richer