Subject: [OAUTH-WG] client secret used in Native App profile

From: Brian Dunnington <[email-masked]>
Date: Thu, 24 Jun 2010 18:50:44 -0700

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.

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 25 Jun 2010 00:22:35 -0700

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
<[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Bouiaw <[email-masked]>
Date: Fri, 25 Jun 2010 16:08:24 +0200

If we consider HTML5 browser, I am not sure there is a clear
separation betweeen native apps and user agent clients. What is the
technical difference between a native app and a browser that support
HTML 5 localStorage ?

---

From: Brian Dunnington <[email-masked]>
Date: Fri, 25 Jun 2010 11:53:24 -0700

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.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Jun 2010 11:56:28 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Dunnington
> Sent: Friday, June 25, 2010 11:53 AM
> To: [email-masked]
> 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.
> 
> "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.
> 
> 
> >> Specifically, as a native app developer, there is no good (secure)
> >> way to distribute the client secret without it being compromised. Any