The problem is that on mobile platforms is extremely easy to simulate
a regular browser to the point a user cannot tell the difference.
Training users to expect security because it looks like a browser is
even worse than telling them to give their passwords to native apps
but be careful as to which apps they use.

Native apps can do many things browser-based apps cannot. Trying to
extend the OAuth metaphor to native apps only works when you give up
the idea of not having to give passwords (or you give up the idea of
having decent UX by saying that the user has to open a separate
browser manually).

OAuth on native apps is useful for:
- a way to provide fast-but-secure connections (https on small devices
has a significant performance impact)
- a way to help native apps not have to save passwords locally.
- a way for the service provider to identify (and block) apps.
- a way for the user to revoke authorization on a per-app basis.

Forget about using OAuth on native apps as a password-less
authorization mechanism, because no matter how hard you try, the
security holes are to big to close properly.

Because, as that Fire Eagle document proves, the only way to prevent
app developers from intercepting browser calls is to beg developers
not to intercept browser calls.

On Oct 13, 11: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

Reply via email to