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

The implicit grant still requires a redirect of some kind, so many 
native apps can just as easily use the web server flow as the implicit 
flow. I personally don't see how the implicit flow is better suited than 
the web flow in this case. However, neither of these are ideally suited 
for native apps without a few tricks, which is the native apps extension 
that Marius is working on, to get the token back to the native app. From 
what I can see, the real question here is dealing with cases where a 
redirect doesn't actually make any sense. In those cases, I'd rather see 
a separate flow profiled end to end than to have hacks like the 
"uri:oob" put in place to patch it into an existing spot.

  -- Justin

On 2/16/2011 3:07 PM, Brian Campbell wrote:
> Exactly Marius, and in most cases the app will want to procure a
> refresh token as a result of the dance so it won't have to put the
> user though the authorization process again and again.  Unless I'm
> mistaken, the implicit grant provides no means of obtaining a refresh
> token (http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2.2)
>   So unless the access tokens themselves are extremely long lived, the
> implicit grant flow doesn't seem very useful to native clients.
>
> I've heard a number of people suggest the native client ->  implicit
> grant thing but it doesn't make sense to me.  Is there something I'm
> not seeing?
>
> On Wed, Feb 16, 2011 at 12:14 PM, Marius Scurtescu
> <mscurtescu@google.com>  wrote:
>> On Wed, Feb 16, 2011 at 11:06 AM, William Mills<wmills@yahoo-inc.com>  wrote:
>>> Token endpoint with username/password credential doesn't solve this?  Depends on the auth scheme of course, but Bearer should provide a solution?
>> Not at all, in most case native apps must use the browser based 3-legged dance.
>>
>> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth