When I read a post that John Gruber wrote today about OAuth in native Twitter apps and how much of a poor user experience it is/will be, I had to dig deeper into the article. On first read of the article, I disagreed with him as I thought he missed a very important point about security, but upon re-reading it, he did identify one of the major issues with how OAuth (and other types of service authentication) is done on iOS, in particular.
Developers can alleviate some of the context switching by using an embedded web view inside their native app for the OAuth authentication handshake, but at that point, why not just use xAuth and simply allow the user to enter their username and password in a native dialog box? So long as you remain within the app, there’s no security advantage for OAuth in an embedded web view over xAuth…
This is something that most users are unaware of when entering their credentials in any iOS app. As long as you are in the app, even if the page says Facebook, Twitter, Dropbox, etc. and you’re not running an app from these companies, the app can capture your username and password. Some companies ship their libraries to developers in a form that doesn’t let the developer modify the source code, but that offers zero protection from a malicious developer that wants to steal usernames and passwords.
I’ve seen one application launch Safari, ask you to login to Facebook and when done, returns you to the app. From a security point of view, this is the ONLY way to ensure that the application doesn’t capture your credentials (provided that you trust that Safari isn’t stealing your credentials). Any embedded web view offers no guarantee that the app isn’t hijacking your credentials as the app can walk the hierarchy of views and grab info; in a kiosk I worked on, we presented web pages, but I modified the web pages before displaying to change the credit card field to a password field to mask the numbers; this type of modification of web data is quite easy when a developer controls the entire app.
Should you be worried? That all depends. Do you use different passwords for every service? If not, consider using 1Passwd. Yes, it may be a pain to enter the random password on a mobile device, but if some app got access to the password you use on all your sites, the risk is great. Are most developers honest? Yes, but bugs in the code could put your password at risk. Also when I tried out apps for Google Voice, I had some strange feelings about an app, so I ran my iPhone’s networking through Charles Proxy to see where the app was connecting; it was connecting to a site that wasn’t Google. I had no idea if my Google Voice password (which is my Google password for email) was going to some lone developer’s server. Based on the developer’s posting in various forums, I didn’t trust his app with my password.
Should users be inconvenienced by having an app launch Safari, enter credentials and then go back to the app? Personally, as someone a bit paranoid about security, I think it is worth the one time inconvenience (per app). The average user may not think this way. However, if the user was better educated in the app indicating that for security purposes Safari will be launched, that may mitigate the issue.