-1 Many sites are using OAuth (or something like it) in native apps now.
One of the objectives of having a standard is to bring best practices and standardization to how to solve a problem rather than "a million freakin unique snowflakes" where developers have to learn and code each mechanism to enable authorization to a native app. Brian's suggested wording may make sense in the context of where OAuth is now -- but it signals that the WG has been unable to solve what I think many viewed as an important aspect of the WG. fwiw: I think a number of important constituents have opted out of the dialogue. An unfortunate situation. On 2011-03-02, at 6:05 AM, Brian Campbell wrote: > I propose that the "or native applications" text be dropped from the > first paragraph in section 4.2 Implicit Grant [1]. > > There is clearly some disagreement about what is most appropriate for > mobile/native applications and many, including myself, don't feel that > the implicit grant works well to support them (due to the lack of a > refresh token and need to repeat the authorization steps). I > understand that the text in section 4 is non-normative, however, I > feel that the mention of native apps in 4.2 biases thinking in a > particular way (it's already led to one lengthy internal discussion > that I'd rather not have again and again). I believe it'd be more > appropriate for the draft to remain silent on how native apps should > acquire tokens and leave it up to implementations/deployments to > decide (or an extension draft as Marius has proposed). > > The "or native applications" text in is also somewhat inconsistent > with the text in the following sentence that talks about the > authentication of the client being based on the user-agent's > same-origin policy. > > Removing those three words is a small change but one that I feel would > be beneficial on a number of fronts. > > Thanks, > Brian > > > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2 > > On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: >> Feel free to propose alternative preamble for the implicit and authorization >> code sections, describing the characteristics of what they are good for. It >> should fit in a single paragraph. Such a proposal would fit right in with >> last call feedback to -13. >> >> EHL >> >>> -----Original Message----- >>> From: Marius Scurtescu [mailto:mscurte...@google.com] >>> Sent: Wednesday, February 16, 2011 1:39 PM >>> To: Eran Hammer-Lahav >>> Cc: Brian Campbell; OAuth WG >>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >>> >>> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav >>> <e...@hueniverse.com> wrote: >>>> The reason why we don't return a refresh token in the implicit grant is >>> exactly because there is no client authentication... >>> >>> Not sure that's the main reason. AFAIK it is because the response is sent >>> through the user-agent and it could leak. >>> >>> >>>> 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. >>> >>> The Authorization Code flow, with no client secret, is perfectly fine for >>> Native >>> Apps IMO. >>> >>> 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
