OAuth for native apps is the worst of all worlds. It’s horrible to implement, it’s a horrible user experience and nobody understands it. That’s a little bit hand-wavy, true. Nobody who actually uses your software actually knows what the hell this OAuth business is nor do they care.
Yes, when they use OAuth they are presented with a page that appears to be branded similarly to your website. A website that, despite what all the big cats seem to do, may actually seriously and honestly strive to protect your personal data. So it’s possible that this branding may well make the user of a native app feel more comfortable submitting their login information. After that is done the native app receives a token that can then be used to communicate with your service.
The problem is that there is absolutely nothing here that precludes native applications from acting as phishing terminals. Nothing. In fact it is completely possible that a malevolent application could use genuine OAuth authentication most of the time but, very occasionally so as not to draw attention, present a phishing attack instead.
Craig Hockenberry went into great detail in his piece about this today — In-App Browsers Considered Harmful. If you’re not a nerd you should be aware that the “Considered Harmful” title is not by accident. This is the language used when developers are warning other developers from following a common practice. You don’t use it lightly. Unless you’re using it lightly because it’s dumb. This is not dumb.
Craig booted his app out to iOS Safari in order to do the OAuth dance. He did this because despite being more steps for the user to take it avoided the issue of trust I outlined above. A user didn’t need to trust Iconfactory or Craig. They needed only to trust Apple. Which is a fair assumption since using an iPhone implies a fair amount of trust in Apple in the first place.
Turns out Apple rejected the app because they thought the user experience of going through Safari to obtain an OAuth token was too onerous. First, yes, it’s completely stupid that’s the way things need to work. Second, “user friendly” doesn’t mean what it appears Apple thinks it means in this case.
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.
“That’s a shitty experience” is, as far as I’m concerned, a decent reason for rejecting a submission to the App Store. What happened here was an application that didn’t take a short-sighted and myopic view of what a “shitty experience” really means was punished for doing so. It is not in Apple’s interest, or for anyone serious about the platform, to enable or accept a culture where phishing attacks are not only possible but the potential is encouraged by the platform vendor in the name of fewer clicks and less task-hopping.
Yes, it’s a pain in the ass to do it. No, the solution isn’t to reject apps that take the time to do it right and, more over, will take it on the chin from Apple and their customers in order to be as transparent, secure and honest as possible.
The issue is OAuth. It’s cumbersome, difficult to implement well and requires hoops to be jumped. Rejecting a developer for doing the right thing by their customers (who are all Apple customers) encourages a culture of not giving a fuck. That’s never turned out well in the long run.