The nice thing about OAuth on a native client is that it allows a non-evil client the option of not storing the cleartext password in a recoverable way on the client.
This way if the device on which the native client lives is compromised, the attacker won't be able to obtain the cleartext password, unless it was compromised during the OAuth login process. Sure, the attacker will get the token, but they won't be able to get the cleartext password and log into other unrelated services with it.
> The nice thing about OAuth on a native client is that it allows a non-evil client the option of not storing the cleartext password in a recoverable way on the client.
Why does this matter?
If you compromise somebody's desktop or phone, you're in an extremely privileged permission. This means that you can spy on their authentication processes while they are occurring. Including processes that occur on the web.
You can also read the user's keychain, containing the saved passwords for the OAuth service that you're trying to protect.
* That all applications that run unattended store the user's service password?
* That the user change the app password on the 2 desktops and 3 tabs/phones they use because they rotated their service password?
* That users should NOT be able to revoke or change an application's access rights without changing their password?
* That applications *shouldn't* request the minimum privileges they need to do their job?
* That it is NOT a good thing for a user to be able to log into their service provider and check what applications are connected with the service?
You're thinking in an extremely binary and absolutist fashion. Systems have lots of failure modes.
> If you compromise somebody's desktop or phone...
This is my day job. After compromise, the first thing is the "smash and grab" where you loot as many credentials as possible off the machine with a bunch of scripts. If there's stuff in a browser's built-in password manager, win. If your app stores a password, win.
> You're thinking in an extremely binary and absolutist fashion. Systems have lots of failure modes.
You seem to be thinking of applications as if they were web sites.
> After compromise, the first thing is the "smash and grab" where you loot as many credentials as possible off the machine with a bunch of scripts. If there's stuff in a browser's built-in password manager, win. If your app stores a password, win.
So they smash and grab the keychain, which holds the master passwords to the services granting OAuth tokens.
You might have me vaguely convinced if you were advocating for XAuth+OAuth, in which case it would provide a bare modicum of additional security without negatively impacting user-experience at all.
I hadn't run into xAuth before. It looks like a reasonable way to make the grant process not such a Desktop UI cluster$%$^ - which I totally agree that it is.
Re: the keychain thing, again, it depends on the level of compromise, whether the machine is unlocked, what platform you're on and whether the creds are in there.
And yes, with enough access you can keylog, man-in-the-browser or "desktop phish", but it's higher risk for the attacker and requires maintaining longer-term access.
But if your app stores passwords the user instantly loses.
Failure modes matter. A kind of parody version of how I see your argument is: "Sites shouldn't bother hashing passwords, because an attacker with a shell could just modify the site's login process to capture passwords".
Depends on the level of compromise. If an attacker can interface to the screen and keyboard, or access other process's memory to directly read the key from there, or spoof the SSL library so you get cleartext network transmissions, sure, they can steal a lot of data.
But if the attacker only has access to the filesystem, then it certainly matters whether the filesystem contains enough information to impersonate a user.
And there are things that people do to desktops that allow other people to access their filesystems. Things like cloud backup, sending your computer in for repairs, or selling an old hard drive. Sure, you should remove the hard drive or wipe it before you do any of these things, but a lot of people...don't. There are plenty of stories about that situation floating around the interwebs, but this comment is long enough...
Also, because the access token for each app is unique, you can grant different account permissions to your apps so you can in principle limit their access to your account.
Also there is more accountability. If an access token gets leaked or misused you at least have a chance of figuring out where it came from.
OAuth is usually a better choice for API authentication than username/password, even for desktop apps.
This way if the device on which the native client lives is compromised, the attacker won't be able to obtain the cleartext password, unless it was compromised during the OAuth login process. Sure, the attacker will get the token, but they won't be able to get the cleartext password and log into other unrelated services with it.