Biometric Authentication in Mobile Apps: Face ID, Touch ID, and Beyond

Biometric authentication has become the default login expectation for mobile users. Face ID, Touch ID, and Android fingerprint authentication offer a compelling combination: faster than typing a password, more secure than most passwords users actually choose, and frictionless enough that users don't disable it after the first week. Getting the implementation right requires understanding what biometrics actually protect — and what they don't.

What Biometrics Do and Don't Protect

The most important thing to understand about biometric authentication on mobile is what's actually happening under the hood. When a user authenticates with Face ID or fingerprint, the biometric data never leaves the device's secure enclave. Your app receives a simple success or failure signal — it never sees the biometric data itself.

This means biometrics on mobile are a gate to local credential storage, not a standalone authentication mechanism. The flow is:

1. User authenticates with biometrics
2. Secure enclave confirms match and releases a stored credential (token, key, password)
3. App uses that credential to authenticate with your backend

What biometrics don't protect against: a compromised device where the OS has been modified, a user who has been coerced, or a stolen authentication token that was extracted before the device was locked. Biometrics protect the login UX — they're one layer of a defense-in-depth strategy.

iOS: Local Authentication Framework

On iOS, biometric authentication is handled by the Local Authentication framework. The primary API is LAContext, which provides:

• canEvaluatePolicy(_:error:) — checks if biometrics are available and enrolled
• evaluatePolicy(_:localizedReason:reply:) — triggers the Face ID / Touch ID prompt

For secure credential storage tied to biometrics, use the Keychain with the kSecAccessControlBiometryCurrentSet or kSecAccessControlBiometryAny access control flags. This stores credentials that can only be retrieved after successful biometric authentication — the OS enforces this, not your app code.

Critical detail: BiometryCurrentSet invalidates stored credentials if new biometrics are added to the device. BiometryAny does not. For high-security apps (banking, healthcare), use CurrentSet so that adding a new fingerprint doesn't inherit access to existing credentials.

You must add NSFaceIDUsageDescription to your Info.plist — App Store review will reject apps that use Face ID without this key.

Android: BiometricPrompt API

Android unifies fingerprint, face, and iris authentication through the BiometricPrompt API (introduced in API level 28, significantly improved in 29+). This replaces the older FingerprintManager API which you should not use in new code.

Key components:

• BiometricManager.canAuthenticate(authenticators) — check availability, specifying BIOMETRIC_STRONG or BIOMETRIC_WEAK
• BiometricPrompt — the authentication dialog, which the system renders (you cannot customize its appearance)
• CryptoObject — optional, wraps a Cipher, Signature, or Mac that is unlocked by biometric auth

For secure key storage, use the Android Keystore with setUserAuthenticationRequired(true) when generating or importing keys. Keys stored this way require biometric authentication before they can be used for cryptographic operations.

Use BIOMETRIC_STRONG for financial or sensitive operations — this requires hardware-backed biometrics. BIOMETRIC_WEAK permits face unlock implementations that aren't hardware-secured, which is not appropriate for high-security contexts.

React Native Implementation

For React Native apps, react-native-biometrics and expo-local-authentication (if using Expo) are the primary libraries. Both provide a cross-platform API over the native iOS/Android implementations.

Pattern for implementing biometric login in React Native:

1. On first login, after successful password authentication, prompt user to enable biometrics
2. Generate a device-specific key pair using the native secure storage (via the library's createKeys())
3. Sign a challenge from your server with the private key after biometric auth success
4. Server verifies the signature using the stored public key — issues session token
5. On subsequent logins, trigger biometric auth, sign the challenge, exchange for session token

This approach means your backend is verifying cryptographic proof of biometric auth, not just trusting the client's claim that it succeeded.

Fallback Handling

Always provide a fallback to password authentication. Users lock themselves out of biometrics regularly (wearing gloves, having a wet finger, Face ID failing in sunlight). An app that offers only biometric login will generate support tickets and one-star reviews.

The standard pattern: after 3 failed biometric attempts, fall through to PIN or password entry. Don't loop biometric retries indefinitely — both iOS and Android will lock out biometric access after repeated failures, and your app should handle that gracefully.

FAQ

Can biometrics replace passwords entirely in a mobile app?

In the UX sense, mostly yes — users don't need to type passwords for daily use. But a password or PIN fallback must always exist for device recovery, biometric failure, and re-enrollment scenarios.

Does biometric auth work when the phone is offline?

Yes, if you implement it with local key storage. The biometric evaluation and key release happen entirely on-device. Your backend verification happens when connectivity is available to exchange the signed challenge for a token.

What about biometric auth for payments specifically?

Payment authorization with biometrics is handled by Apple Pay (Secure Element + Face ID/Touch ID) and Google Pay (Android Keystore + BiometricPrompt) — the platform handles this correctly by design. Don't build your own payment biometric layer on top of them.

How do I handle users who don't have biometrics enrolled?

Check availability before presenting the option. If biometrics aren't available or enrolled, skip the biometric setup flow entirely and use your standard authentication flow. Treat it as an opt-in feature enhancement, not a required authentication path.