Re: [OAUTH-WG] Draft -12 feedback deadline

[Skylar Woodward <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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
>> [e-mail]
>> 
>> 
>> 
>> 
>> On 2011-02-28, at 2:58 PM, Marius Scurtescu wrote:
>> 
>>> On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg
>>> <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth