Biometrische Authentifizierung

Sensible Aktionen — das Anzeigen von Zahlungsdaten, das Entsperren gespeicherter Passwörter oder das Autorisieren einer Überweisung — sollten nur nach ausdrücklicher Nutzerbestätigung zugänglich sein. Biometrische Authentifizierung bietet dafür eine elegante Lösung: Sie verbindet hohe Sicherheit mit minimaler Reibung. Ein Fingerabdruck oder ein kurzer Blick in die Kamera genügt. Android stellt dafür seit API Level 28 die BiometricPrompt-API bereit, die alle Gerätesensoren und Sicherheitsstufen hinter einer einheitlichen Schnittstelle zusammenfasst.

Was ist das?

Biometrische Authentifizierung bezeichnet die Identitätsverifizierung anhand körperlicher Merkmale — typischerweise Fingerabdruck oder Gesichtserkennung. Statt ein Passwort einzutippen, misst das Gerät ein biometrisches Merkmal und vergleicht es mit einem sicher gespeicherten Referenzwert.

Auf Android übernimmt das Betriebssystem diesen Vergleich vollständig. Deine App sieht weder den Fingerabdruck noch den Kamera-Scan, sondern nur das binäre Ergebnis: Authentifizierung erfolgreich oder fehlgeschlagen. Das ist kein Zufall, sondern ein bewusstes Sicherheitsdesign: Biometrische Rohdaten verlassen nie den Trusted Execution Environment (TEE) des Geräts und werden auch nicht in der Cloud gespeichert.

Für Entwickler ist der Einstiegspunkt die Klasse BiometricPrompt aus der Jetpack-Bibliothek androidx.biometric. Sie löst die älteren, geräteherstellerspezifischen APIs wie FingerprintManager ab und unterstützt Fingerabdruck, Gesichtserkennung und Iris-Scans mit einem einzigen API-Pfad.

Authentifizierungsklassen

Android unterscheidet drei Sicherheitsstufen, sogenannte Authenticator Classes:

• Class 1 (Convenience): Niedrigste Sicherheitsanforderungen, nicht für sicherheitskritische Aktionen geeignet.
• Class 2 (Weak): Moderat sicherer Sensor, ausreichend für Standard-Login-Szenarien.
• Class 3 (Strong): Strenge Anforderungen, zwingend notwendig für kryptografisch gesicherte Operationen, etwa das Entsperren eines SecretKey im AndroidKeyStore.

Wie funktioniert es?

Die Integration läuft in drei klar abgegrenzten Schritten ab: Verfügbarkeit prüfen, Prompt konfigurieren, Ergebnis verarbeiten.

1. Verfügbarkeit prüfen

Bevor du den Dialog zeigst, fragst du BiometricManager nach dem aktuellen Gerätestatus:

val biometricManager = BiometricManager.from(context)
val authenticators = BiometricManager.Authenticators.BIOMETRIC_STRONG or
        BiometricManager.Authenticators.DEVICE_CREDENTIAL

when (biometricManager.canAuthenticate(authenticators)) {
    BiometricManager.BIOMETRIC_SUCCESS          -> { /* Biometrie einsatzbereit */ }
    BiometricManager.BIOMETRIC_ERROR_NO_HARDWARE -> { /* Kein Sensor vorhanden */ }
    BiometricManager.BIOMETRIC_ERROR_HW_UNAVAILABLE -> { /* Sensor vorübergehend gesperrt */ }
    BiometricManager.BIOMETRIC_ERROR_NONE_ENROLLED  -> { /* Keine biometrischen Daten registriert */ }
}

2. Prompt konfigurieren

val promptInfo = BiometricPrompt.PromptInfo.Builder()
    .setTitle("Identität bestätigen")
    .setSubtitle("Authentifiziere dich, um fortzufahren")
    .setAllowedAuthenticators(
        BiometricManager.Authenticators.BIOMETRIC_STRONG or
        BiometricManager.Authenticators.DEVICE_CREDENTIAL
    )
    .build()

Durch DEVICE_CREDENTIAL als Fallback stellst du sicher, dass Nutzer ohne registrierten Fingerabdruck trotzdem über PIN oder Muster Zugang erhalten.

3. Ergebnis verarbeiten

val biometricPrompt = BiometricPrompt(
    activity,
    ContextCompat.getMainExecutor(context),
    object : BiometricPrompt.AuthenticationCallback() {
        override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
            // Zugriff freigeben oder Krypto-Operation fortsetzen
        }
        override fun onAuthenticationFailed() {
            // Merkmal nicht erkannt – Nutzer kann es erneut versuchen
        }
        override fun onAuthenticationError(errorCode: Int, errString: CharSequence) {
            // Nicht behebbarer Fehler oder Nutzer hat abgebrochen
        }
    }
)

biometricPrompt.authenticate(promptInfo)

Für kryptografisch gesicherte Aktionen — etwa das Entsperren eines SecretKey im AndroidKeyStore — übergibst du stattdessen ein CryptoObject, das den Schlüssel an die laufende Authentifizierungssitzung bindet. Nur ein erfolgreicher Biometrie-Check entsperrt dann den Schlüssel, und selbst ein kompromittiertes Gerät-OS erhält keinen Zugriff auf die Rohdaten.

In der Praxis

Stell dir vor, deine Banking-App zeigt den Kontostand erst nach Authentifizierung an. Das richtige Muster: Beim Wechsel in den sensiblen Bereich canAuthenticate() aufrufen, danach den BiometricPrompt auslösen und erst im onAuthenticationSucceeded-Callback die Daten aus dem Repository laden.

Stolperfalle: Zu früh freigeben

Ein häufiger Fehler ist, gesicherten Inhalt bereits vor der Authentifizierung zu laden und ihn dann nur per UI-Flag auszublenden. Das ist keine echte Schranke — die Daten liegen bereits im Speicher. Modelliere den Auth-State im ViewModel als StateFlow und lass das Repository Daten erst freigeben, wenn dieser State auf Authenticated steht:

sealed interface AuthState {
    data object Locked : AuthState
    data object Authenticated : AuthState
}

So verhindert die Architektur selbst, dass sensible Daten versehentlich in die UI gelangen, bevor der Nutzer sich ausgewiesen hat.

Stolperfalle: BIOMETRIC_ERROR_NONE_ENROLLED ignorieren

Wenn kein Fingerabdruck registriert ist, liefert canAuthenticate() den Fehlercode BIOMETRIC_ERROR_NONE_ENROLLED. Leite den Nutzer in diesem Fall aktiv zu den Systemeinstellungen, anstatt den Fehler stillschweigend zu schlucken:

val enrollIntent = Intent(Settings.ACTION_BIOMETRIC_ENROLL).apply {
    putExtra(
        Settings.EXTRA_BIOMETRIC_AUTHENTICATORS_ALLOWED,
        BiometricManager.Authenticators.BIOMETRIC_STRONG
    )
}
startActivity(enrollIntent)

Das signalisiert dem Nutzer, was fehlt, und vermeidet frustrierende Sackgassen in der App.

Fazit

Die BiometricPrompt-API macht es unkompliziert, sensible Aktionen hinter einer starken, nutzerfreundlichen Schranke zu sichern — ohne eigene Sensor-Logik implementieren zu müssen. Schau jetzt in deine eigene App: Welche Screens zeigen Passwörter, Zahlungsdetails oder persönliche Daten, ohne eine Authentifizierungsschranke zu haben? Füge an einer dieser Stellen einen BiometricPrompt ein, modelliere den Auth-State sauber in deinem ViewModel und schreibe einen instrumentierten Test, der sowohl den onAuthenticationSucceeded-Pfad als auch den Fehlerfall abdeckt. So verinnerlichst du nicht nur die API, sondern auch das Sicherheitsdenken, das hinter ihr steckt.