I don't have strong views on keeping the reference to native apps, but the spec no longer offers advice on picking a grant type, other than pointing out the importance of being able to keep a secret. The term native app is undefined.
What is needed is a separate guide for helping newcomers pick the right grant type for their specific needs. I also want to point out that this is a standard, not a tutorial. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Skylar Woodward > Sent: Monday, March 07, 2011 11:38 AM > To: Richer, Justin P. > Cc: OAuth WG > Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 > feedback deadline) > > 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: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of > > Torsten Lodderstedt [tors...@lodderstedt.net] > > 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<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 > > _______________________________________________ > > 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 > > _______________________________________________ > 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
