In-App Browsers Considered Harmful
How many apps on your iPhone or iPad have a built-in browser?
Would it surprise you to know that every one of those apps could eavesdrop on your typing? Even when it’s in a secure login screen with a password field?
[…]
There is always a tradeoff between usability and security. Doing the OAuth token exchange with an in-app browser makes it easier for a user to login, but they’ll have no idea if their personal information was captured. That is why Twitterrific did its token exchange in Safari, even though it’s a more complex user interaction and a more difficult technical implementation. As a user, I know that there’s no way for my login to be compromised when the transaction involves Safari.
Unfortunately, Apple’s current App Review policy does not agree with this recommendation or with Twittterrific’s previous implementation. This is why our update for iOS 8 was delayed—it was the first time since the launch of the App Store that we haven’t had a new version on release day.
Update (2014-10-09): Guy English:
Less tapping around and not leaving the app? Yes. That’d be a good thing. It appears, however, that Apple rejected this application because it strove to do the right thing for users over the long term — establish a level of trust and transparency vetted through Apple’s own web client for the platform.
3 Comments RSS · Twitter
OAuth token exchanges in in-app browsers should not be allowed by Apple's app reviews. They defeat the whole purpose of OAuth. You might as well just give the app your login credentials.
Also, this is one of the reasons why I still think that Android's back button is a good idea, despite of the drawbacks: it allows an app to open a third-party browser, which the user can then leave and get back to the originating app by hitting the back button.
Craig’s criticism is based on a mistaken understanding of the threat model.
Once a malicious app is installed, it's already “game over” as far as security is concerned.
An app controls the full device screen, so the malicious app can easily simulate switching temporarily to Safari if the app really is intent on stealing the user's password while pretending to do OAuth sign-in. Sign in via the external browser is no more secure than is a built-in browser view.
In practice, a malicious app wouldn’t need to bother with a web view, since most users are quite happy to enter their account credentials into any text fields displayed on the screen that are labeled “username” and “password”.
The actual benefit of OAuth, which applies with both in-app browsers and external browsers, is that non-malicious apps don’t need to touch or retain account credentials. Instead, apps receive and hold narrowly-scoped tokens. So apps will not accidentally store user credentials insecurely, and interception of API requests from the app cannot be used for arbitrary access to all of a user’s account data.
Ideally, Apple would support OAuth 1 and 2 tokens and provide token exchange and authorized requests for any third-party API provider. Apple so far hasn’t shown interest in that kind of cooperation.
[…] Apple’s store guidelines do not actually document this rule, which is perhaps why Hockenberry referred to it as “Apple’s current App Review […]
