Monday, January 20, 2014

Apple App Store Rejects Web-Based Login Applications

I'm a big believer in federated logins- when smaller apps delegate logins to a well-known & trusted third party (like Twitter, Facebook, etc). This is partly because I'm strategically lazy (and a good auth system is not easy), but primarily because I believe the "yet another password" or "password hell" issues that users face are very real. Every time you ask a user to remember another account and password, there's a couple of common reactions:

  1. The user will simply walk away (most common)
  2. They will create an account, but they will reuse a password they've used elsewhere
  3. They will create an account and a unique password, but will have difficulty remembering it and will:
    • Write it down somewhere (!)
    • Use a ridiculously simple password
    • Forget it and depend on password recovery later on
Sure- there are the power users that have mnemonics or other patterns to create memorable and secure passwords, but that's exceedingly rare. So with that said, I tend to favor asking a user to use a login that they're already likely to remember. This relationship is even better when the big guys, like Google, already offer a battle-tested platform complete with great add-ons like 2-factor authentication.

So imagine my surprise to see that Apple is rejecting apps that use federated authentication!

When apps delegate logins to a third party, the most common (and secure) method is to send the user briefly to the third party website. The user logs in (if they haven't already), and the third party vouches for the user back to the App.

So what's the problem? To make this work (securely), you have to bounce the user out of the app briefly- otherwise, the app would have to broker that conversation:

This is bad for everyone involved. Best case scenario is that the app has to deal with the responsibility of touching that password. Worst case? The app can now use your password buy movies from Google for you to watch together.

So this is where it runs afoul of Apple's "I want it to all be pretty and mine" requirements:
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy" button that goes to a web site to purchase a digital book, will be rejected
And this catch-all gem:
10.6: Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good it may be rejected
It'd be one thing if they just used it to enforce their already questionable App Store-only purchase requirements, but they're using this premise to reject federated logins as well. Taking a less cynical view, I can also see why the experience is less than ideal; having everything be one seamless motion would be idea. Unfortunately, until Apple bakes in generic federated login capability into iOS, there really isn't much alternative.

To be fair, Apple does now offer the Social Framework that allows Twitter and Facebook federated logins. It's better than nothing, I suppose. For now, developers will be left to weight using those versus rolling their own auth system and punting the problem to the user. I mean, you're already in password hell, right? What's one more?

Not talking about any app *I have* submitted, of course, because that would be against the draconian NDA that Apple forces upon developers.

No comments: