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
<mscurte...@google.com> wrote:
On Wed, Feb 16, 2011 at 11:06 AM, William Mills<wmi...@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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
