IETF Logo Mail Archive

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

"Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> Mon, 04 April 2011 19:37 UTC

Return-Path: <zachary.zeltsan@alcatel-lucent.com>
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 C77C43A67A3 for <oauth@core3.amsl.com>; Mon, 4 Apr 2011 12:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.339
X-Spam-Level:
X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 71eFV1eiKDKC for <oauth@core3.amsl.com>; Mon, 4 Apr 2011 12:37:02 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id E33D53A67A2 for <oauth@ietf.org>; Mon, 4 Apr 2011 12:37:01 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p34Jcf1Y005545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2011 14:38:42 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p34JcfIe009425 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Apr 2011 14:38:41 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 4 Apr 2011 14:38:41 -0500
From: "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com>
To: 'Marius Scurtescu' <mscurtescu@google.com>, Kris Selden <kris.selden@gmail.com>
Date: Mon, 04 Apr 2011 14:38:40 -0500
Thread-Topic: [OAUTH-WG] Flowchart for legs of OAuth
Thread-Index: Acvy9l3T5/MVZLLMRLCrJlQl/NMdnQAAl8Zw
Message-ID: <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.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>
In-Reply-To: <BANLkTik5u5+jjTwnwNCQVyzMux4aMB98yg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Cc: "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 19:37:02 -0000

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.

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

v2.23.0 | Report a Bug | By Email