There is an ongoing meme that OAuth provides little or no security benefit in client applications. I believe that this assertion is incorrect.
Client applications are applications that run on my computer or phone and so are implicitly "trusted" by me. (I use quotes because I think that the assumption of user trust for client applications is wrong, but that is neither here nor there.)
I already addressed this somewhat obliquely in my OAuth FAQ Part 1 and Part 2, but it bears repeating, which I just did on the OAuth Google Group here.
To quote myself:
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.
In other words, developers should use OAuth in their phone and desktop applications and users should demand it. I do.