Re: [OAUTH-WG] Flowchart for legs of OAuth

[Skylar Woodward <[e-mail]>]

Having worked many years with native Internet consumer software applications, and having worked in those teams in attempt to secure client secrets (be they keys or obfuscated dynamic algorithms), I can say with reasonable confidence that it is impossible to secure client credentials for publicly available applications (where the same credential is shared against all instances of the application).  Both iPhone and PlayStation represent some of the most formidable efforts to secure secrets or data in publicly distributed consumer products.  Systems on these have been successfully broken and this will continue to be the case.  Even if someone has a new technology to propose that they think can prove this wrong, there is no reliable record of success for hiding secrets in the field. We should assume any system distributed for public review can be reverse engineered, and secrets obtained.

I propose that for the sake of this discussion, we continue with the assumption that no native apps with public distribution are able to have client secrets.


(Btw, Kris seemed to be suggesting that users could be prompted to enter a (unique?) app ID and client secret, but this would complicate usability, working against the goals of OAuth in the first place. I'd agree - if native app users had to enter a custom client secret, they might as well obtain their own private access token and enter it instead, by passing OAuth completely).

On Apr 4, 2011, at 2:02 PM, Phil Hunt wrote:

> On 2011-04-04, at 10:47 AM, Kris Selden wrote:
> 
>> A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once.
> 
> My understanding (and I'm not an iOS expert) is that each iOS application has a secure keystore where the client credential could be stored. I am told this is fairly straight forward. The client app would issue a call out to the external safari browser for the authorization with a redirect back to the app registered (local redirect) such as myapp://authorization_code