The current prose makes the distinction as a matter of practicality, not normative language. IOW, it uses these labels to provide an introduction on how OAuth may be applied to these well establish client types. However, when it comes to the actual endpoints (once the simplification proposal makes it into -09 shortly), there is no longer distinction between the client types, only the endpoint attributes.
EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Brian Dunnington > Sent: Friday, June 25, 2010 11:53 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] client secret used in Native App profile > > I think the line between 'native apps' and 'user-agent apps' is fuzzier than > that. if the only difference being considered is that user-agent apps are not > compiled (Javascript) vs. native apps that are, that is not the whole picture. > some native apps may not be compiled (think Python, etc) and even those > that are compiled are usually pretty easy to deconstruct. so in either case, > secure storage of the key is not viable. > > beyond the storage of the key is the point of distribution. to use the too-oft > cited example of Twitter, if i register my app (client), i get assigned a > Client ID > and Client Secret. if i want my native app to communicate with the Twitter > API, i have to ship the Client ID *and* secret in every instance of my app. > the > secret is now distributed to n number of unsecured machines which can > easily retrieve my secret and there is no centralized way to revoke/replace > the secret. > > Eran Hammer-Lahav wrote on his blog: > > "However, when the Consumer is a desktop application, a mobile application, > or any other client-side software such as browser applets (Flash, Java, > Silverlight) and scripts (JavaScript), the Consumer credentials must be > included in each copy of the application. This means the Consumer Secret (or > Private Key) must be distributed with the application, which inheritably > compromises them." - http://hueniverse.com/2008/10/beginners-guide-to- > oauth-part-iii-security-architecture/ > > whether written in Javascript or not, any app that runs on the end-user's > machine has the same problems with regard to client secrets. i am just trying > to wrap my head around why there should be a distinction between the two > in that regard. > > > On Fri, Jun 25, 2010 at 12:22 AM, Marius Scurtescu > <mscurte...@google.com> wrote: > > I think the main difference is that User-Agent clients (aka JavaScript > > clients) cannot store a secret while Native Apps can safely store a > > secret, but the secret cannot be distributed (or, even if it can be > > distributed, it may not have much value). > > > > The difference is important. Each native app instance could require a > > registration phase that would provide a unique secret and possibly Id. > > This registration phase could be completely automatic or could involve > > the end user. There have been proposals for both. How much value there > > is in such a registration is not clear to me. > > > > Marius > > > > > > > > On Thu, Jun 24, 2010 at 6:50 PM, Brian Dunnington > > <briandunning...@gmail.com> wrote: > >> In the 'User-Agent' profile, it says: > >> > >> "This user-agent profile does not utilize the client secret since the > >> client executables reside on the end-user's computer or device > >> which > >> makes the client secret accessible and exploitable" > >> > >> However, the 'Native Apps' profile does not include such verbiage and > >> in fact specifically requires the use of the client secret. Native > >> apps' executables also reside on the end-user's computer or device, > >> making the client secret just as accessible and exploitable, so why > >> the difference? > >> > >> Specifically, as a native app developer, there is no good (secure) > >> way to distribute the client secret without it being compromised. Any > >> open-source application would have even more problems keeping their > >> secret secure, but even complied apps are easily exploitable. in this > >> scenario, there is no single, secure repository to keep the client > >> secret safe, so I would expect that the requirement of the client > >> secret for native apps be removed and made conformant with the > >> user-agent profile. > >> _______________________________________________ > >> 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
