As I mentioned yesterday, phishing, keystroke logging are some of the
attacks that a malicious app can use with OAuth.
With these attacks, a malicious app can get the password.
Of course, in the case of basic auth, every app (malicious or good)
will always get the password.

However, as I also mentioned, OAuth offers significant security/
privacy benefits over basic auth - when it comes to non-malicious

I'm surprised that many OAuth opponents are unwilling to acknowledge
(or even discuss) this basic fact.


On Oct 13, 8:49 am, Craig Hockenberry <>
> To everyone who's suggesting to embed a web view in the desktop or
> mobile app, please go read this:
> <
> oauth_best_practice>
> Specifically, "... we insist that you must not use embedded rendering
> controls to present the OAuth process  ...".
> Phishing in a web view is incredibly easy with a little bit of
> JavaScript. From a user's point-of-view, entering their credentials
> into that built-in web browser is MUCH less secure than sending HTTP
> basic authentication over SSL.
> -ch
> On Oct 12, 11:45 pm, Ram <> wrote:
> > >>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.
> > Ram Hide quoted text -
> - Show quoted text -

Reply via email to