Face and fingerprint ID login is a convenient, seamless way to gain app access on a mobile device. Instead of typing in a lengthy, hard-to-remember username and password, many apps allow you login with just a quick scan of your face or fingerprint (also known as biometrics).

It's a desirable feature for both our end user and the Patients Team here at Alto — we want to make it as easy as possible for users to log in while also performing more frequent authentication checks. Improve the user experience and the security of our app? Sounds like a win-win.

As an engineer, implementing biometric login might seem easy, as mobile devices already capture, manage, and encrypt biometric data and expose APIs for app developers like myself to initiate a biometric scan. All I need to do is call that API and wait to hear if the scan is successful or not. What isn't as simple, though, is figuring out what to actually do with a successful biometric scan response. What does a successful scan mean, and how does that relate to the username and password credentials that users currently use to access our app?

This post walks through the decision points we encountered while implementing biometric login and how our healthcare privacy concerns influenced the final implementation approach.

First, some context

Prior to implementing biometric login, the only way for users to access the Alto app was with email (username) and password. A valid email and password generates a session, which expires at some frequency. Once the session expires, the user must re-enter their email and password to regain access to the app.

From the beginning, we knew that biometrics would need to be built with our existing email and password session management in mind. This is made clear in the Apple developer docs: "Use biometrics as a supplement to something you’re already doing. Don’t depend on biometrics as your only authentication option."

Our goals:

Make it easier for users to login. Nobody likes typing in an email and password — especially on a mobile app. Our goal was to reduce the number of times a user must enter their email and password.

Enhance the security of our app using more frequent authentication checks. As a healthcare app that displays Personal Health Information (PHI), conducting more frequent authorization checks decreases the likelihood of PHI becoming exposed to an unauthorized third party.

Have the ability to revoke biometric access from a particular user. Similarly, we want to be extra careful to ensure that if a device is lost or stolen, we have a fallback plan to invalidate a user's session and protect the user’s PHI. For email and password initiated sessions, this happens when a user changes their password, as any change in login credentials will invalidate all active sessions for that user. We needed a similar contingency plan for biometric login.

Technical design

There are several ways to use a mobile device's biometrics to authenticate a user, with varying degrees of security.

No server-side authentication. Simply integrate with the device's biometrics as an extra layer of authentication. If the biometric scan is successful, let the user proceed into the app.

Pros:

• Easiest to implement

• Provides an extra check and gives your app a sense of modern polish

Cons:

• No server-side validation means that nothing is being validated against your system, so this is not a good substitute for account authentication. Therefore, even if you add this check, the user should still be prompted to re-enter their email and password at the same frequency as before.

• Given this, this approach wouldn't help us reach our goal of reducing the number of times a user must enter their email and password.

This approach is a good fit if your application already has an existing login and session management system, and you want extra authentication checks throughout the user's session without modifying any other part of the system.

Tie biometrics to our existing email and password authentication. Use the user's biometrics to unlock an encrypted version of their email and password credentials. When a user sets up biometric login, store the user's login credentials within the device's keystore — the keystore will automatically encrypt the credentials. After a successful biometric scan, retrieve those credentials from the keystore and send them to your existing login API.

Pros:

• Still easy to implement, no backend changes needed

• Biometric scan can be used in place of entering an email and password

• Changing email and password credentials will revoke biometric access: if a user changes their credentials, their biometrics will access stale credentials and fail to login. (This is somewhat of a con as well — it provides a poor user experience, but it's an edge case that should happen infrequently.)

Cons:

• There is still only one way for a user to authenticate server-side, but now two ways to pass server-side authentication — essentially weakening your app's existing account security.

• This approach effectively hands out internal login credentials to third party storage. While not a huge risk considering a device's secure storage is encrypted and trusted by most users, it’s not necessarily a best practice either.

This approach is a good fit if your application doesn't contain sensitive data, and your goal is to make it more convenient for a user to login by replacing email and password with a biometric scan.

Create a separate authentication mechanism for biometrics. Introduce a new authentication mechanism specifically for biometrics, resulting in two independent forms of server-side session authentication: email with password and biometrics. The implementation could look like generating a keypair or a shared secret to save and validate against the server whenever a user attempts to login with biometrics.

Pros:

• Biometrics is now tied to its own secure server-side authentication mechanism, which means it can be used independently of email/password (or even replace it, if you choose to).

• Two layers of authentication adds security to the app. Not only does a user need a valid email/password session, they also need a valid biometric session.

• It provides fine-grain control over a user's biometric session. You can invalidate a user's biometric session by invalidating the public key and can even invalidate a biometric session without impacting an email-and-password session if needed.

Cons:

• Requires building and maintaining a separate authentication mechanism

This approach is a good fit if your application contains sensitive data (e.g. PHI or financial information), and your goals are to make it both more convenient for a user to login by replacing email and password with a biometric scan while also strengthening the security of your account management system.

Because we are a healthcare company dealing with sensitive data, we chose this last path. It required greater engineering investment, but we agreed it was imperative that we maintain a secure system while introducing biometric login for users.

In part 2, we talk implementation details, including the library we used, code snippets, and questions to consider before you get started. Interested in learning more about engineering at Alto? Follow us on LinkedIn.