Open Feature Request: iTunes Auth

Problem

There are a lot of applications that would like to persist user state for one reason or another and right now there are two options:

Option 1: tie everything to the device identifier.

Option 2: implement your own authentication and registration mechanisms.

From an end user perspective both of these methods provide me with a less than optimal experience.

Option 1 is convenient in that I don’t have to provide up front information, but if I ever upgrade or change devices then all of my information is lost.

Option 2 solves the problem you encounter with with option 1 and even provides a way to access my information across multiple devices, but at a serious burden. Now I have to complete a registration process where you choose a unique username, password and probably an email address. Filling out registration forms on my tiny iPhone keyboard is never a great experience and when you are done you have yet another set of credentials that you have to keep track of. In addition, the second option is non-trivial to implement from the developer perspective and requires a decent amount of server code.

“iTunes Auth” would be an easy way for a developer to invoke the iTunes login dialog and then retrieve a unique token identifier when a user successfully authenticates.

The token would be unique to the application and user and would provide no information about the user. It would just be a constant identifier the developer could use to associate persistent data to.

Technical details

Below is an overview of the implementation I have in mind. It’s not extremely in depth, but should give you a pretty good idea of what the implementation would look like as an application developer.

First your application would prompt the developer to sign in. For most applications this would only need to be done once per device + application combo.

[AuthKit authenticateUser];

Which would bring up the standard login dialog:

iTunes Login

Once the user has authenticated your application might receive a callback similar to the one you get after registering for push notifications:

- (void)application:(UIApplication *)application didAuthenticateWithUserIdentifier:(NSData *)userIdentifier

With the user identifier being:

hash(Bundle Seed ID  + iTunes Username)

Where the hash function is something like sha256 and the Bundle Seed ID is an identifier that is unique to an application or group of applications. This way each developer’s application has a different identifier.

OAuth would be another options, but I don’t see Apple exposing this as a web-service outside the device due to the phishing concerns so I don’t know if it’s really necessary.

Security

The method described above doesn’t provide any information about the user to the developer so no personal information is exchanged.

Even though the hash for that user+bundle identifier will always be the same, each application will have a unique hash for that user. This way it is impossible to determine if a user is the same from one bundle id to the next preventing any concern about libraries collecting analytics about user habbits across applications.

Phishing could become a concern since an application could present a login dialog similar to the actual dialog, but this is currently possible with StoreKit; therefore shouldn’t create any additional concern.

Summary

iTunes Auth would provide a simple solution to allow developers to easily persist user information without having to implement complex registration systems while giving users the ability to use the credentials they are already have. The unique nature of the user hash would allow developers to consistently identify a user without exposing user information limiting security and privacy concerns.

Advertisements