I had assumed a use case for this was an entirely browser-based client. Such a client would be limited to same-host requests. Providing a proxy to make token requests just opens the possibility of abuse of client proxies with poor security practices - and for no added value. If a client can't secure credentials, there's no point in a second round trip. As such, simplify the model and, in the process, emphasize the loss of of a layer of security in the flow.
In principle, I favor reserving separate flows for credential vs. credential-less apps. However, in practice, I see providers evangelizing one flow when there are a mix of apps with credentials and those without (eg, mix of device & hosted apps in the ecosystem) and thus no need to restrict the code flow only to clients with secrets. One flow is enough complication when there is provider-specific complexity to explain as well. The implicit flow, then, seems appropriate for providers who never issue secret client credentials. Better use cases anyone? On Mar 1, 2011, at 2:24 AM, Eran Hammer-Lahav wrote: > One more round trip is often too slow. > > EHL > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Phil Hunt >> Sent: Monday, February 28, 2011 3:18 PM >> To: Marius Scurtescu >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >> >> Given these questions, I am wondering, why does the Implicit Grant flow >> NOT have an authorization code step? Having one, would keep architecture >> of AS and TS clearly separate. >> >> One down side is that issuing of access/refresh token would now have to be >> opened to SHOULD authenticate the client from MUST. >> >> What was the original case for this flow? That should point us as to why the >> separate flow and whether refresh makes sense given the higher risks of the >> implicit flow. >> >> Phil >> phil.h...@oracle.com >> >> >> >> >> On 2011-02-28, at 2:58 PM, Marius Scurtescu wrote: >> >>> On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg >>> <igor.faynb...@alcatel-lucent.com> wrote: >>>> +1 >>>> >>>> Igor >>>> >>>> Torsten Lodderstedt wrote: >>>>> >>>>> ... >>>>> >>>>> I'm in favour to add the refresh token parameter to the implicit >>>>> grant flow as it would make it more useable for native apps. >>> >>> I think it is much safer to go with refresh tokens only sent >>> indirectly through an authorization code swap. >>> >>> Implicit grant with refresh token also has no client secret swap and >>> makes things worse by passing the refresh token through the browser. >>> >>> 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
