To clarify, when I say "can keep secrets" I mean "can be packed/shipped with secrets." Good point.
I assume all OAuth clients can keep secrets in the more general sense you implied. Otherwise, even bearer tokens would be useless. On Mar 8, 2011, at 6:26 AM, Justin Richer wrote: > 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
