The distinction is that the client_secret tends to be a global secret, and there is little ability to protect this type of secret in many common means of application distribution.
For example, a iOS app that is shipped through iTunes certainly has access to reasonably secure storage via KeyChain for secrets issued to the application at runtime, such as the referesh_token, but it can't do a good job of protecting the client_secret, since this must be embeded in the binary that is distributed to everyone. -cmort On 5/31/11 2:17 PM, "Dave Nelson" <[email protected]> wrote: This issue has likely been discussed "long ago", but I'd like to potentially re-open the discussion. > o Native applications that use the authorization code grant type flow > SHOULD do so without client password credentials, due to their inability to > keep those credentials confidential. I understand that, in a strict sense, a software component running in a non-embedded environment cannot be guaranteed to maintain the confidentiality of credentials entrusted to it. On the other hand, I think this proscription may go too far. All security is a matter of providing sufficient counter-measures to identified attack vectors, and I believe that native applications probably *can* keep secrets well enough to resist the types of attacks they are likely to be subject to in certain specified use cases. Perhaps the "SHOULD" wording leaves enough room for implementations with credential hiding mechanisms that are deemed appropriate in a given use scenario to include the use of a client password. I think it would be more accurate to say that native applications SHOULD NOT include the client password in the authorization grant type flow, *unless* the design of the application can provide a sufficient level of protection for said password storage to meet the risks identified in association with the deployment scenario. Thoughts? Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
