Using Face ID in financial apps (and most apps!) is one of the most secure ways to authenticate users within iOS, making the login experience more efficient, user friendly, and helps bring users back to your app. Using Face ID best practices in financial apps means you’ll use the device’s front-facing TrueDepth camera on the front of an iPhone X, iPhone Xs, or iPhone Xs Max (with the device passcode serving as a backup) to access secure data in the iOS keychain.

Face ID allows users to have one of the most unique “passwords” to secure their financial accounts—their own face—without having to worry about insecure practices such as writing down passwords or using complex passwords that are difficult to remember. All they need to do is continue glancing at their phone during the login flow to gain access to their account information.

Here’s where we get into the actual Swift code of how Face ID works, and how to implement it correctly.

Two Ways of Implementing Face ID in Financial Apps

Apple’s Local Authentication APIs

There are two ways of implementing Face ID in apps—either through Apple’s Local Authentication APIs, or through access control on the underlying system keychain. Local Authentication lets you decide when to show the Face ID prompt through calling the LAContext function:

evaluatePolicy:localizedReason:reply:^(BOOL success, NSError *error).

If the success Boolean returned is true, then the user has authenticated successfully with Face ID and developers can perform authentication manually.

Using Local Authentication is easier and has its benefits, but there are downsides to consider as well. Tools available on jailbroken iOS devices can bypass Local Authentication by sending a success signal to Apple’s APIs, and there have even been reports of regular, non-jailbroken device manipulation using similar techniques.

Obviously, a trained attacker would have to have direct physical access to the phone, in which case there are bigger issues at play than overriding Face ID, but it all depends on the level of risk acceptable while designing a Face ID strategy. As with any authentication method, Face ID best practices imply that a thoughtful risk-rewards analysis about security vs user experience should be considered.

Using Keychain Services

For high risk financial apps with sensitive data, it is generally agreed to be best practice to use Keychain Services. This takes a little more time for iOS developers to set up because they need to write a keychain wrapper themselves, but the wrapper is easily portable and there are well-written examples online.

For high risk financial apps with sensitive data, it is generally agreed to be best practice to use Keychain Services. Developers can implement Keychain Services directly by using an API of C functions, but many opt to write a Swift wrapper around the keychain API for better code reuse, or utilize an existing library that already does this. Apple has some sample code for Swift 4.0 including a wrapper on their developer website. (Note: Even though this example has a disclaimer about it no longer being updated by Apple, it’s stilll a good example.)

It’s critical that developers set up access control on the keychain so that when users attempt to retrieve a secure item, they must authenticate with the device passcode (and therefore, Face ID when enabled). By providing a prompt message to keychain query parameters, the Face ID prompt displays itself any time users try to retrieve their secure item.

In some ways, once the wrapper is implemented, it could be argued that this is even easier and cleaner than Local Authentication. Consider the following code:

let savedPassword = AccessControlWrapper.get(username, prompt: "Login to view \(username).")

With this implementation, thieves of iOS devices will have a more difficult time gaining access to any securely stored data, since access to the keychain would require device authentication.

Now that the basis of Face ID is covered, there are still many different scenarios that might occur while developing a Face ID in financial apps strategy. Let’s dive in.

How can users enroll in Face ID in my app?

Face ID best practices indicate that developers shouldn’t assume a user wants Face ID enabled in their apps, no matter how much we might feel it’s obviously easier than using passwords. While it’s true that most consumers are not particularly diligent with the security and complexity of their passwords, many are, and prefer them to biometric authentication.

The best practice is to have a prompt upon registration or a first successful user login of your app, asking the user if they want to opt into Face ID. This prompt should be made in a way that succinctly explains the strengths and weaknesses of Face ID to the user, and directs them to a section of the app where they can edit this setting at a later time if they so choose.

If the user opts in, it’s necessary to save their credentials, or token, in order to have Face ID successfully authenticate the next time they log in. Depending on the app’s level of risk, this is where developers could store the password, encrypted, in the access control keychain. The username is normally stored in NSUserDefaults, or right in the keychain if it’s being used already for the password.

It’s important to note that NSUserDefaults is just a file with key value storage. Values in User Defaults can easily be discovered by an attacker. In most cases, it’s safe to take that risk, as the username is not considered as sensitive as a user’s password. (This is the rationale behind the “save username” feature apps commonly offer.)

There should also be another area in the app—usually the settings screen—where a user can toggle Face ID on or off. This ensures that, should a user change her mind about using Face ID, it’s easy for her to change the preferred authentication method.

How do developers allow users to enroll in Face ID once they’re already logged in?

A user flow can get disorienting if a user did not initially enable Face ID the first time they logged in, but wants to enable it later. If they want to turn on Face ID for their next login, how do we save their user details if we didn’t store them previously during their initial login?

Some developers suggest storing the username and password for every user who logs in on a device, with a flag that determines if the user has enabled Face ID or not. You might be able to get by with this level of storage on low risk apps, but good security practices dictate that we should only store what is absolutely necessary when it comes to user info, and only with the user aware of what is being stored and why.

So how do we get the user’s credentials if they choose to turn on Face ID? The best practice around this scenario is to have the user re-authenticate their account. With a successful authentication, the app can store user information going forward, similar to how it would handle a first-time login. (With the above mindset, developers should make sure to delete user data stored if the user decides to turn off Face ID.)

What are Face ID best practices for managing multiple users on a single device?

A scenario many developers may encounter when implementing Face ID is that a user may have multiple accounts or users on the same device using your app. This is especially true now that all devices in the iPad lineup have a Touch ID sensor or Face ID TrueDepth camera for authentication, and iPads are commonly shared among multiple users in a household. Despite this, there can only be one Face ID user per device, so it’s critical to demonstrate this clearly to the user.

The most logical approach to this problem is:

1. Once prompting for Face ID, apps should include in the prompt message the name of the account they are logging into, in order to clearly demonstrate which account the Face ID authentication is associated with.
2. When logging into an account that is not the Face ID–associated account, ensure that users have the ability to switch the option for Face ID authentication to their current account. Apps can accomplish this by checking the username entered against the username stored and, if necessary, display appropriate messaging asking if they want to change their Face ID authentication to the current account.
3. Make sure the toggle displaying the Face ID enabled state is synced to the current account, not to the status of Face ID on the phone. Make sure the Face ID username is the same as the username currently logged in and, if not, then the Face ID toggle should be set to off. Furthermore, if the user then enables Face ID, apps should give the user similar messaging about changing their Face ID–associated account.

When should I have the user authenticate?

Depending on your acceptable risk, it may still be necessary to have areas of your app that are still behind a standard password wall. It might be safe for read-only data to be secured by Face ID—like recent transactions and balances—but more sensitive areas of the user experience may require further protection. This is especially applicable when financial apps allow for transfers of funds or running payroll, for example.

Face ID can be risky for secure areas because the user can use their device passcode as a backup. Many iOS users still depend on simple four-digit PINs to unlock their devices, which are usually less secure than the account password and significantly less secure than biometric facial authentication with Face ID. Face ID can still provides users with easy access to core, regularly used features in the app—features that are important to users across the board.

The Takeaway of Face ID Best Practices in Financial Apps

Overall, Face ID is a feature that improves the iOS user experience within many third-party iPhone or iPad apps. It can be difficult to implement due to the significant number of edge cases and unusual situations that may occur, but with a comprehensive Face ID strategy, the actual logic is fairly simple.

Without much effort, developers can convert existing app authentication methods to make use of the technology. With a good Face ID strategy, even highly sensitive financial apps can minimize risk while providing added convenience to their mobile users.