Third Party Touch ID Implementation

How Apple might implement a 3rd party Touch ID API

With iOS 8 around the corner I can’t help but speculate what we’ll see. When Apple introduced Touch ID with iPhone 5s last year many people were clamoring for 3rd party integrations. How convenient would it be to sign in to your banking app with the speed an accuracy of Touch ID?

Apple implemented TouchID in such a way that this is seemingly impossible without breaking the secure enclave of the A7 chip. Perhaps if Apple provided developers access to the hash of user’s fingerprints, those could be stored in a web-service database and validated against much like a password. Well, that’s not possible as fingerprint data is was very intentionally made unavailable to the software. Apple themselves cannot even access the mathematical representation of your fingerprint. So, where does that leave us?

Let’s take a step back and ask ourselves what we actually need from Touch ID. Do we need the fingerprint hash? No. In fact I don’t even believe that we even want it. What we need is to know is that the fingerprint scanned is one of the enrolled fingerprints for the device, a simple yes or no will suffice.

Once that yes or no is received the developer can act accordingly. What might all of this look like?

A new method on UIApplicationDelegate could allow an app developer to let iOS know if they require Touch ID before proceeding.

- (BOOL)applicationDoesRequireBiometricAuthentication:(UIApplication *)application;

Returning YES tells iOS to present a screen prompting the user to scan their fingerprint.

Once fingerprint scanning has completed, whether it was valid or not, iOS calls the familiar delegate method below.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions;

But a new launchOption key is included that says whether or not the user completed the biometric authentication successfully.

In the event that the app was simply in the background a new delegate method can be implemented.

- (void)application:(UIApplication *)application didReceiveBiometricAuthenticationResult:(BOOL)passedAuthentication;

And the rest is on the app developer to decide what to do with these results. In the event that you’re writing an app that does not require any other form of authentication you can present the user with their content. Such an app might be personal journal where the data is local or synced with iCloud.

In the more likely case of credentials being required to authenticate with a web-service like a banking app, more care must be taken. And you must dynamically decide whether or not Touch ID should be required at launch. Consider the following hypothetical user journey.

1. User installs banking app
2. User launches app
3. App checks for cached credentials
4. Cached credentials not found
5. App tells iOS that Touch ID is not required
6. User is prompted with a login screen
7. User logs in
8. App caches credentials in the user’s Key Chain
9. App asks for permission to use Touch ID for future logins
10. User grants permission
11. User quits app
12. User returns to app and is presented with Touch ID screen
13. User scans a valid fingerprint
14. App is informed that Touch ID authentication succeeded
15. Apps retrieves cached credentials from Key Chain and authenticates the user
16. User sees their content

In the event that Touch ID authentication fails the app developer should present the standard login screen for the user to enter their credentials.

With my understanding of the system I believe that this could be a secure approach to using Touch ID with third party applications. Currently Apple provides similar capabilities with authorizing purchases via the App Store and iTunes. Maybe the API could be extended to allow developers to present the Touch ID screen anywhere in their app like iTunes and receive a yes or no response as well?

Header image courtesy of Craig Sunter https://flic.kr/p/gd7MGG