The reason why we don't return a refresh token in the implicit grant is exactly because there is no client authentication... These are all well-balanced flows with specific security properties. If you need something else, even if it is just a tweak, it must be considered a different flow. That doesn't mean you need to register a new grant type, just that you are dealing with different implementation details unique to your server.
EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Brian Campbell > Sent: Wednesday, February 16, 2011 12:07 PM > To: Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Draft -12 feedback deadline > > 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
