Also, there's a big difference between "can keep secrets" and "can be packed/shipped with secrets". Many native apps fit into the former category but not the latter, which makes storage of refresh tokens and other long-term credentials reasonable, but not server-issued client secrets.
-- Justin On Mon, 2011-03-07 at 14:37 -0500, Skylar Woodward wrote: > 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
