In my relatively uneducated opinion, one major security benefit of using OAuth for client apps is that the client is only provided with an access token for the service and not the user's password. If the access token and consumer secret are compromised, then either can be revoked, either by the user (in the case of the access token) or by the provider (in the case of the consumer secret). In most provider implementations a request authorized with an access token is not allowed to update certain aspects of the user's account, such as the password.
If the client requires the user to input their password (for example, Google's ClientLogin protocol) and the client becomes compromised, then the password is exposed, allowing full access to the user's account. Game over. In my mind, this is *the* reason I want clients I use to use OAuth rather than a username/password login scheme. I would be happy with another token-based login scheme as well, but OAuth is a perfectly good, publicly reviewed standard and I see no reason why a provider should cook up a bespoke token-based authorization scheme when OAuth is available and works for clients. Ethan On Fri, Jul 24, 2009 at 9:24 AM, Zhihong <zhih...@gmail.com> wrote: [...] > > In my opinion, you don't add much security by using OAuth on client > because there is no way to keep the secret. However, many people still > do it. It may raise the hurdle for hacking a little, but not much. > [...] > Zhihong > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
