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

Mit der Veröffentlichung von iOS 17 und Android 14 hat sich die Passkey-Landschaft für native mobile Apps grundlegend verändert. Erstmals können Passwort-Manager von Drittanbietern als Passkey-Anbieter fungieren und durchbrechen damit das Monopol vom iCloud-Schlüsselbund und dem Google Passwortmanager. So können User ihre eigenen vertrauenswürdigen Lösungen wie 1Password, Bitwarden oder Dashlane in die Authentifizierungs-Flows nativer Apps integrieren. Das ist ein großer Gewinn für die Wahlfreiheit der User, bringt aber auch eine erhebliche Komplexität für Entwickler mit sich. Die Implementierung von Passkeys kann sich je nach Passwort-Manager in nativen mobilen Anwendungen unterschiedlich verhalten. Deshalb ist es für jedes Team wichtig, native App-Passkeys und Passwort-Manager von Drittanbietern sorgfältig zu testen.

Dieser umfassende Guide beschreibt unseren praxiserprobten Ansatz zum Testen von Passkeys in nativen Apps mit Passwort-Managern von Drittanbietern. Obwohl das Passkey-Ökosystem im Jahr 2025 deutlich gereift ist, erfordert die Implementierung in der Praxis nach wie vor eine sorgfältige Validierung über die verschiedenen Passwort-Manager-Implementierungen hinweg. Wir haben unsere Erfahrungen in einem praktischen Testplan zusammengefasst, der sicherstellt, dass Ihre native App reibungslos mit den von den Usern bevorzugten Passwort-Managern funktioniert.

Das Ökosystem der Passwort-Manager hat sich über die plattformeigenen Lösungen hinaus entwickelt. User entscheiden sich aktiv für Passwort-Manager von Drittanbietern wie 1Password, Bitwarden, Dashlane, Proton Pass und NordPass, je nach ihren spezifischen Bedürfnissen wie plattformübergreifende Synchronisierung, Unternehmensfunktionen oder Datenschutzpräferenzen. Eine native iOS-/Android-App muss diese Vielfalt berücksichtigen, ohne die User zum Wechsel ihrer vertrauten Passwort-Management-Lösung zu zwingen.

Basierend auf Daten, die wir auf den Corbado-Seiten erheben, sehen wir, dass sich nur 5–10 % der allgemeinen User auf Passwort-Manager von Drittanbietern verlassen. Auch wenn diese Zahl niedrig klingen mag, wird sie einen großen Einfluss auf die Wahrnehmung der 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 geringfügig anders implementieren, was zu feinen Unterschieden in der User Experience oder sogar zu Fehlern führt.

Native iOS- und Android-Apps bieten verschiedene Möglichkeiten zur Nutzung von Passkeys. Bei Android gibt es Passkey-Overlays und manuelle Eingaben in Textfeldern, die eine Passkey-Zeremonie auslösen (für Web-Apps unterstützt Android auch Conditional UI). iOS bietet neben Conditional UI und manuellen Eingaben in Textfeldern ebenfalls ein eigenes Set an Passkey-Overlays. Darüber hinaus gibt es weitere Edge Cases zu prüfen. Alles in allem muss eine native Anwendung Folgendes souverän handhaben:

• Passkey-Overlay-Logins, die sofort beim Laden der Seite erscheinen
• Conditional UI Logins (nur iOS), die automatisch verfügbare Passkeys vorschlagen
• Logins über Textfelder, bei denen der User seinen Benutzernamen eingibt, bevor er auf einen Button klickt
• Geräteübergreifende Authentifizierung (CDA) zur Nutzung von Passkeys mit einem anderen Gerät
• Fallback-Mechanismen, wenn die Passkey-Nutzung nicht verfügbar ist

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

• 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, dass der User seine lokale Authentifizierungsmethode verwenden muss
• Resident key/discoverable credentials: Ermöglicht die Authentifizierung ohne Benutzernamen (erlaubt Conditional UI)
• Backup eligibility (BE) und backup state (BS): Ermöglicht die geräteübergreifende Synchronisierung von Passkeys

Falsch konfigurierte Flags führen nicht immer zu sofortigen Fehlern. Sie können aber subtile Probleme und Inkonsistenzen verursachen, z. B. dass Passkeys auf einem Gerät verfügbar sind, aber nicht über Geräte hinweg synchronisiert werden (obwohl derselbe Passwort-Manager eines Drittanbieters auf beiden Geräten verfügbar sein könnte). Eine unserer Erkenntnisse bei den Tests war, dass einige Passwort-Manager von Drittanbietern die BE/BS-Flags falsch setzen und für einen großen Teil der Passkey-Probleme verantwortlich waren.

Architekturen mit einer einzigen Activity (Android) oder einer einzigen Scene (iOS) erfordern ein sorgfältiges Lifecycle-Management. Wenn ein Dialogfeld des Passwort-Managers erscheint und wieder geschlossen wird, muss eine 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.

Wir haben zum Beispiel 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 Benutzeroberfläche des Passkey Credential Managers als separater Task geöffnet wird. Dies fügt nicht nur einen verwirrenden, zusätzlichen App-Eintrag in der „Zuletzt verwendet“-Ansicht hinzu, sondern kann auch dazu führen, dass die App hängen bleibt, 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 startet, was einen vorhersagbareren Lifecycle über verschiedene OEMs (Samsung, Google, Vivo usw.) hinweg gewährleistet und das Risiko herstellerspezifischer Fehler reduziert. Es bietet eine stabilere Grundlage für das Testen von Navigation, Overlays und Deeplinks.

Wir haben beobachtet, dass sich solche Lifecycle-Probleme oft als „Fehler im Passwort-Manager“ tarnen, obwohl es sich in Wirklichkeit um Probleme auf Anwendungsebene handelt. Eine ordnungsgemäße Instrumentierung und Tests über verschiedene Anbieter hinweg helfen, diese Muster frühzeitig zu erkennen.

Bei den Tests für native App-Passkeys sollte der Fokus auf den am weitesten verbreiteten Passwort-Managern von Drittanbietern liegen:

Primäre Ziele (unverzichtbare Abdeckung):

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

Sekundäre Ziele (je nach User-Basis):

• Regionale Anbieter (z. B. Samsung Pass für Samsung-Geräte)
• Unternehmenslösungen, wenn Geschäftskunden die Zielgruppe sind
• Plattform-Standards (Google Passwortmanager, iCloud-Schlüsselbund) als Baseline

Man sollte der Versuchung widerstehen, jeden verfügbaren Passwort-Manager zu testen. Der Fokus sollte auf Anbietern liegen, die 90 % der User-Basis abdecken. Unsere Analysen haben gezeigt, dass die fünf primären Ziele 85 % der User von Drittanbieter-Passwort-Managern in der EU/USA/UK/AUS/NZ abdeckten.

Vor jedem Testlauf sollte eine saubere, reproduzierbare Umgebung sichergestellt werden:

1. Bereinigter Anmeldedaten-Status:

• Alle vorhandenen Anmeldedaten für Ihre RP-ID entfernen
• Browser- und App-Caches leeren
• Vollständig beim Passwort-Manager ab- und wieder anmelden
• Die zu testende App schließen und neu starten

2. Testumgebung stabilisieren:

• Stabile Netzwerkverbindung sicherstellen (keine VPNs während des Testens)
• UI-Animationen deaktivieren, wenn Tests automatisiert werden
• Konsistente Geräteausrichtung verwenden
• Betriebssystemversion, App-Version und Passwort-Manager-Version dokumentieren

Jeder Test validiert bestimmte Aspekte der Passkey-Funktionalität. Die Ergebnisse sollten systematisch mit einem Pass/Fail-Status und detaillierten Notizen zu Anomalien dokumentiert werden.

Korrekte Handhabung des Abbruchs validieren

✓ Das Dialogfeld des Passwort-Managers öffnet sich korrekt ✓ Der User bricht ab, ohne einen Passkey zu erstellen ✓ Die App kehrt zum Anmeldebildschirm zurück ✓ Keine verwaisten Anmeldedaten im Passwort-Manager ✓ Die Benutzeroberfläche zeigt geeignete Wiederholungsoptionen an

Passkey-Erstellung nach dem Authentifizierungs-Flow überprüfen

✓ Die lokale Authentifizierung startet zuverlässig ✓ Die biometrische Authentifizierung wird erfolgreich abgeschlossen ✓ Die Anmeldedaten werden mit der korrekten RP-ID erstellt ✓ Die App wechselt ohne Schleifen in den authentifizierten Zustand

Standard-Authentifizierungsszenarien testen

✓ Das Passkey-Overlay-UI erscheint oder der User gibt seinen Benutzernamen im Textfeld-Szenario ein ✓ Der biometrische Scan und eine einzige biometrische Abfrage führen zu einer erfolgreichen Authentifizierung ✓ Keine Auswahlschleifen oder erneutes Erscheinen des Dialogfelds ✓ Die Sitzung bleibt nach der Authentifizierung stabil

In-App-Passkey-Verwaltung validieren

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

Lifecycle-Management der Anmeldedaten testen

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

Portabilität von App zu Web validieren

✓ Der Browser erkennt die in der App erstellten Passkeys ✓ Das Auswahl-Dialogfeld zeigt die korrekte RP-Zuordnung an ✓ Die Authentifizierung wird ohne Umweg über QR/CDA abgeschlossen

Gemeinsame Nutzung von Anmeldedaten von Web zu App testen

✓ Die App zeigt die im Web erstellten Anmeldedaten in der Auswahl an ✓ Die Authentifizierung gelingt beim ersten Versuch ✓ Kein erzwungener Fallback auf das Passwort

Passkey-Synchronisierung von nativer App zum Desktop-Browser überprüfen

✓ Der in der App erstellte Passkey wird mit dem Desktop-Passwort-Manager synchronisiert ✓ Der synchronisierte Passkey funktioniert nahtlos im Desktop-Browser ✓ Es wird kein QR-Code-/geräteübergreifender Flow ausgelöst ✓ Die Authentifizierung wird ohne Schleifen oder Fehler abgeschlossen

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

✓ Der auf dem Desktop erstellte Passkey wird mit dem mobilen Passwort-Manager synchronisiert ✓ Die native App zeigt den synchronisierten Passkey korrekt an ✓ Die Authentifizierung gelingt ohne Passwort-Fallback ✓ Protokolle verknüpfen die Assertion mit der richtigen Credential-ID

Szenarien mit dem Smartphone als Sicherheitsschlüssel validieren

✓ Das Smartphone bietet die in der App erstellten Anmeldedaten für die Web-CDA an ✓ Keine falschen „Keine Passkeys verfügbar“-Fehler ✓ Die Web-Sitzung wird nach der mobilen Biometrie abgeschlossen

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

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

Lösung: Implementieren Sie eine Wiederholungslogik mit exponentiellem Backoff. Bieten Sie manuelle Aktualisierungsoptionen für User an, die Synchronisierungsverzögerungen feststellen.

Problem: Das Verhalten von Passwort-Managern variiert erheblich zwischen den Betriebssystemversionen, insbesondere bei Android 14+ und iOS 17+.

Lösung: Führen Sie eine Kompatibilitätsmatrix und passen Sie die Flows basierend auf der erkannten Betriebssystemversion an. Ziehen Sie Mindestversionsanforderungen für ein optimales Erlebnis in Betracht.

Die erfolgreiche Implementierung der Passkey-Unterstützung für Passwort-Manager von Drittanbietern in nativen Apps erfordert methodisches Testen und Liebe zum Detail. Unser umfassender, in der Praxis verfeinerter Testplan bietet eine solide Grundlage für die Validierung Ihrer Passkey-Integration.

Die wichtigsten Erkenntnisse für den produktiven Einsatz:

1. Systematisch testen: Nutzen Sie unseren Testplan als Grundlage und passen Sie ihn an Ihre spezifischen Anwendungsfälle an.
2. Wahlfreiheit der User respektieren: Unterstützen Sie die Passwort-Manager, die Ihre User bevorzugen, nicht nur die Plattform-Standards.
3. Kontinuierlich überwachen: Implementieren Sie ein umfassendes Logging, um Edge Cases in der Produktion zu erfassen.
4. Sorgfältig dokumentieren: Führen Sie klare Aufzeichnungen über anbieterspezifische Verhaltensweisen 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 entwickelt sich weiter. Wer jetzt ein robustes Test-Framework etabliert, ist darauf vorbereitet, sich an die Weiterentwicklung der Technologie anzupassen.

Wir werden unsere SDKs und unsere Testmethodik weiter aktualisieren, sobald neue Muster auftauchen. Die Investition in umfassende Tests von Passwort-Managern von Drittanbietern zahlt sich durch einen geringeren Supportaufwand und eine höhere User-Zufriedenheit aus. Schließlich sollte die Authentifizierung einfach funktionieren – unabhängig davon, welchen Passwort-Manager Ihre User wählen.