Testen von Passkeys für native Apps mit Passwort-Managern

1. Einleitung: 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 Passwort-Manager von Drittanbietern als Passkey-Provider fungieren und damit das Monopol von iCloud Keychain und dem Google Password Manager brechen. Das ermöglicht es Usern, ihre eigenen vertrauten Lösungen wie 1Password, Bitwarden oder Dashlane in die Authentifizierungsabläufe nativer Apps zu integrieren. Während dies ein riesiger Gewinn für die Wahlfreiheit der User ist, bringt es für Entwickler eine erhebliche Komplexität mit sich. Eure Passkey-Implementierung kann sich in nativen mobilen Anwendungen je nach Passwort-Manager unterschiedlich verhalten. Daher ist es für jedes Team wichtig, Native App Passkeys und Drittanbieter-Passwort-Manager gründlich zu testen.

Dieser umfassende Guide teilt unseren praxiserprobten Ansatz für das Passkey-Testing in nativen Apps mit Drittanbieter-Passwort-Managern. Auch wenn das Passkey-Ökosystem im Jahr 2025 deutlich reifer geworden ist, erfordert die Implementierung in der realen Welt immer noch eine sorgfältige Validierung über verschiedene Passwort-Manager hinweg. Wir haben unsere Erfahrungen in einen praktischen Testplan destilliert, der sicherstellt, dass eure Native App nahtlos mit den bevorzugten Passwort-Managern der User funktioniert.

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

2.1 User bringen ihren eigenen Passwort-Manager mit#

Das Ökosystem der Passwort-Manager hat sich über die plattformeigenen Lösungen hinaus entwickelt. User entscheiden sich aktiv für Drittanbieter wie 1Password, Bitwarden, Dashlane, Proton Pass und NordPass, basierend auf ihren spezifischen Bedürfnissen – sei es plattformübergreifende Synchronisation, Enterprise-Features oder Datenschutzpräferenzen. Eure native iOS- oder Android-App muss dieser Vielfalt gerecht werden, ohne die User zu zwingen, ihre vertraute Lösung zu wechseln.

Basierend auf Daten, die wir auf Corbado-Seiten messen, verlassen sich nur 5-10 % der allgemeinen User auf Drittanbieter-Passwort-Manager. Auch wenn diese Zahl niedrig klingen mag, hat sie einen enormen Einfluss auf die Wahrnehmung eurer Passkey-Implementierung und die Anzahl der Support-Tickets, besonders wenn ihr in einer Large-Scale-Umgebung arbeitet. Wir haben gesehen, dass einige Passwort-Manager die WebAuthn-Spezifikation leicht unterschiedlich implementieren, was zu subtilen Variationen in der User Experience (UX) oder sogar zu Bugs führen kann.

2.2 Unterschiedliche UX-Patterns in nativen Apps#

Native iOS- und Android-Apps bieten verschiedene Wege für die Passkey-Nutzung. Unter Android werdet ihr auf Passkey-Overlays und manuelle Textfeldeingaben stoßen, die eine Passkey-Zeremonie auslösen (für Web-Apps unterstützt Android auch Conditional UI). iOS präsentiert sein eigenes Set an Passkey-Overlays neben Conditional UI und manuellen Textfeldeingaben. Darüber hinaus gibt es weitere Edge Cases zu prüfen. Insgesamt muss eure native Anwendung folgende Szenarien 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 User ihren Nutzernamen eingeben, bevor sie auf einen Button klicken
• Geräteübergreifende Authentifizierung (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 wie erwartet über Geräte und Plattformen hinweg funktionieren. Kritische Werte sind:

• Relying Party ID (rpID): Muss exakt zwischen Web- und nativen Implementierungen übereinstimmen und ist die Domain, an die der Passkey gebunden ist
• User Verification: Legt fest, ob der User seine lokale Authentifizierung (z. B. Biometrie) durchführen muss
• Resident Key / Discoverable Credentials: Ermöglicht die Authentifizierung ohne Nutzernamen (erlaubt Conditional UI)
• Backup Eligibility (BE) und Backup State (BS): Ermöglicht die geräteübergreifende Synchronisation von Passkeys

Falsch konfigurierte Flags verursachen nicht immer sofortige Fehler. Sie können jedoch subtile Probleme und Inkonsistenzen erzeugen – zum Beispiel sind Passkeys auf einem Gerät verfügbar, werden aber nicht synchronisiert (obwohl derselbe Drittanbieter-Passwort-Manager auf beiden Geräten verfügbar ist). Eines unserer Testergebnisse war, dass einige Drittanbieter-Passwort-Manager die BE/BS-Flags inkorrekt setzten, was einen großen Teil der Passkey-Probleme ausmachte.

2.4 Lifecycle-Management in Single-Instance-Apps#

Single-Activity (Android) und Single-Scene (iOS) Architekturen erfordern ein akribisches Lifecycle-Management. Wenn sich ein Passwort-Manager-Sheet öffnet und wieder schließt, muss eure App den Status bewahren, Callbacks verarbeiten und korrekt fortfahren. Dies ist besonders kritisch unter Android, wo die launchMode-Konfiguration unerwartetes Verhalten verursachen kann.

Wir haben beispielsweise festgestellt, dass die Einstellung MainActivity auf launchMode="singleInstance" Probleme verursachte. Auf einigen Android-Versionen und OEM-Anpassungen führt dieser Modus dazu, dass sich die Passkey Credential Manager UI als separater Task öffnet. Das fügt nicht nur einen verwirrenden, zusätzlichen App-Eintrag zum „Recents“-Bildschirm hinzu, sondern kann auch dazu führen, dass die App hängt, wenn sie in den Hintergrund geschoben wird, während der Passkey-Dialog offen ist.

Der empfohlene Fix ist, die Konfiguration auf launchMode="singleTask" zu ändern. Dies verhindert, dass der Credential Manager einen separaten Task startet, sorgt für einen vorhersehbareren Lifecycle über verschiedene OEMs hinweg (Samsung, Google, Vivo etc.) und reduziert 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. Eine saubere Instrumentierung und Tests mit verschiedenen Anbietern helfen, diese Muster frühzeitig zu erkennen.

3. Einrichten der Testumgebung#

3.1 Ziel-Passwort-Manager#

Konzentriert euer Passkey-Testing für native Apps auf die am weitesten verbreiteten Drittanbieter-Lösungen:

Primäre Ziele (essenzielle Abdeckung):

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

Sekundäre Ziele (basierend auf eurer User-Basis):

• Regionale Anbieter (z. B. Samsung Pass für Samsung-Geräte)
• Enterprise-Lösungen, falls ihr Geschäftskunden ansprecht
• Plattform-Standards (Google Password Manager, iCloud Keychain) als Baseline

Vermeidet die Versuchung, jeden verfügbaren Passwort-Manager zu testen. Konzentriert euch auf die Anbieter, die 90 % eurer User-Basis ausmachen. Unsere Analysen zeigten, dass die fünf primären Ziele 85 % der Nutzer von Drittanbieter-Passwort-Managern in EU/USA/UK/AUS/NZ abdecken.

3.2 Pre-Flight Checklist#

Stellt vor jedem Testlauf eine saubere, reproduzierbare Umgebung sicher:

1. Sauberer Credential-Status:

• Entfernt alle existierenden Credentials für eure RP ID
• Leert Browser- und App-Caches
• Meldet euch vollständig beim Passwort-Manager ab und wieder an
• Erzwingt das Schließen und Neustarten der Ziel-App

2. Stabilisierung der Testumgebung:

• Stellt eine stabile Netzwerkverbindung sicher (keine VPNs während des Tests)
• Deaktiviert UI-Animationen, falls ihr Tests automatisiert
• Nutzt eine konsistente Geräteausrichtung
• Dokumentiert OS-Version, App-Version und Passwort-Manager-Version

4. Der umfassende Testplan#

Jeder Test validiert spezifische Aspekte der Passkey-Funktionalität. Dokumentiert die Ergebnisse systematisch mit Pass/Fail-Status und detaillierten Notizen für etwaige Anomalien.

4.1 Core Authentication Flow Tests#

Test 1: Passkey-Erstellung abbrechen (nach erfolgreichem konventionellen Login)#

Validierung der Abbruch-Behandlung

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

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

Verifizierung der Passkey-Erstellung nach dem Auth-Flow

✓ Lokale Authentifizierung startet zuverlässig ✓ Biometrische Authentifizierung wird erfolgreich abgeschlossen ✓ Credential wird mit korrekter RP ID erstellt ✓ App wechselt in den authentifizierten Zustand ohne Loops

Test 3: Authentifizierung mit existierendem Passkey#

Testen von Standard-Authentifizierungsszenarien

✓ Passkey-Overlay UI erscheint oder User gibt Nutzernamen im Textfeld-Szenario ein ✓ Biometrischer Scan und einzelne biometrische Aufforderung führen zur erfolgreichen Authentifizierung ✓ Keine Auswahl-Loops oder wiederholtes Erscheinen des Sheets ✓ Session bleibt nach der Authentifizierung stabil

Test 4: Passkey aus den Einstellungen erstellen#

Validierung des In-App Passkey-Managements

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

Test 5: Passkey löschen und Re-Login versuchen#

Testen des Credential Lifecycle Managements

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

4.2 Cross-Platform Kompatibilitätstests#

Test 6: Nativ erstellten Passkey im Web nutzen (Gleiches Gerät)#

Validierung der App-zu-Web Portabilität

✓ Browser erkennt in der App erstellte Passkeys ✓ Auswahl-Sheet zeigt korrekte RP-Zuordnung ✓ Authentifizierung schließt ohne QR/CDA-Umweg ab

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

Testen des Web-zu-App Credential Sharings

✓ App zeigt im Web erstelltes Credential in der Auswahl an ✓ Erster Authentifizierungsversuch ist erfolgreich ✓ Kein erzwungener Passwort-Fallback

Test 8: Cross-Device Sync (Mobile zu Desktop)#

Verifizierung des Passkey-Syncs von nativer App zum Desktop-Browser

✓ App-erstellter Passkey synchronisiert zum Desktop-Passwort-Manager ✓ Synchronisierter Passkey funktioniert nahtlos im Desktop-Browser ✓ Kein QR-Code / Cross-Device-Flow wird ausgelöst ✓ Authentifizierung schließt ohne Loops oder Fehler ab

Test 9: Cross-Device Sync (Desktop zu Mobile)#

Verifizierung des Passkey-Syncs vom Desktop-Browser zur nativen App

✓ Desktop-erstellter Passkey synchronisiert zum mobilen Passwort-Manager ✓ 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 Web#

Validierung von „Handy als Sicherheitsschlüssel“-Szenarien

✓ Handy bietet 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 Lösungsstrategien#

Unsere umfangreichen Tests haben mehrere wiederkehrende Muster aufgedeckt, die die Integration von Passwort-Managern betreffen:

Verzögerungen bei Cross-Device Sync#

Problem: Credentials, die auf einem Gerät erstellt wurden, erscheinen möglicherweise nicht sofort auf anderen.

Lösung: Implementiert Retry-Logik mit exponentiellem Backoff. Bietet manuelle Refresh-Optionen für User an, die Sync-Verzögerungen erleben.

Versionsspezifisches Verhalten#

Problem: Das Verhalten von Passwort-Managern variiert signifikant zwischen OS-Versionen, besonders unter Android 14+ und iOS 17+.

Lösung: Pflegt eine Kompatibilitätsmatrix und passt die Flows basierend auf der erkannten OS-Version an. Zieht Mindestversionsanforderungen für eine optimale Experience in Betracht.

6. Fazit: Passkey-Support reif für die Produktion machen#

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

Wichtige Erkenntnisse für das Deployment in Produktion:

1. Systematisch testen: Nutzt unseren Testplan als Baseline und passt ihn an eure spezifischen Use Cases an
2. Wahlfreiheit respektieren: Unterstützt die Passwort-Manager, die eure User bevorzugen, nicht nur die Plattform-Standards
3. Kontinuierlich überwachen: Implementiert umfassendes Logging, um Edge Cases in der Produktion abzufangen
4. Gründlich dokumentieren: Führt klare Aufzeichnungen über anbieterspezifische Verhaltensweisen und Workarounds

Das Passkey-Ökosystem entwickelt sich rasant weiter. Passwort-Manager aktualisieren regelmäßig ihre Implementierungen, Betriebssysteme führen neue Features ein und die WebAuthn-Spezifikation selbst schreitet voran. Indem ihr jetzt ein robustes Test-Framework etabliert, seid ihr vorbereitet, euch anzupassen, wenn die Technologie reift.

Wir werden unsere SDKs und Testmethoden weiter aktualisieren, sobald neue Muster auftauchen. Die Investition in umfassende Tests mit Drittanbieter-Passwort-Managern zahlt sich durch reduzierten Support-Aufwand und höhere Kundenzufriedenheit aus. Am Ende sollte die Authentifizierung einfach funktionieren – egal welchen Passwort-Manager eure User wählen.