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.h...@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.sel...@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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
