Login in Apps: Biometrie und Passkeys

„Können wir Face ID einbauen?" ist eine der häufigsten Anfragen zu bestehenden Apps, und sie klingt nach einer kleinen Sache. Die ehrliche Antwort ist zweigeteilt. Wenn die App ihre Zugangsdaten schon richtig ablegt und das Backend saubere, widerrufbare Sitzungen kennt, ist Biometrie tatsächlich eine überschaubare Ergänzung. Liegt das Zugangstoken dagegen in den Einstellungen, oder kennt das Backend keine Sitzungen pro Gerät, wird aus der Face-ID-Anfrage schnell eine Sanierung des gesamten Logins. Dieselbe Frage, zwei sehr verschiedene Antworten, und der Unterschied liegt an Stellen, die niemand sieht: dem Tresor, in dem die App ihre Schlüssel aufbewahrt, und dem Backend, das entscheidet, wer angemeldet ist.

Dieser Beitrag ist das mobile Gegenstück zu meinem Beitrag über Login-Sicherheit in Webanwendungen. Er erklärt die drei Bausteine, aus denen ein sicherer App-Login besteht: die sichere Ablage auf dem Gerät, die Biometrie als Schlüssel dazu, und Passkeys als Ersatz für das Passwort. Und er zeigt die Fehler, die ich in Apps zur Prüfung am häufigsten finde.

Für Entscheider: Worum es geht

• Biometrie ersetzt kein Passwort. Das Betriebssystem bestätigt nur, dass die Geräteauthentifizierung erfolgreich war. Wertvoll wird das erst, wenn das System den Zugriff auf den Zugangsschlüssel daran bindet.
• Unter iOS liegt das Credential im Keychain. Unter Android wird es mit einem Schlüssel geschützt, der im Android Keystore liegt. Alles andere, Einstellungen, Dateien, Datenbank, ist kein Ort für Zugangsdaten.
• Passkeys sind für persönliche Geräte eine der stärksten Kombinationen aus Sicherheit und Komfort: phishing-resistent, an Ihre Domain gebunden, ohne Passwort. Sie brauchen eine Verknüpfung zwischen App und Website, die einmal sauber eingerichtet werden muss.
• Die Sitzung lebt im Backend, nicht im Gerät. Ein verlorenes Handy wird serverseitig abgemeldet, nicht per Hoffnung.
• Für Geräte, die mehrere Personen nutzen, gilt ein anderes Muster: Die Person weist sich unabhängig vom Gerät aus.
• Der Aufwand hängt vor allem davon ab, wie Tokens heute gespeichert werden und ob das Backend bereits saubere, widerrufbare Sitzungen verwaltet.

Was Face ID und Fingerabdruck wirklich tun

Wenn eine App Face ID abfragt, bekommt sie vom Betriebssystem eine einzige Information zurück: Die auf diesem Gerät konfigurierte Authentifizierung wurde erfolgreich erfüllt, oder nicht. Die App sieht kein Gesicht, keinen Fingerabdruck, keine biometrischen Daten. Die biometrische Verarbeitung übernimmt das Betriebssystem in seiner geschützten Sicherheitsumgebung, bei Apple unter Einbindung der Secure Enclave, bei Android je nach Gerät über eine vergleichbare sichere Hardware. Und das System sagt auch nicht „Das ist Frau Meyer aus Ihrem ERP". Es sagt: Wer auch immer dieses Gerät eingerichtet hat, hat sich gerade ausgewiesen. Geräteidentität ist nicht Benutzerkonto, und das ist der Grund, warum Biometrie allein keinen Login ergibt.

Das Ja ist für sich genommen wertlos. Ein Angreifer, der die App manipuliert, kann sich das Ja selbst geben. Wertvoll wird die Biometrie erst durch ihre zweite Fähigkeit: Sie kann einen Eintrag im Schlüsselbund des Geräts so schützen, dass er nur nach erfolgreicher Authentifizierung lesbar ist, und zwar vom Betriebssystem erzwungen, nicht von der App. Dort liegt beispielsweise das Refresh-Token oder ein vergleichbares widerrufbares Sitzungs-Credential. Der Ablauf beim Öffnen der App ist dann:

1. Die App bittet das System, den Eintrag mit dem Zugangstoken aus dem Schlüsselbund zu lesen.
2. Das System verlangt Face ID, Fingerabdruck oder Geräte-PIN, weil der Eintrag so angelegt wurde.
3. Bei Erfolg gibt das System das Token heraus, die App holt sich damit vom Backend eine neue Sitzung.
4. Bei Misserfolg bleibt der Eintrag verschlossen. Die App hat nichts, womit sie sich anmelden könnte.

Der Unterschied zur naiven Variante ist entscheidend, und er ist im Code leicht zu übersehen. Naiv heißt: Die App fragt selbst Face ID ab, und bei Ja liest sie ein Token, das ohne Biometrie genauso lesbar gewesen wäre. Dann ist die Biometrie eine Fassade. Richtig heißt: Der Zugriff auf das Token ist vom Betriebssystem an die Geräteauthentifizierung gebunden. Unter iOS geschieht das über Zugriffsbedingungen am Keychain-Eintrag, unter Android über einen Keystore-Schlüssel, der eine Nutzerauthentifizierung verpflichtend macht. Die Bibliotheken, mit denen man in Flutter oder nativ auf den Schlüsselbund zugreift, bieten beide Wege an; welchen die App nutzt, sieht man ihr von außen nicht an, und genau das prüfe ich als Erstes.

Face ID weiß nicht, wer Ihr Mitarbeiter ist. Das Smartphone weiß nur, dass die lokal eingerichtete Geräteauthentifizierung erfolgreich war. Welcher Mitarbeiter zum Konto gehört, entscheidet Ihr Backend. Auf einem persönlichen Diensthandy fällt beides oft zusammen. Auf gemeinsam genutzten Geräten ausdrücklich nicht.

Gerätegebunden, nicht mitgenommen

Ein Detail, das über die Sicherheit entscheidet: Ohne besondere Einstellung kann ein Keychain-Eintrag über ein Geräte-Backup auf ein anderes Gerät wandern. Für Sitzungs- und Refresh-Tokens sollte deshalb eine gerätegebundene Keychain-Klasse verwendet werden, bei Apple erkennbar am Zusatz ThisDeviceOnly. Dann wird der Eintrag nicht auf ein neues Gerät migriert, und nach einem Gerätewechsel meldet sich der Nutzer einmal neu an. Für ein langlebiges Zugangstoken ist das genau das gewünschte Verhalten. Bei Android erledigt das der Keystore, dessen Schlüssel das Gerät ohnehin nicht verlassen.

Wo Zugangsdaten hingehören, und wo nicht

Der häufigste Fehler in Apps, die ich zur Prüfung bekomme, ist nicht die fehlende Biometrie. Es ist das Token in den Einstellungen. SharedPreferences auf Android, UserDefaults auf iOS, eine Datei im Dokumentenordner, ein Feld in der lokalen Datenbank. Alles Klartext, alles im Backup, auf einem entsperrten oder gerooteten Gerät für jeden lesbar. Die Regel ist einfach:

Was	Wohin	Niemals
Zugangstoken, Refresh-Token, API-Schlüssel des Nutzers	Keychain (iOS), Keystore-verschlüsselte Ablage (Android)	Einstellungen, Dateien, Datenbank
Das Passwort des Nutzers	nirgends	auch nicht verschlüsselt, auch nicht „für den Komfort"
Feste Schlüssel der App (Backend-URL, öffentliche Schlüssel)	im Code, sind öffentlich	geheime Schlüssel im Code: sie sind nach dem Auspacken der App für jeden lesbar
Fachdaten (Aufträge, Kunden) für den Offline-Betrieb	lokale Datenbank, bei sensiblen Daten verschlüsselt	unverschlüsselt auf der SD-Karte

Die zweite Zeile ist die wichtigste. Es gibt keinen Grund, das Passwort eines Nutzers auf dem Gerät zu behalten. Wer sich nach dem ersten Login ein widerrufbares Refresh-Token vom Backend holt und dieses geschützt ablegt, braucht das Passwort nie wieder. Und die dritte Zeile ist die, die am häufigsten übersehen wird: Ein „geheimer" API-Schlüssel, den die App fest eingebaut hat, ist kein Geheimnis. Jede App lässt sich auspacken. Geheimnisse, die das Backend braucht, bleiben im Backend.

Passkeys: Das Passwort loswerden

Passkeys funktionieren in Apps genauso wie im Web: Beim Anlegen erzeugt das Gerät ein Schlüsselpaar. Der öffentliche Teil geht an Ihr Backend, der private bleibt in der geschützten Credential-Infrastruktur des Nutzers, bei synchronisierten Passkeys über dessen Apple-, Google- oder andere unterstützte Konten auf seine Geräte verteilt, bei gerätegebundenen Passkeys und Sicherheitsschlüsseln nur dort. Beim Login signiert das Gerät eine Anfrage des Backends, nachdem der Nutzer die Verwendung des Credentials über die Geräteauthentifizierung freigegeben hat. Kein Passwort, nichts zum Merken, nichts zum Phishen. Auf iOS läuft das über AuthenticationServices, auf Android über den Credential Manager, und beide Plattformen zeigen dem Nutzer denselben Systemdialog, den er von Websites kennt.

Der Teil, der in Anleitungen oft fehlt und in Projekten die Zeit kostet: Passkeys sind an eine Domain gebunden, und die App muss nachweisen, dass sie zu dieser Domain gehört. Damit App und Website dieselbe Identität verwenden dürfen, wird die Domain technisch mit der App verknüpft: unter iOS über eine Datei apple-app-site-association mit dem Eintrag für Webcredentials, unter Android über assetlinks.json. Beide liegen auf Ihrer Website und sagen: Diese App darf meine Passkeys benutzen.

// iOS: https://portal.musterbetrieb.de/.well-known/apple-app-site-association
{ "webcredentials": { "apps": [ "TEAMID.de.musterbetrieb.portal" ] } }

// Android: https://portal.musterbetrieb.de/.well-known/assetlinks.json
[{ "relation": ["delegate_permission/common.get_login_creds"],
   "target": { "namespace": "android_app", "package_name": "de.musterbetrieb.portal",
               "sha256_cert_fingerprints": ["AB:CD:...:12"] } }]

Ohne diese Verknüpfung zeigt das System keinen Passkey-Dialog, und die Fehlermeldung dazu ist nichtssagend. Mit ihr teilen sich App und Website dieselben Passkeys: Wer sich im Portal am Rechner einen Passkey angelegt hat, meldet sich in der App damit an, und umgekehrt. Das Backend ist dasselbe wie im Web; die Bibliothek für die Prüfung der Signaturen ändert sich nicht, nur der Absender.

Für eine Geschäftsanwendung können Passkeys zunächst neben dem klassischen Passwort-Login angeboten werden, nicht als Zwang. Die Gerätebiometrie ist davon getrennt: Sie bestätigt lokal die Nutzung eines Passkeys oder schützt den Zugriff auf eine bereits bestehende Sitzung, sie ist keine dritte Login-Methode. Es gibt Umgebungen mit anderen Vorgaben, Smartcards, Hardware-Schlüssel, zentrale Unternehmensidentität, regulierte Bereiche, und dort entscheidet die Vorgabe, nicht der Komfort. Und mit einer Einschränkung, die der Web-Beitrag ausführlicher beschreibt: Synchronisierte Passkeys hängen an der Sicherheit des Apple- oder Google-Kontos. Für ein Adminkonto im Controlling will man das wissen.

Die Sitzung lebt im Backend

Alles bisher spielt auf dem Gerät. Aber die Frage, wer angemeldet ist, beantwortet das Backend, und das hat Folgen, die in App-Projekten gern vergessen werden:

• Tokens sind widerrufbar. Zugriffstokens sind typischerweise kurzlebig, Refresh-Tokens deutlich länger gültig und serverseitig widerrufbar. Das Backend führt deshalb pro Gerät oder Sitzung einen Zustand, über den einzelne Logins beendet werden können. Meldet ein Nutzer sein Handy als verloren, beendet der Admin die Sitzung, und die App auf dem verlorenen Gerät ist beim nächsten Aufruf abgemeldet. Ohne diesen Zustand ist ein gestohlenes Gerät so lange angemeldet, wie das Token gültig ist.
• Jedes Gerät ist eine eigene Sitzung. Der Nutzer sieht in seinem Konto, welche Geräte angemeldet sind, und kann einzelne abmelden. Das ist eine Tabelle und zwei Bildschirme, und es ist der Unterschied zwischen „Handy weg, Panik" und „Handy weg, abgemeldet".
• Rate-Limit und Protokoll gelten für die App-Schnittstelle genauso wie für das Web-Login. Ein Angreifer, der die App auspackt, sieht die Schnittstelle und probiert sie direkt.

Mehr Sicherheit kann Betriebssicherheit kosten

Ein Beispiel dafür ist Certificate Pinning: Die App akzeptiert nur das Zertifikat Ihres Backends statt jedes gültigen. Das wird gern als Standardbaustein für sensible Apps empfohlen, und das ist es nicht. Es kann bei einem passenden Bedrohungsmodell zusätzliche Sicherheit bringen, etwa gegen manipulierte Proxys in fremden Netzen, erhöht aber das Betriebsrisiko erheblich: Ein ungeplanter Zertifikats- oder CA-Wechsel schneidet ältere App-Versionen vollständig vom Backend ab, und die Nutzer können nichts tun außer auf ein Update warten. Wenn Pinning eingesetzt wird, braucht es deshalb eine geplante Schlüsselrotation, Backup-Pins und einen Kalendereintrag, der nicht in den Urlaub fällt. Für die meisten Business-Apps ist ein sauber konfiguriertes TLS ohne Pinning die bessere Abwägung.

Der Sonderfall: Geräte, die mehrere Personen nutzen

Im Lager, in der Pflege, im Sicherheitsdienst gehört das Gerät nicht der Person, sondern der Schicht. Biometrie ist dort gar nicht oder nur für einen Nutzer eingerichtet, und ein synchronisierter Passkey gehört zum privaten Apple-Konto, das auf einem Firmengerät nichts zu suchen hat. Die Gerätebiometrie ist hier kein geeigneter Nachweis für die Person, denn sie sagt nur, dass jemand mit Zugang zum Gerät es entsperrt hat.

Auf gemeinsam genutzten Geräten muss deshalb die Person unabhängig vom Gerät authentifiziert werden, etwa per persönlicher PIN, Dienstausweis, Smartcard oder NFC-Ausweis, mit kurzer Anmeldung pro Schicht und automatischer Abmeldung nach Inaktivität. Das Gerät selbst wird separat verwaltet, über ein MDM, ein Gerätezertifikat oder den Kiosk-Modus. Zwei Fragen, zwei Antworten: Welches Gerät ist das, und welche Person ist das. Wer die beiden vermischt, hat am Ende ein Protokoll, in dem alle Buchungen der Schicht auf den Kollegen laufen, der morgens das Gerät entsperrt hat.

Die häufigsten Fehler

• Token in den Einstellungen. Klartext, im Backup, für jeden lesbar, der das Gerät in die Hand bekommt.
• Biometrie als Fassade. Die App fragt Face ID ab, aber das Token liegt ungeschützt daneben und wäre auch ohne lesbar.
• Passwort auf dem Gerät gespeichert, damit die App sich „automatisch neu anmelden" kann. Dafür gibt es Refresh-Tokens.
• Geheime Schlüssel im Code. Nach dem Auspacken der App öffentlich.
• Keine serverseitige Sperre. Verlorene Geräte bleiben angemeldet.
• Passkeys ohne Domain-Verknüpfung. Der Dialog erscheint nicht, und niemand weiß warum.
• Pinning ohne Rotationsplan. Beim nächsten Zertifikatswechsel sind alle ausgesperrt.
• Biometrie-Änderung nicht bedacht. Wer einen neuen Fingerabdruck hinzufügt, sollte sich neu anmelden müssen. Beide Plattformen bieten dafür einen Schalter am Schlüsseleintrag, der bei Änderung der Biometrie den Eintrag ungültig macht.

Checkliste: Ist der Login Ihrer App sauber?

• ☐ Liegen Tokens ausschließlich im Keychain oder Keystore, gerätegebunden?
• ☐ Wird das Passwort des Nutzers nirgends auf dem Gerät gespeichert?
• ☐ Ist der Zugriff auf das Token vom System an die Authentifizierung gebunden, oder fragt nur die App?
• ☐ Können Admin und Nutzer ein Gerät serverseitig abmelden?
• ☐ Laufen Tokens ab, und führt das Backend einen Zustand je Sitzung?
• ☐ Ist die Domain-Verknüpfung für Passkeys auf der Website veröffentlicht?
• ☐ Gibt es für gemeinsam genutzte Firmengeräte ein eigenes Anmeldemuster?
• ☐ Enthält die App keine geheimen Schlüssel, die nur ins Backend gehören?
• ☐ Falls Pinning: gibt es Rotationsplan und Backup-Pins?

Fazit: Der Tresor ist wichtiger als die Tür

Face ID ist die Tür, die jeder sieht. Der Tresor dahinter, Keychain und Keystore mit systemgebundenem Zugriff, ist das, was die Sicherheit ausmacht, und er ist unsichtbar. Passkeys machen die Tür noch besser, weil sie das Passwort abschaffen und an Ihre Domain gebunden sind. Und das Backend behält den Generalschlüssel: Es entscheidet, welche Sitzung gilt, und kann jede beenden. Deshalb ist die erste Frage bei jeder Face-ID-Anfrage nicht „wie lange dauert das", sondern „wo liegt heute das Token". Stimmen Tresor und Backend, ist es eine überschaubare Ergänzung. Stimmen sie nicht, ist die Biometrie der Anlass, sie in Ordnung zu bringen.

Verwandt auf die.entwicklerin.net: Login-Sicherheit: 2FA und Passkeys für Geschäftsanwendungen, dieselbe Anmeldung im Browser statt in der App.