Passwort-Manager-Testing für native App-Passkeys

1. Einführung: Native App-Passkeys treffen auf Drittanbieter-Passwort-Manager#

Mit der Veröffentlichung von iOS 17 und Android 14 hat sich die Passkey-Landschaft für native mobile Apps grundlegend verändert. Zum ersten Mal können Drittanbieter-Passwort-Manager als Passkey-Provider fungieren und durchbrechen damit die exklusive Vormachtstellung von iCloud Keychain und Google Password Manager. Dies ermöglicht es den Nutzern, ihre eigenen vertrauten Lösungen wie 1Password, Bitwarden oder Dashlane in die Authentifizierungsabläufe nativer Apps einzubringen. Während dies ein großer Gewinn für die Wahlfreiheit der Nutzer ist, bringt es für Entwickler eine erhebliche Komplexität mit sich. Ihre Passkey-Implementierung kann sich über verschiedene Passwort-Manager hinweg in nativen mobilen Anwendungen unterschiedlich verhalten. Daher ist es für jedes Team wichtig, native App-Passkeys und 3rd-Party-Passwort-Manager richtig zu testen.

Dieser umfassende Guide teilt unseren praxiserprobten Ansatz für das Testing nativer App-Passkeys mit Drittanbieter-Passwort-Managern. Obwohl das Passkey-Ökosystem 2025 deutlich gereift ist, erfordert die reale Implementierung weiterhin eine sorgfältige Validierung über diverse Passwort-Manager-Implementierungen hinweg. Wir haben unsere Erfahrung in einem praktischen Testplan destilliert, der sicherstellt, dass Ihre native App nahtlos mit den bevorzugten Passwort-Managern der Nutzer funktioniert.

2. Warum Passkey-Testing in der Produktion wichtig ist#

2.1 Nutzer bringen ihren eigenen Passwort-Manager mit#

Das Passwort-Manager-Ökosystem hat sich über plattformnative Lösungen hinaus entwickelt. Nutzer entscheiden sich aktiv für Drittanbieter-Passwort-Manager wie 1Password, Bitwarden, Dashlane, Proton Pass und NordPass, basierend auf ihren spezifischen Bedürfnissen, wie plattformübergreifender Synchronisierung, Enterprise-Funktionen oder Datenschutzpräferenzen. Ihre native iOS- / Android-App muss diese Vielfalt berücksichtigen, ohne Nutzer zu zwingen, ihre vertraute Passwort-Management-Lösung zu wechseln.

Basierend auf Daten, die wir über Corbado-Seiten hinweg messen, sehen wir, dass nur 5 bis 10 % der allgemeinen Nutzer auf Drittanbieter-Passwort-Manager angewiesen sind. Auch wenn diese Zahl gering klingen mag, wird sie einen enormen Einfluss auf die Wahrnehmung Ihrer Passkey-Implementierung und die Anzahl der Support-Tickets haben, wenn Sie in einer groß angelegten Umgebung arbeiten. Wir haben festgestellt, dass einige Passwort-Manager die WebAuthn-Spezifikation leicht unterschiedlich implementieren, was zu subtilen Variationen in der User Experience oder sogar zu Bugs führt.

2.2 Unterschiedliche UX-Muster in nativen Apps#

Native iOS- und Android-Apps bieten verschiedene Möglichkeiten für die Passkey-Nutzung. Bei Android stoßen Sie auf Passkey-Overlays und manuelle Textfeld-Eingaben, die eine Passkey-Zeremonie auslösen (für Web-Apps unterstützt Android auch Conditional UI). iOS bietet sein eigenes Set an Passkey-Overlays neben Conditional UI und ebenfalls manuelle Textfeld-Eingaben. Darüber hinaus gibt es weitere Edge-Cases zu überprüfen. Alles in allem muss Ihre native Anwendung Folgendes elegant handhaben:

• Passkey-Overlay-Logins, die sofort beim Laden der Seite erscheinen
• Conditional UI-Logins (nur iOS), die verfügbare Passkeys automatisch vorschlagen
• Textfeld-Logins, bei denen der Nutzer seinen Benutzernamen eingibt, bevor er auf einen Button klickt
• Cross-Device Authentication (CDA) für die Passkey-Nutzung mit einem anderen Gerät
• Fallback-Mechanismen, wenn die Passkey-Nutzung nicht verfügbar ist

2.3 WebAuthn-Flags erfordern Präzision#

Die korrekte Flag-Konfiguration bestimmt, ob Passkeys über Geräte und Plattformen hinweg wie erwartet funktionieren. Zu den kritischen Werten gehören:

• Relying Party ID (rpID): Muss zwischen Web- und nativen Implementierungen exakt übereinstimmen und ist die Domain, an die der Passkey gebunden ist
• User verification: Bestimmt, dass der Nutzer seine lokale Authentifizierung bereitstellen muss
• Resident key/discoverable credentials: Ermöglicht eine Benutzernamen-lose Authentifizierung (erlaubt Conditional UI)
• Backup eligibility (BE) und backup state (BS): Erlaubt die geräteübergreifende Synchronisierung von Passkeys

Falsch konfigurierte Flags verursachen nicht immer sofortige Fehler. Sie könnten jedoch subtile Probleme und Inkonsistenzen hervorrufen, wie z. B. dass Passkeys auf einem Gerät verfügbar sind, aber nicht geräteübergreifend synchronisiert werden (obwohl derselbe Drittanbieter-Passwort-Manager auf beiden Geräten verfügbar sein könnte). Eine unserer Erkenntnisse in den Tests war, dass einige Drittanbieter-Passwort-Manager die BE/BS-Flags falsch setzen und für einen großen Teil der Passkey-Probleme verantwortlich waren.

2.4 Lifecycle Management in Single-Instance-Apps#

Single-Activity- (Android) und Single-Scene- (iOS) Architekturen erfordern ein akribisches Lifecycle Management. Wenn das Sheet eines Passwort-Managers erscheint und wieder geschlossen wird, muss Ihre App den Zustand beibehalten, Callbacks verarbeiten und korrekt fortfahren. Dies ist besonders kritisch bei Android, wo die launchMode-Konfiguration zu unerwartetem Verhalten führen kann.

Beispielsweise haben wir festgestellt, dass das Setzen von MainActivity auf launchMode="singleInstance" Probleme verursachte. Bei einigen Android-Versionen und OEM-Anpassungen führt dieser Modus dazu, dass die Passkey Credential Manager-UI als separater Task geöffnet wird. Dies fügt nicht nur einen verwirrenden, zusätzlichen App-Eintrag zum "Recents"-Bildschirm (Zuletzt verwendet) hinzu, sondern kann auch dazu führen, dass die App einfriert, wenn sie in den Hintergrund verschoben wird, während der Passkey-Dialog geöffnet ist.

Die empfohlene Lösung ist, die Konfiguration auf launchMode="singleTask" zu ändern. Dies verhindert, dass der Credential Manager einen separaten Task erzeugt, sorgt für einen vorhersehbareren Lebenszyklus über verschiedene OEMs (Samsung, Google, Vivo usw.) hinweg und verringert das Risiko herstellerspezifischer Bugs. Es bietet eine stabilere Grundlage für das Testen von Navigation, Overlays und Deeplinks.

Wir haben beobachtet, dass sich solche Lifecycle-Probleme oft als "Passwort-Manager-Bugs" tarnen, wenn es sich eigentlich um Probleme auf Anwendungsebene handelt. Ein ordnungsgemäßes Instrumentieren und Testen über verschiedene Provider hinweg hilft, diese Muster frühzeitig zu erkennen.

3. Einrichten Ihrer Testumgebung#

3.1 Ziel-Passwort-Manager#

Fokussieren Sie Ihr Passkey-Testing in nativen Apps auf die am weitesten verbreiteten Drittanbieter-Passwort-Manager:

Primäre Ziele (wesentliche Abdeckung):

• 1Password
• Bitwarden
• Dashlane
• Proton Pass
• NordPass

Sekundäre Ziele (basierend auf Ihrer Nutzerbasis):

• Regionale Provider (z. B. Samsung Pass für Samsung-Geräte)
• Enterprise-Lösungen, falls Sie Geschäftskunden ansprechen
• Plattform-Standardeinstellungen (Google Password Manager, iCloud Keychain) als Basislinie

Vermeiden Sie die Versuchung, jeden verfügbaren Passwort-Manager zu testen. Konzentrieren Sie sich auf Provider, die 90 % Ihrer Nutzerbasis repräsentieren. Unsere Analysen ergaben, dass die fünf primären Ziele 85 % der Nutzer von Drittanbieter-Passwort-Managern in der EU, den USA, Großbritannien, Australien und Neuseeland abdeckten.

3.2 Pre-Flight-Checkliste#

Stellen Sie vor Beginn jedes Testlaufs eine saubere, reproduzierbare Umgebung sicher:

1. Sauberer Credential-Zustand:

• Entfernen Sie alle vorhandenen Credentials für Ihre RP ID
• Leeren Sie Browser- und App-Caches
• Melden Sie sich vollständig aus dem Passwort-Manager ab und wieder an
• Erzwingen Sie das Beenden der Ziel-App und starten Sie sie neu

2. Stabilisierung der Testumgebung:

• Sorgen Sie für eine stabile Netzwerkverbindung (keine VPNs während des Tests)
• Deaktivieren Sie UI-Animationen bei automatisierten Tests
• Verwenden Sie eine konsistente Geräteausrichtung
• Dokumentieren Sie die OS-Version, App-Version und Passwort-Manager-Version

4. Der umfassende Testplan#

Jeder Test validiert spezifische Aspekte der Passkey-Funktionalität. Dokumentieren Sie die Ergebnisse systematisch mit Pass/Fail-Status und detaillierten Notizen zu jeglichen Anomalien.

4.1 Kern-Tests des Authentifizierungsablaufs#

Test 1: Abbruch der Passkey-Erstellung (nach erfolgreichem konventionellem Login)#

Überprüfen einer sauberen Abbruch-Handhabung

✓ Passwort-Manager-Sheet öffnet sich korrekt
✓ Nutzer bricht ab, ohne einen Passkey zu erstellen
✓ App kehrt zum Login-Bildschirm zurück ✓ Keine verwaisten Credentials im Passwort-Manager
✓ UI zeigt angemessene Wiederholungsoptionen an

Test 2: Passkey erstellen (nach erfolgreichem konventionellem Login)#

Überprüfen der Passkey-Erstellung nach dem Authentifizierungsablauf

✓ Lokale Authentifizierung startet zuverlässig
✓ Biometrische Authentifizierung wird erfolgreich abgeschlossen
✓ Credential wird mit korrekter RP ID erstellt
✓ App geht ohne Schleifen in den authentifizierten Zustand über

Test 3: Mit bestehendem Passkey authentifizieren#

Testen von Standard-Authentifizierungsszenarien

✓ Passkey-Overlay-UI erscheint oder Nutzer gibt Benutzernamen im Textfeld-Szenario ein ✓ Biometrischer Scan und eine einzige biometrische Eingabeaufforderung führen zur erfolgreichen Authentifizierung
✓ Keine Auswahl-Schleifen oder wiederholtes Erscheinen von Sheets
✓ Session bleibt nach der Authentifizierung stabil

Test 4: Passkey aus den Einstellungen erstellen#

Validieren der in-App Passkey-Verwaltung

✓ Korrekte RP ID, Discoverability und BE/BS-Flags
✓ App bleibt nach Erstellung authentifiziert
✓ Passwort-Manager aktualisiert sofort mit korrekten Labels

Test 5: Passkey löschen und erneuten Login versuchen#

Testen des Credential-Lifecycles

✓ Passkey in den Einstellungen löschen ✓ Passkey-Login ist nicht möglich
✓ Passende Fallback-Option wird angeboten

4.2 Cross-Platform Kompatibilitätstests#

Test 6: In der nativen App erstellten Passkey im Web nutzen (gleiches Gerät)#

Überprüfen der App-zu-Web-Portabilität

✓ Browser erkennt in der App erstellte Passkeys
✓ Auswahl-Sheet zeigt die korrekte RP-Zuordnung
✓ Authentifizierung wird ohne QR-/CDA-Umweg abgeschlossen

Test 7: Im Web erstellten Passkey in nativer App nutzen#

Testen der Freigabe von Web-zu-App-Credentials

✓ App zeigt das im Web erstellte Credential in der Auswahl an
✓ Authentifizierung im ersten Versuch gelingt
✓ Kein erzwungenes Passwort-Fallback

Test 8: Geräteübergreifende Synchronisierung (Mobile zu Desktop)#

Überprüfen der Passkey-Synchronisierung von nativer App zu Desktop-Browser

✓ In der App erstellter Passkey wird mit dem Desktop-Passwort-Manager synchronisiert ✓ Synchronisierter Passkey funktioniert nahtlos im Desktop-Browser ✓ Es wird kein QR-Code / Cross-Device-Flow ausgelöst ✓ Authentifizierung wird ohne Schleifen oder Fehler abgeschlossen

Test 9: Geräteübergreifende Synchronisierung (Desktop zu Mobile)#

Überprüfen der Passkey-Synchronisierung vom Desktop-Browser zur nativen App

✓ Auf dem Desktop erstellter Passkey wird mit dem mobilen Passwort-Manager synchronisiert ✓ Native App zeigt den synchronisierten Passkey korrekt an ✓ Authentifizierung gelingt ohne Passwort-Fallback ✓ Logs verknüpfen die Assertion mit der korrekten Credential ID

Test 10: Mobile als Authenticator für das Web#

Überprüfen von "Smartphone-als-Security-Key"-Szenarien

✓ Smartphone bietet in der App erstelltes Credential für Web-CDA an
✓ Keine falschen "Keine Passkeys verfügbar"-Fehler
✓ Web-Session wird nach mobiler Biometrie abgeschlossen

5. Häufige Probleme und Vermeidungsstrategien#

Unsere umfangreichen Tests offenbarten mehrere wiederkehrende Muster, die die Integration von Passkeys bei Drittanbieter-Passwort-Managern beeinträchtigen:

Verzögerungen bei der geräteübergreifenden Synchronisierung#

Problem: Auf einem Gerät erstellte Credentials erscheinen möglicherweise nicht sofort auf anderen.

Lösung: Implementieren Sie Retry-Logik mit exponentiellem Backoff. Bieten Sie manuelle Aktualisierungsoptionen für Nutzer, die Synchronisierungsverzögerungen erleben.

Versionsspezifisches Verhalten#

Problem: Das Verhalten von Passwort-Managern variiert stark zwischen OS-Versionen, insbesondere bei Android 14+ und iOS 17+.

Lösung: Pflegen Sie eine Kompatibilitätsmatrix und passen Sie Abläufe basierend auf der erkannten OS-Version an. Ziehen Sie Mindestversionsanforderungen für eine optimale Erfahrung in Betracht.

6. Fazit: Produktreifen Passkey-Support aufbauen#

Die erfolgreiche Implementierung von Passkey-Support für Drittanbieter-Passwort-Manager in nativen Apps erfordert methodisches Testing und Liebe zum Detail. Unser umfassender Testplan, verfeinert durch praxisnahe Tests, bietet eine solide Grundlage für die Validierung Ihrer Passkey-Integration.

Wichtige Erkenntnisse für das produktive Deployment:

1. Systematisch testen: Nutzen Sie unseren Testplan als Basis und passen Sie ihn an Ihre spezifischen Anwendungsfälle an
2. Nutzerwahl respektieren: Unterstützen Sie die Passwort-Manager, die Ihre Nutzer bevorzugen, nicht nur Plattform-Standardeinstellungen
3. Kontinuierlich überwachen: Implementieren Sie umfassendes Logging, um Edge-Cases in der Produktion zu erfassen
4. Gründlich dokumentieren: Führen Sie klare Aufzeichnungen über provider-spezifisches Verhalten und Workarounds

Das Passkey-Ökosystem entwickelt sich weiterhin rasant. Passwort-Manager aktualisieren regelmäßig ihre Implementierungen, Betriebssysteme führen neue Funktionen ein und die WebAuthn-Spezifikation selbst schreitet voran. Indem Sie jetzt ein robustes Testing-Framework aufbauen, sind Sie darauf vorbereitet, sich anzupassen, wenn die Technologie reift.

Wir werden unsere SDKs und unsere Testing-Methodik weiter aktualisieren, sobald neue Muster auftauchen. Die Investition in umfassendes Testing von Drittanbieter-Passwort-Managern zahlt sich durch geringeren Support-Aufwand und verbesserte Nutzerzufriedenheit aus. Letztendlich sollte die Authentifizierung einfach funktionieren – unabhängig davon, welchen Passwort-Manager Ihre Nutzer wählen.

Über Corbado

Corbado ist die Passkey Intelligence Platform für CIAM-Teams, die Consumer-Authentifizierung im großen Maßstab betreiben. Wir zeigen Ihnen, was IDP-Logs und generische Analytics-Tools nicht sehen können: welche Geräte, OS-Versionen, Browser und Credential-Manager Passkeys unterstützen, warum Enrollments nicht zu Logins werden, wo der WebAuthn-Flow scheitert und wann ein OS- oder Browser-Update den Login still und leise unterbricht – und das alles, ohne Okta, Auth0, Ping, Cognito oder Ihren In-House-IDP zu ersetzen. Zwei Produkte: Corbado Observe ergänzt Observability für Passkeys und jede andere Login-Methode. Corbado Connect bringt Managed Passkeys mit integrierter Analytics (neben Ihrem IDP). VicRoads betreibt Passkeys für über 5 Mio. Nutzer mit Corbado (+80 % Passkey-Aktivierung). Mit einem Passkey-Experten sprechen →

Häufig gestellte Fragen#

Welche Drittanbieter-Passwort-Manager sollte ich beim Testen nativer App-Passkeys priorisieren?#

Priorisieren Sie 1Password, Bitwarden, Dashlane, Proton Pass und NordPass als primäre Ziele. Diese fünf Provider decken 85 % der Nutzer von Drittanbieter-Passwort-Managern in den Märkten EU/USA/UK/AUS/NZ ab und bieten eine breite Abdeckung, ohne übermäßig in kleinere Long-Tail-Provider zu investieren.

Warum lassen sich in einer nativen App erstellte Passkeys nicht über Geräte hinweg synchronisieren, wenn ein Drittanbieter-Passwort-Manager verwendet wird?#

Eine fehlerhafte Konfiguration der Flags für Backup Eligibility (BE) und Backup State (BS) ist eine Hauptursache für fehlerhafte geräteübergreifende Synchronisierungen. Einige Drittanbieter-Passwort-Manager setzen diese Flags falsch, sodass ein Passkey auf einem Gerät existiert, sich aber nicht mit anderen synchronisiert, selbst wenn derselbe Passwort-Manager auf beiden installiert ist.

Wie behebe ich Bugs im Android Credential Manager UI, die als separate Tasks im "Zuletzt verwendet"-Bildschirm erscheinen?#

Das Setzen von MainActivity auf launchMode singleInstance führt dazu, dass die Credential Manager-UI als separater Task geöffnet wird. Dies erzeugt einen verwirrenden Eintrag unter "Zuletzt verwendet" (Recents) und kann die App aufhängen lassen, wenn sie in den Hintergrund rückt. Das Ändern der Konfiguration zu launchMode singleTask löst dies über OEMs hinweg, einschließlich Samsung, Google und Vivo.

Welche Authentifizierungsabläufe muss ich testen, wenn ich die Unterstützung für Drittanbieter-Passwort-Manager in einer nativen iOS- oder Android-App validiere?#

Ein umfassender Testplan deckt 10 Szenarien ab: Passkey-Erstellung und eleganter Abbruch, Overlay- und Textfeld-Authentifizierung, in-App Credential-Verwaltung, Credential-Löschung mit Fallback sowie bidirektionale geräteübergreifende Synchronisierung. Plattformübergreifende Tests sollten zudem bestätigen, dass in der App erstellte Passkeys sich in einem Browser authentifizieren und im Web erstellte Passkeys sich in der nativen App authentifizieren lassen.