>>Until that happens, no user or developer is going to be happy with
>>OAuth in a desktop or mobile application. Sorry to be blunt, but the
>>user experience sucks when you're using OAuth outside the confines of
>>a web browser.

Not necessarily.
A UIWebView (in an iPhone app) can provide a good user experience for
OAuth login
Right now, the OAuth UI is pretty bad (see bug 395). However, if that
bug is fixed, the user experience should be fairly good.

>>>It is even more likely that a malicious app would direct you to a phishing 
>>>site during the OAuth flow

Yes, this is a good point. Phishing, keystroke logging etc. are some
of the attack tactics that a malicious app can use.
A malicious app can do malicious things and OAuth wouldn't protect the
user against every possible attack.

However, OAuth can help in some other circumstances (with non-
malicious apps, that may have insecure code).
For instance, a popular iPhone Twitter client used to save the user's
(unencrypted) password on the device (NSUserDefaults).
Presumably, some Windows and Mac Twitter clients also do similar
things and save the unencrypted password on the machine. Some
probably  send the unencrypted password over HTTP for every user post.

OAuth can help protect the user's password in these scenarios.
Obviously, the user (of an app with insecure code) is still at some
risk because the access token may be easily retrievable from the
machine, but it is far more difficult to exploit an access token

The bottomline is that it is possible to write good secure code with
basic auth, but several developers don't do that.
OAuth mitigates the risks, but it doesn't eliminate all risks.
So there is some value to OAuth.


Reply via email to