IETF Logo Mail Archive

Re: [OAUTH-WG] Flowchart for legs of OAuth

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 04 April 2011 20:59 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA8D93A67F4 for <oauth@core3.amsl.com>; Mon, 4 Apr 2011 13:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.222
X-Spam-Level:
X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL3aUlbE6Ozr for <oauth@core3.amsl.com>; Mon, 4 Apr 2011 13:59:23 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by core3.amsl.com (Postfix) with ESMTP id BBEBC3A67EE for <oauth@ietf.org>; Mon, 4 Apr 2011 13:59:22 -0700 (PDT)
Received: from [79.253.39.103] (helo=[192.168.71.20]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1Q6qtT-0000SJ-DC; Mon, 04 Apr 2011 23:01:03 +0200
Message-ID: <4D9A318D.3090908@lodderstedt.net>
Date: Mon, 04 Apr 2011 23:01:01 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com>
References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <AANLkTimGjiCGk5dpA=YVzq5vDkLR2+caSz=pZ5WiZO9H@mail.gmail.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <BANLkTiniuuRXtkzLubgOjVursVtOGjFe6A@mail.gmail.com> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <BANLkTi=XyF25vB6qKX2q8iOpEaZ1yQx9Jw@mail.gmail.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <BANLkTik5u5+jjTwnwNCQVyzMux4aMB98yg@mail.gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
In-Reply-To: <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: torsten@lodderstedt-online.de
Cc: Kris Selden <kris.selden@gmail.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 04 Apr 2011 20:59:24 -0000

Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary):
> According to section "6 Refreshing an Access Token" (-13.txt), client when making a request for exchanging a refresh token for an access token has to include its authentication credentials, and the "authorization server MUST validate the client credentials".
> How can this be done if a client is an application that can't have a client secret?
> The authorization code grant does require client authentication (per section 4.1):
>
> (D)  The client requests an access token from the authorization
>          server's token endpoint by authenticating using its client
>          credentials, and includes the authorization code received in the
>          previous step.
>
> It appears that the clients that cannot keep its secret cannot use (be issued) the refresh tokens.

In my opinion, this part of the spec is misleading. Authorization code 
MUST be possible without client authentication. Otherwise, OAuth is 
useless for native apps.

http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-01#section-2.10 
describes how the flow can be protected in such cases.

regards,
Torsten.
> Zachary
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Marius Scurtescu
> Sent: Monday, April 04, 2011 2:30 PM
> To: Kris Selden
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
>
> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden<kris.selden@gmail.com>  wrote:
>> A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once.
>>
>> What is the best profile to use for an app that can't have a client secret and needs a refresh token or a long lived access token?
> The authorization code grant, aka web server flow.
>
> The spec is misleading in this respect IMO.
>
> Marius
> _______________________________________________
> 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

v2.23.0 | Report a Bug | By Email