Justin has well stated my view on this. Folks here have explained how the flows can work for (or doesn't prohibit) a native app, but it also seems clear that new readers don't pick up how native apps fit into the flow in a 1st or 2nd pass.
So, in short, I agree with Brian's suggestion of (1) removing choice references to native apps, and (2) as a further (and preferred) step, a better preamble (possibly with further supporting edits) on the role of native apps. It seems Justin and Torsten are suggesting the same. To go further than step 1 I agree we need some discussion on the story for native apps. For my part, here's how I see them fitting in: - The general assumption is that Native apps can't keep secrets. This is mostly true except... - Native apps with secured distribution (eg, controlled access by corporate IT departments who also can modify app preferences w/ the provider) can claim the apps keep secrets. (A sample use case are Kiva field partners who develop simple enterprise apps for use inside a firewall). - In truth, the question of secrets or no secrets (can authenticate or spoofable) is of primary importance for choosing a flow. - In the common case, Native apps without secrets, an implicit flow or auth-code flow can be used. If an auth-code flow is used, there should be no client authentication. Alternatively, providers may instruct such clients to authenticate with an empty secret (since such clients should never be issued secrets to begin with). - In the uncommon case of native apps who can keep secrets, an implicit flow cannot be used. The app must present credentials which requires an auth-code (or other) flow. - I think there should be some note added to the auth-code flow on how a native app chooses and makes use of a redirect_uri. This was present in draft 10 and was (i think) key to understanding the auth-code story for native apps. I do not have strong opinions on the client-assertion flows for native apps nor the issuance of refresh tokens in an implicit flow. It does seem that some find it important to be able to issue refresh tokens to clients without secrets. I don't see a good argument to restrict this from a policy point of view (rather it seems more of issue of mechanics and/or fragment parsing), but it does seem the policy should be consistent. That is, if as an issue of policy, refresh tokens are not issued to apps without credentials, the policy applies for auth-code flows or implicit flows. skylar On Mar 7, 2011, at 5:54 AM, Richer, Justin P. wrote: > Agree with Torsten - having the mention in just that one place doesn't make > sense. It should be removed or replicated throughout, but I think we might > want a paragraph addressing native apps more deeply in the introduction. We > don't want to give the (incorrect) impression that the implicit flow is the > only or even preferred flow for native apps. > > -- Justin > ________________________________________ > From: [email protected] [[email protected]] On Behalf Of Torsten > Lodderstedt [[email protected]] > Sent: Monday, March 07, 2011 5:00 AM > To: Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 > feedback deadline) > > Hi Dick, > > I agree with you, the OAuth standard should offer clear patterns for > native apps. > > All native apps I'm familiar with use the authorization code, which is > because of its support for refresh tokens. But the current text of the > spec only suggests to use the implict grant flow to implement native > apps whereas previous versions mentioned authz code and password flow as > well. So in my opinion, the text is misleading to developers. And that's > not only a feeling since I already meet people, which have been > misguided :-(. > > I think at least the misleading words shall be removed. Better would be > to come up with a consensus after a discussion in the group. > > regards, > Torsten. > > Am 06.03.2011 23:12, schrieb Dick Hardt: >> -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<[email protected]> >>> 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:[email protected]] >>>>> 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 >>>>> <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
