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

Justin Richer <jricher@mitre.org> Tue, 05 April 2011 13:23 UTC

Return-Path: <jricher@mitre.org>
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 379C328C101 for <oauth@core3.amsl.com>; Tue, 5 Apr 2011 06:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.057
X-Spam-Level:
X-Spam-Status: No, score=-5.057 tagged_above=-999 required=5 tests=[AWL=1.542, 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 LHj+2705TUEY for <oauth@core3.amsl.com>; Tue, 5 Apr 2011 06:22:56 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 2033528C0FE for <oauth@ietf.org>; Tue, 5 Apr 2011 06:22:55 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 081FA21B1018; Tue, 5 Apr 2011 09:24:39 -0400 (EDT)
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 00A8221B01D1; Tue, 5 Apr 2011 09:24:39 -0400 (EDT)
Received: from [129.83.50.23] (129.83.50.23) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Tue, 5 Apr 2011 09:24:38 -0400
From: Justin Richer <jricher@mitre.org>
To: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <EA481D30-1614-4A80-A4BB-4E4B599CF1C9@oracle.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> <DB132E2B-D363-46D3-8E7F-E5AD1BF8081E@kiva.org> <1301947797.31750.53.camel@ground> <EA481D30-1614-4A80-A4BB-4E4B599CF1C9@oracle.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 05 Apr 2011 09:24:51 -0400
Message-ID: <1302009891.31750.1113.camel@ground>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
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: Tue, 05 Apr 2011 13:23:03 -0000

Phil,

It's completely within the normative language of the spec to do things
this way right now -- the question is how the editorial text surrounding
the normative text presents different flows and use cases and how to map
between them. As it's written in the latest drafts, it sounds like the
implicit flow is the best option for native clients, but that doesn't
match with current and planned deployments.

 -- Justin

On Mon, 2011-04-04 at 16:59 -0400, Phil Hunt wrote:
> Does section 3.2 help you?
> "In addition, the authorization server MAY allow unauthenticated access token requests when the client identity does not matter (e.g. anonymous client) or when the client identity is established via other means."
> 
> Phil
> phil.hunt@oracle.com
> 
> 
> 
> 
> On 2011-04-04, at 1:09 PM, Justin Richer wrote:
> 
> > Agreed - we are planning to use the auth-code flow for native apps and
> > have no immediate plans to use implicit mode for native clients, either.
> > We'd be using the auth-code flow with a client id only and no client
> > secret, which I think is the pattern that everyone else is planning to
> > follow.
> > 
> > -- justin
> > 
> > On Mon, 2011-04-04 at 14:54 -0400, Skylar Woodward wrote:
> >> I agree with Marius' points. We plan to support the auth-code flow for native apps as well.  There is no reason why native apps can't perform a successful auth-code flow, they just do so without client credentials.  However, the spec doesn't make it clear that this is viable option.
> >> 
> >> skylar
> >> 
> >> 
> >> On Apr 4, 2011, at 2:29 PM, Marius Scurtescu wrote:
> >> 
> >>> 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
> > 
> > 
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>