> I completely agree with you regarding not being able to authenticate a native > client.
I suggest you read the security considerations draft to make sure this is correct and points out the issues -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Kris Selden Sent: Monday, April 04, 2011 12:10 PM To: Skylar Woodward Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth I completely agree with you regarding not being able to authenticate a native client. The problem with web flow is the user experience is bad for a native app. Why does this matter? Because of competition - if competitors use a user friendly but less secure method and the end user does not know it is bad for them, then because of market forces you have to do the same. As a startup developer, I cannot tell the business side that our UI has to be worse than their Facebook app, Twitter client or Instagram on their phone because that isn't secure. They're going to look at me like I'm crazy. If the end user is ignorant, educating them comes at too high of a price for a startup. The end user cares about their safety but assumes that big companies are the bar for security. On Apr 4, 2011, at 11:21 AM, Skylar Woodward wrote: > 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 > _______________________________________________ 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
