Passkeys in nativen Apps: Native vs. WebView-Implementierung

+70-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

Hinweis: System- und eingebettete WebViews werden oft kombiniert, wobei die System-WebView das Login (mit automatischer Freigabe von Anmeldeinformationen) übernimmt und die eingebettete WebView dann die Passkey-Verwaltung in den Einstellungen darstellt.

Wichtige Entscheidungsfaktoren:

• OAuth-basiertes Login? → System-WebView (ASWebAuthenticationSession, Chrome Custom Tabs)
• Web-Authentifizierung in einer nativen Hülle wiederverwenden? → Eingebettete WebView (WKWebView, Android WebView mit WebKit 1.12.1+)
• Eine native App von Grund auf entwickeln? → Native Implementierung (Apple AuthenticationServices, Google Credential Manager)

Moderne mobile Plattformen bieten drei verschiedene Ansätze zur Integration von Passkeys in Ihre native App. Jeder Ansatz hat unterschiedliche Kompromisse in Bezug auf Benutzererfahrung, technische Komplexität und OAuth-Kompatibilität:

1. Native Implementierung: Passkey-Flows werden direkt in Ihre App mit Plattform-APIs (iOS AuthenticationServices, Android Credential Manager) integriert. Dies bietet die beste Benutzererfahrung mit nahtloser biometrischer Authentifizierung, erfordert aber einen mittleren bis hohen technischen Implementierungsaufwand.

2. System-WebView: Die Browser-Komponente der Plattform (iOS ASWebAuthenticationSession / SFSafariViewController, Android Chrome Custom Tabs) wird zur Abwicklung der Authentifizierung verwendet. Dies eignet sich hervorragend für OAuth-basierte Login-Flows und teilt Anmeldeinformationen mit dem Systembrowser.

3. Eingebettete WebView: Eine anpassbare Webansicht (iOS WKWebView, Android WebView) wird in Ihre App eingebettet, um die Web-Authentifizierung mit einem nativen App-Skelett wiederzuverwenden. Dies bietet ein nativ anmutendes Erscheinungsbild ohne URL-Leisten und volle Kontrolle über die WebView-UI. Es erfordert zusätzliches Setup, einschließlich Berechtigungen und Entitlements (iOS) sowie die Konfiguration der WebView mit AndroidX WebKit 1.12.1+ (Android), um die Passkey-Funktionalität zu aktivieren.

Die richtige Wahl hängt von der Authentifizierungsarchitektur Ihrer App ab, ob Sie OAuth-Anbieter nutzen, wie viel Kontrolle Sie über die Benutzeroberfläche benötigen und ob Sie eine native App von Grund auf neu erstellen oder Web-Komponenten wiederverwenden.

Eine native Passkey-Implementierung bietet die optimale Benutzererfahrung, bei der Authentifizierungs-Flows direkt in die Benutzeroberfläche Ihrer App mit plattformspezifischen APIs integriert werden. Nutzer profitieren von plattform-nativen Dialogen, nahtloser biometrischer Verifizierung und den schnellstmöglichen Anmeldezeiten.

Wann sollte man eine native Implementierung wählen:

• Beim Erstellen einer neuen nativen App oder bei der Umgestaltung der Authentifizierung auf native Bildschirme
• Wenn die bestmögliche Benutzererfahrung mit sofortiger, stiller Authentifizierung gewünscht ist
• Automatische Passkey-Aufforderungen beim App-Start: Native Implementierungen können preferImmediatelyAvailableCredentials nutzen, um automatisch ein Passkey-Overlay anzuzeigen, sobald Passkeys verfügbar sind. Dies ermöglicht die schnellste Anmeldung, ohne dass zuerst eine Kennung eingegeben werden muss.
• Wenn volle Kontrolle über die UI und den Ablauf der Authentifizierung benötigt wird
• Wenn man bereit ist, in plattformspezifische Implementierungen (iOS Swift, Android Kotlin) zu investieren

Hauptvorteil: preferImmediatelyAvailableCredentials()

Native Implementierungen können preferImmediatelyAvailableCredentials() nutzen, um ein automatisches Passkey-Overlay zu erstellen, das sofort beim Start der App erscheint, wenn Passkeys verfügbar sind. Dieser benutzername-lose Flow bietet das schnellstmögliche Login-Erlebnis – Nutzer sehen ihre Passkeys sofort, ohne zuerst eine Kennung eingeben zu müssen. Diese Fähigkeit ist exklusiv für native Implementierungen und in WebView-Varianten nicht verfügbar.

Während WebView-Implementierungen Conditional UI (Passkey-Vorschläge in Eingabefeldern) verwenden können, bietet das automatische Overlay der nativen Implementierung eine überlegene UX mit höheren Passkey-Nutzungsraten, da die Authentifizierung sofort beim Start der App beginnt.

Überblick über die technischen Anforderungen:

Die native Passkey-Integration erfordert ein kryptografisches Vertrauen zwischen Ihrer App und Ihrer Web-Domain. Ohne dieses wird das Betriebssystem alle WebAuthn-Operationen ablehnen. Wichtige Anforderungen:

1. App-Domain-Zuordnungsdateien, die unter /.well-known/ gehostet werden
2. Korrekte Relying Party ID, die mit Ihrer Web-Domain übereinstimmt
3. Plattformspezifische Capabilities (detailliert in Abschnitt 4)

Der große Vorteil: Passkeys, die auf Ihrer Website erstellt wurden, funktionieren nahtlos in Ihrer App und umgekehrt.

Die native Implementierung von Passkeys auf iOS beinhaltet Apples AuthenticationServices Framework, das eine API für WebAuthn-Operationen bereitstellt:

Wichtige Komponenten:

• ASAuthorizationController: Verwaltet den Authentifizierungs-Flow
• ASAuthorizationPlatformPublicKeyCredentialProvider: Erstellt Passkey-Anfragen
• Drei verschiedene UI-Modi zur Handhabung von Passkey-Logins:
  • Textfeld-Login: Traditionelles Benutzernamenfeld, bei dem der Passkey-Login durch einen Klick auf einen Button gestartet wird
  • Passkey-Modal-Overlay: Betriebssystemdialog, der verfügbare Passkeys auflistet
  • Conditional UI: Passkey-Vorschläge in der QuickType-Leiste über der Tastatur

Entwicklungs-Tipps

• AASA Caching: Apple speichert die AASA-Datei aggressiv (bis zu 24 Stunden), was das Testen frustrierend machen kann. Lösung: Aktivieren Sie den Entwicklermodus auf Ihrem Testgerät und hängen Sie ?mode=developer an Ihre AASA-URL an, um ein frisches Abrufen zu erzwingen.
• Performance-Tests: Testen Sie mit iCloud-Konten, die Hunderte von Anmeldeinformationen enthalten, um die Latenz unter realen Bedingungen zu beobachten. Das System-Overlay kann bei vielen gespeicherten Passkeys eine leichte Verzögerung aufweisen.

Die native Passkey-Implementierung auf Android verwendet die Credential Manager API (oder die ältere FIDO2-API für Abwärtskompatibilität):

Wichtige Komponenten:

• CredentialManager: Zentrale API für alle Operationen mit Anmeldeinformationen
• CreatePublicKeyCredentialRequest: Für die Registrierung von Passkeys
• GetCredentialRequest: Für die Authentifizierung mit Passkeys
• Zwei primäre UI-Modi:
  • Textfeld-Login: Traditionelles Benutzernamenfeld, bei dem der Passkey-Login durch einen Klick auf einen Button gestartet wird
  • Passkey-Modal-Overlay: Betriebssystemdialog, der verfügbare Passkeys auflistet

Anmerkung: Android fehlt derzeit die Unterstützung für Conditional UI-Tastaturvorschläge in nativen Apps, die iOS bietet (obwohl Conditional UI in Web-Apps funktioniert).

Die native Implementierung von Passkeys birgt wichtige Herausforderungen und Lektionen: Die Integration auf Betriebssystemebene kann Probleme auf verschiedenen Geräten und Betriebssystemversionen aufwerfen.

1. Unser Team stieß beispielsweise auf Probleme wie das aggressive Caching der apple-app-site-association-Datei durch Apple (die zur Verknüpfung von App- und Web-Anmeldeinformationen verwendet wird) und feine UI-Unterschiede bei den biometrischen Aufforderungen bestimmter Android-OEMs.
2. Bedenken Sie außerdem, dass in einigen Unternehmensszenarien die Synchronisierung von Passkeys auf verwalteten Geräten durch Richtlinien deaktiviert sein kann. In Unternehmensumgebungen, in denen die Synchronisierung von iCloud Keychain oder Google Password Manager deaktiviert ist, werden Passkeys gerätegebunden und wandern nicht mit – ein wichtiges Szenario, das man einplanen sollte (z. B. sicherstellen, dass Benutzer sich auch dann noch anmelden können, wenn sie ein neues Telefon bekommen).
3. Zusätzlich können Drittanbieter-Apps für die Verwaltung von Anmeldeinformationen den Ablauf beeinflussen. Wenn ein Benutzer beispielsweise einen Passwort-Manager wie 1Password als aktiven Anbieter für Anmeldeinformationen eingerichtet hat, fängt dieser oft die Erstellung und Speicherung von Passkeys ab und hat Vorrang vor dem nativen Anmeldeinformationsmanager der Plattform.

Obwohl man Passkeys mit reinen Plattform-APIs implementieren kann, beschleunigen speziell entwickelte SDKs die Entwicklung erheblich, indem sie die Komplexität von WebAuthn und Randfälle handhaben sowie integrierte Telemetrie bereitstellen. SDKs bieten auch mockbare Schnittstellen für Unit-Tests (entscheidend, da man Biometrie nicht in Simulatoren testen kann).

Empfehlung: Für native Implementierungen empfehlen wir die Verwendung der Corbado SDKs (iOS Swift Passkey SDK, Android Kotlin Passkey SDK), die die zahlreichen, in Produktionsumgebungen entdeckten Randfälle abdecken, zusätzliche Telemetrie und Testmöglichkeiten bieten.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Passkeys, die Millionen begeistern. Starten Sie mit der Adoption-Plattform von Corbado.

Kostenlos testen

System-WebViews verwenden die native Browser-Komponente der Plattform, um die Authentifizierung innerhalb Ihrer App durchzuführen. Im Gegensatz zu vollständig nativen Implementierungen zeigen System-WebViews Webinhalte mit dem eigentlichen Systembrowser (Safari auf iOS, Chrome auf Android) an und behalten dabei geteilte Cookies, gespeicherte Anmeldeinformationen und die vertrauten Sicherheitsindikatoren des Browsers bei.

Wann sollte man eine System-WebView wählen:

• Ihre App verwendet OAuth-basiertes Login: Die System-WebView ist der empfohlene Ansatz für OAuth2/OIDC-Flows und bietet eine sichere Authentifizierung.
• Bestehende webbasierte Authentifizierung, die Sie in mobilen Apps wiederverwenden möchten.
• Wenn mehrere Authentifizierungsmethoden (Passwörter, Social Login, Passkeys) unterstützt werden sollen, ohne alles nativ neu zu erstellen.
• Wenn Sie eine einzige Authentifizierungs-Codebasis für Web und Mobilgeräte beibehalten möchten.

Wichtige Vorteile:

• OAuth-Kompatibilität: Speziell für OAuth/OIDC-Authentifizierungs-Flows entwickelt.
• Sicherheitsindikatoren: Benutzer sehen die tatsächliche URL und SSL-Zertifikate, was Vertrauen schafft.
• Geringer Implementierungsaufwand: Minimaler nativer Code erforderlich.
• Konsistente UX: Vertraute Browser-Oberfläche, der die Benutzer bereits vertrauen.

Plattform-Komponenten:

• iOS: ASWebAuthenticationSession (empfohlen für Authentifizierungs-Flows) oder SFSafariViewController (allgemeines Surfen)
• Android: Chrome Custom Tabs (CCT)

Große Unternehmen wie Google und GitHub haben diesen Ansatz gewählt, um den Passkey-Login zu ihren mobilen Apps über WebView-Overlays auf bestehenden Web-Authentifizierungsseiten hinzuzufügen. Dies funktioniert gut, wenn eine vollständig native Neuentwicklung der Authentifizierung nicht sofort machbar ist.

iOS bietet zwei primäre System-WebView-Komponenten für die Authentifizierung:

ASWebAuthenticationSession (Empfohlen für die Authentifizierung):

• Speziell für OAuth/OIDC und sichere Login-Flows entwickelt
• Fordert den Benutzer automatisch auf, dass die App sich authentifizieren möchte
• Teilt Cookies und Anmeldeinformationen mit Safari
• Unterstützt Passkeys über iCloud Keychain

SFSafariViewController (Allgemeines Surfen):

• Vollständiges Safari-Erlebnis innerhalb der App
• Zeigt URL-Leiste und Sicherheitsindikatoren an
• Teilt seit iOS 11+ keine Safari-Cookies mehr; verwenden Sie ASWebAuthenticationSession, wenn das Teilen der Safari-Sitzung erforderlich ist
• Weniger anpassbar, aber für Benutzer vertrauenswürdiger

Wenn Ihre App ein OAuth-basiertes Login verwendet, ist ASWebAuthenticationSession die empfohlene Wahl, da sie speziell für Authentifizierungsszenarien entwickelt wurde und die beste Balance zwischen Sicherheit und Benutzererfahrung bietet.

Chrome Custom Tabs (CCT) bieten ein von Chrome unterstütztes Authentifizierungserlebnis innerhalb Ihrer App:

Wichtige Merkmale:

• Teilt Cookies und Anmeldeinformationen mit dem Chrome-Browser
• Zeigt URL und Sicherheitsindikatoren an
• Kann die Farbe der Symbolleiste und das Branding anpassen
• Pre-Warming für schnellere Ladezeiten

OAuth-Integration: Chrome Custom Tabs sind das Android-Äquivalent zur iOS ASWebAuthenticationSession und bieten exzellente OAuth-Unterstützung bei gleichzeitigem Zugriff auf gespeicherte Passkeys.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Eingebettete WebViews bieten volle Kontrolle über das Rendern von Webinhalten innerhalb Ihrer App und ermöglichen die direkte Manipulation von Cookies, Sitzungen und Navigation ohne URL-Leiste. Diese Kontrolle erfordert jedoch zusätzliche technische Anforderungen, um die Passkey-Funktionalität zu ermöglichen.

Wann sollte man eine eingebettete WebView wählen:

• Nativ anmutendes Erlebnis: Ihre App bettet die Authentifizierung bereits in eine angepasste Webansicht ein, um ein natives Erscheinungsbild beizubehalten, und Sie möchten dieses konsistente Benutzererlebnis beibehalten.
• Bedarf an Sitzungs-/Cookie-Kontrolle: Ihre App erfordert die direkte Manipulation von Authentifizierungstoken und dem Sitzungsstatus, nachdem die OAuth-Authentifizierung abgeschlossen ist.
• Bestehender Authentifizierungs-Flow, bei dem die System-WebView-Authentifizierung einen Auth-Code, aber keine Sitzung in eingebetteten Kontexten zurückgibt.
• Authentifizierter Zustand muss über mehrere eingebettete Web-Bildschirme hinweg aufrechterhalten werden.
• Nur Erstanbieter-Authentifizierung: Ihre App behandelt die Authentifizierung direkt, für Drittanbieter-Passkey-Implementierungen siehe hier.
• AndroidX WebKit 1.12.1+ mit Laufzeit-Funktionserkennung.
• Akzeptanz der Einschränkung von Conditional UI für das Login (wird in eingebetteter WebView nicht unterstützt), nicht relevant für Verwaltungseinstellungen.

Wichtiger Kontext:

Viele Apps verwenden einen hybriden Ansatz: Die System-WebView übernimmt die anfängliche OAuth-Authentifizierung (bei der Passkeys nahtlos funktionieren) und wechselt dann zur eingebetteten WebView für die Nach-Authentifizierung, um Passkeys in den Einstellungen zu verwalten. Die Herausforderungen entstehen, wenn versucht wird, Passkeys direkt in eingebetteten WebViews zu verwenden.

Technische Anforderungen:

Eingebettete WebViews erfordern im Vergleich zu System-WebViews ein zusätzliches Setup:

1. iOS: Associated Domains Entitlements, AASA-Dateikonfiguration
2. Android: AndroidX WebKit 1.12.1+ mit WebView WebAuthn-Konfiguration (Funktionserkennung erforderlich)
3. Beide: Well-known-Zuordnungsdateien korrekt konfiguriert und Digital Asset Links

Plattform-Komponenten:

• iOS: WKWebView
• Android: android.webkit.WebView

Kompromisse:

• Mittlere Komplexität: Erfordert WebView-Konfiguration (Android WebKit 1.12.1+) und Entitlements-Setup (iOS)
• Geringere Passkey-Akzeptanz: Benutzer könnten im Vergleich zur nativen Implementierung auf mehr Hürden stoßen
• Conditional UI wird nicht unterstützt: Passkey-Autofill in Eingabefeldern funktioniert nicht in Android Embedded WebView
• Begrenzte Plattformunterstützung: Einige Funktionen funktionieren möglicherweise nicht konsistent (z. B. automatische Passkey-Erstellung)

Bei der Implementierung von Passkeys über WebViews ist das Verständnis der Unterscheidung zwischen System-WebViews und eingebetteten WebViews entscheidend. Die drei oben genannten Ansätze (Native Implementierung, System-WebView und eingebettete WebView) dienen jeweils unterschiedlichen Anwendungsfällen.

Auf iOS haben Sie mehrere Optionen, um Webinhalte in der App anzuzeigen:

• WKWebView ist eine anpassbare WebView, die Teil des WebKit-Frameworks ist (eingeführt in iOS 8). Sie gibt Ihnen viel Kontrolle über das Aussehen und Verhalten des Webinhalts.
• SFSafariViewController ist ein von Apple bereitgestellter View-Controller, der als leichtgewichtiger Safari-Browser innerhalb Ihrer App fungiert. Er verwendet die Engine von Safari. Ab iOS 11+ hat er einen separaten Cookie-Speicher und teilt keine Safari-Cookies. Verwenden Sie ASWebAuthenticationSession, wenn das Teilen der Safari-Sitzung erforderlich ist.
• SFAuthenticationSession / ASWebAuthenticationSession sind spezialisierte Web-Authentifizierungssitzungen (verfügbar seit iOS 11/12), die speziell für OAuth/OpenID oder andere sichere Anmeldeabläufe gedacht sind. Diese nutzen ebenfalls Safari im Hintergrund, sind aber auf Authentifizierungsabläufe ausgerichtet und behandeln automatisch Dinge wie geteilte Cookies und Single Sign-On (SSO).

Auf Android sind die Hauptoptionen:

• Android WebView ist das Standard-WebView-Widget (android.webkit.WebView), das im Wesentlichen ein Mini-Browser ist, der in Ihre Activities eingebettet werden kann. Es ist hochgradig anpassbar, läuft aber im Prozess Ihrer App.
• Chrome Custom Tabs (CCT) ist eine Funktion, die einen von Chrome unterstützten Tab im Kontext Ihrer App öffnet. Custom Tabs erscheinen als Teil Ihrer App, werden aber vom Chrome-Browser (sofern installiert) betrieben, mit Funktionen wie Pre-Loading, geteilten Cookies und der vertrauten URL-Leiste für das Vertrauen des Benutzers.

In den folgenden Abschnitten werden wir uns diese WebView-Typen für iOS und Android genauer ansehen und erörtern, welche für Passkey-Authentifizierungsabläufe am besten geeignet sein könnten.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Apples Plattform bietet die drei oben aufgeführten WebView-Optionen. Ihre Wahl beeinflusst, wie reibungslos Passkeys innerhalb der App verwendet werden können:

Zum Testen des unterschiedlichen WebView-Verhaltens in iOS empfehlen wir die App WebView - WKWebView and UIWebView rendering.

WKWebView ist eine vielseitige WebView-Komponente für iOS. Entwickler können eine WKWebView einbetten, um Webinhalte mit einem hohen Maß an Kontrolle über die Benutzeroberfläche und das Verhalten darzustellen. WKWebView verwendet dieselbe Rendering-Engine wie Safari, ist also sehr performant und unterstützt moderne Web-Funktionen. Theoretisch kann WKWebView WebAuthn (und damit Passkeys) handhaben, wenn es korrekt konfiguriert ist, aber beachten Sie, dass einige erweiterte Browser-Funktionen aus Sicherheitsgründen eingeschränkt sein könnten. Ein Punkt, auf den man achten sollte, ist, dass WKWebView standardmäßig keine Cookies oder Schlüsselbunddaten mit Mobile Safari teilt. Benutzer müssen sich möglicherweise erneut anmelden, da ihre WebView-Sitzung von der Safari-Sitzung isoliert ist. Da der Inhalt von WKWebView von der App vollständig angepasst werden kann, sieht der Benutzer keine Adressleiste oder Safari-Benutzeroberfläche – was für das Branding großartig ist, aber bedeutet, dass der Benutzer weniger Hinweise hat, um die Legitimität der Seite zu überprüfen (ein Anliegen in Bezug auf Anti-Phishing). Einige Apps haben WKWebView sogar missbraucht, um Skripte einzuschleusen oder Inhalte zu verändern (z.B. wurde bei TikTok festgestellt, dass es Tracking-JS über seinen In-App-Browser einschleust), daher muss man darauf achten, WKWebView auf eine sichere, für den Benutzer vertrauenswürdige Weise zu verwenden.

SFSafariViewController bietet ein In-App-Safari-Erlebnis. Wenn Sie eine URL mit SFSafariViewController öffnen, ist es fast so, als würden Sie sie im echten Safari-Browser öffnen, außer dass der Benutzer innerhalb der Benutzeroberfläche Ihrer App bleibt. Der Vorteil für Passkeys ist erheblich: Da es im Wesentlichen Safari ist, sind der iCloud Keychain des Benutzers und die gespeicherten Passkeys zugänglich. Beachten Sie, dass Cookies seit iOS 11+ nicht mehr geteilt werden. Das bedeutet, wenn der Benutzer bereits einen Passkey für Ihre Seite hat, kann Safari ihn finden und sogar die Conditional UI Autovervollständigung für eine einfache Anmeldung anzeigen. SFSafariViewController ist weniger anpassbar (man kann seine Symbolleiste nicht wesentlich ändern), aber er handhabt automatisch viele Sicherheits- und Datenschutzfunktionen. Die URL-Leiste wird angezeigt, komplett mit dem Schlosssymbol für HTTPS, was den Benutzern Vertrauen gibt, dass sie sich auf der richtigen Domain befinden. Im Allgemeinen gilt SFSafariViewController als sicherer als eine rohe WKWebView und ist einfacher zu implementieren (Apple stellt es als Drop-in bereit). Der Hauptkompromiss ist, dass Sie etwas Kontrolle über das Erscheinungsbild opfern. Für einen Authentifizierungsablauf ist das normalerweise akzeptabel. Die Priorität liegt hier auf Sicherheit und einfacher Anmeldung, worin SFSafariViewController durch die Nutzung des Safari-Kontexts hervorragend ist.

SFAuthenticationSession / ASWebAuthenticationSession – Diese Klassen (letztere ist der neuere, Swift-freundliche Name) sind speziell für Anmeldeabläufe wie OAuth oder OpenID Connect konzipiert. Wenn Sie einen Benutzer über eine Webseite authentifizieren müssen (vielleicht bei einem externen IdP), sind diese Sitzungen die empfohlene Wahl auf iOS. Sie sind SFSafariViewController sehr ähnlich, da sie den Safari-Browser im Hintergrund nutzen und Cookies/Speicher mit Safari teilen. Der Hauptunterschied besteht darin, dass SFAuthenticationSession den Benutzer immer darüber informiert, dass die App sich über eine Webseite authentifizieren möchte (zur Sensibilisierung des Benutzers), und sie verwendet automatisch die vorhandene Safari-Sitzung des Benutzers, falls verfügbar.

Der Vorteil ist ein nahtloses SSO-Erlebnis – wenn der Benutzer bereits beim Anbieter in Safari angemeldet ist, kann diese Sitzung dieses Cookie verwenden, um eine weitere Anmeldung zu vermeiden. Für Passkeys ist dies wichtig, da es bedeutet, dass jede in Safari/iCloud Keychain gespeicherte Passkey-Anmeldeinformation auch hier verwendet werden kann. Apples offizielle Anleitung ist, ASWebAuthenticationSession für alles zu verwenden, was wie ein Anmeldeablauf aussieht. Die Vorteile sind verbesserter Datenschutz (Ihre App sieht niemals die Anmeldeinformationen oder Cookies, Safari kümmert sich darum) und integrierte SSO-Unterstützung. Der Nachteil ist, dass es auf Authentifizierungsabläufe beschränkt ist (man würde es nicht verwenden, um einfach beliebige Webinhalte in der App darzustellen). Zusammenfassend lässt sich sagen, dass ASWebAuthenticationSession bei der Wahl eines WebView-Ansatzes auf iOS typischerweise die beste Wahl für die Implementierung von Passkeys ist, da sie sicher ist, den Zustand mit Safari teilt und speziell für die Authentifizierung entwickelt wurde.

Want to find out how many people use passkeys?

View Adoption Data

Bei Android fällt die WebView-Entscheidung zwischen der klassischen WebView und den Chrome Custom Tabs:

Zum Testen des unterschiedlichen WebView-Verhaltens in Android empfehlen wir die App WebView vs Chrome Custom Tabs.

Android WebView (android.webkit.WebView) ist eine Komponente, mit der Sie Webseiten in Ihr Activity-Layout einbetten können. Sie ähnelt der WKWebView darin, dass Sie die volle Kontrolle haben: Sie können die Navigation abfangen, JavaScript injizieren, die Benutzeroberfläche anpassen usw. Sie läuft auch im Prozess Ihrer App. Eine WebView für Passkeys zu verwenden bedeutet, dass Ihre App Ihre Web-Anmeldeseite lädt und diese Seite eine WebAuthn-Passkey-Zeremonie initiieren kann. Die moderne Android WebView unterstützt WebAuthn (vorausgesetzt, die WebView-Implementierung des Geräts ist über Android System WebView oder die Chrome-Komponente auf dem neuesten Stand). Eine wichtige Überlegung: Standardmäßig teilt eine Android WebView keine Cookies oder gespeicherten Anmeldeinformationen mit dem Chrome-Browser des Benutzers. Jeder in der WebView erstellte oder verwendete Passkey ist also möglicherweise für Chrome nicht bekannt und umgekehrt. Diese Isolation kann gut für die Sicherheit sein (Ihre App kann keine Browser-Cookies lesen), aber sie könnte Benutzer dazu zwingen, sich erneut anzumelden, wenn sie sich bereits in Chrome authentifiziert haben. Ein weiteres Problem ist das Vertrauen. Eine einfache WebView zeigt nicht die URL oder das SSL-Schlosssymbol an, sodass Benutzer Ihrer App vollständig vertrauen müssen, sie nicht zu phishen. Google hat sogar die Verwendung von WebView für Google-OAuth-Anmeldungen aufgrund potenzieller Phishing-Risiken verboten. Leistungsmäßig sind WebViews in Ordnung, können aber langsamer oder speicherintensiver sein als die Verwendung des Standardbrowsers des Benutzers, insbesondere beim Laden umfangreicher Seiten.

Chrome Custom Tabs (CCT) sind ein hybrider Ansatz. Sie ermöglichen Ihrer App, eine von Chrome gerenderte Seite zu öffnen, die aussieht, als wäre sie Teil Ihrer App. Sie können die Farbe der Symbolleiste anpassen, ein App-Logo hinzufügen usw., aber der Inhalt wird von Chrome in einem separaten Prozess gerendert. Für Passkeys haben CCTs mehrere Vorteile: Sie teilen die Cookies und Anmeldeinformationen des Benutzers mit Chrome, was bedeutet, dass, wenn der Benutzer einen Passkey über Chrome (Google Password Manager) gespeichert hat, der Custom Tab darauf zugreifen kann. Der Benutzer sieht auch die tatsächliche URL und die Sicherheitsindikatoren, was Vertrauen schafft. die Leistung ist oft besser – Chrome kann im Hintergrund „aufgewärmt“ werden, um schneller zu laden. Und wichtig ist, dass die Sicherheit stark ist: Da es im Wesentlichen die Chrome-App ist, schützen Dinge wie Google Safe Browsing die Sitzung, und Ihre App kann keine beliebigen Skripte in die Seite injizieren (was bestimmte Angriffe verhindert).

Der Nachteil ist, dass der Benutzer Chrome (oder einen unterstützten Browser) installiert und auf dem neuesten Stand haben muss. Die meisten Android-Benutzer haben das, aber auf einigen Geräten in bestimmten Regionen könnte dies ein Problem sein. Insgesamt sind Chrome Custom Tabs bei der Wahl eines eingebetteten Web-Ansatzes auf Android für Passkey-Flows zu empfehlen, da sie eine gute Balance zwischen Integration und Sicherheit bieten. Tatsächlich sind sie in vielerlei Hinsicht analog zu iOS' SFSafariViewController/ASWebAuthSession – sie nutzen den Standardbrowser für die Authentifizierung.

(Nebenbemerkung: Apples WKWebView vs. SFSafariViewController und Androids WebView vs. CCT haben viele Parallelen. Sowohl Safari VC als auch Chrome Tabs teilen den Browser-Status und bieten eine bessere Sicherheit, während WKWebView/Android WebView mehr Kontrolle geben, aber den Webinhalt isolieren. Für Passkeys ist das Teilen des Status (Cookies, Anmeldeinformationsspeicher) normalerweise wünschenswert, damit der Passkey nahtlos abgerufen und erstellt werden kann.)

Unabhängig davon, für welchen Implementierungsansatz Sie sich entscheiden, müssen bestimmte technische Anforderungen erfüllt sein, um die Passkey-Funktionalität zu ermöglichen. Dieser Abschnitt bietet eine umfassende Anleitung zur Konfiguration von Well-Known-Zuordnungsdateien, iOS-Entitlements und der Android-WebView-Konfiguration.

Hinweis zu verwalteten Geräten: Das Verhalten von Passkeys ändert sich erheblich auf verwalteten Geräten, bei denen Mobile Device Management (MDM)-Richtlinien die Speicherung von Anmeldeinformationen steuern. Informationen zum Testen von Passkeys auf verwalteten Geräten finden Sie unter Passkeys auf verwalteten iOS- und Android-Geräten.

Native und eingebettete WebView-Flows erfordern Zuordnungsdateien, um ein kryptografisches Vertrauen zwischen Ihrer App und Ihrer Web-Domain herzustellen. System-WebView (ASWebAuthenticationSession) und Chrome Custom Tabs erfordern keine App-zu-Website-Zuordnung.

Die AASA-Datei stellt die Verbindung zwischen Ihrer iOS-App und Ihrer Web-Domain her und ermöglicht es Passkeys, auf beiden Plattformen zu funktionieren.

Dateispeicherort: https://yourdomain.com/.well-known/apple-app-site-association

Konfigurationsanforderungen:

• Hosten unter /.well-known/apple-app-site-association auf Ihrer Domain
• Bereitstellung über HTTPS mit einem gültigen SSL-Zertifikat
• Content-Type: application/json
• Keine Weiterleitungen auf dem .well-known-Pfad
• Fügen Sie die Team-ID und Bundle-ID Ihrer App hinzu

Beispiel AASA-Datei:

{
    "webcredentials": {
        "apps": ["TEAMID123.com.example.app"]
    }
}

AASA-Caching und Testen:

Apple speichert AASA-Dateien aggressiv (bis zu 24-48 Stunden) über ein CDN, was die Entwicklung und das Testen erschweren kann. Um das Caching während der Entwicklung zu umgehen:

1. Aktivieren Sie den Entwicklermodus auf Ihrem Testgerät
2. Hängen Sie ?mode=developer an Ihre zugehörige Domain in Xcode an
3. Dies zwingt iOS, die neueste AASA-Datei direkt von Ihrem Server abzurufen

⚠️ Wichtig: Verwenden Sie ?mode=developer NICHT in Produktions-Releases. Dieser Parameter ist nur für die Entwicklung gedacht – die Verwendung in der Produktion verhindert, dass iOS Ihre AASA-Datei ordnungsgemäß erkennt, was die Passkey-Funktionalität beeinträchtigt.

Validierung: Verwenden Sie den AASA-Validator von Apple, um Ihre Konfiguration zu überprüfen.

Android verwendet Digital Asset Links, um die Beziehung zwischen Ihrer App und Ihrer Website zu überprüfen.

Dateispeicherort: https://yourdomain.com/.well-known/assetlinks.json

Konfigurationsanforderungen:

• Hosten unter /.well-known/assetlinks.json auf Ihrer Domain
• Bereitstellung über HTTPS mit gültigem Zertifikat
• Content-Type: application/json
• Fügen Sie den SHA256-Fingerabdruck Ihrer App hinzu (aus dem Signaturzertifikat)

Beispiel assetlinks.json-Datei:

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.example.app",
            "sha256_cert_fingerprints": [
                "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99"
            ]
        }
    }
]

Validierung: Verwenden Sie den Digital Asset Links Generator von Google, um Ihre Konfiguration zu erstellen und zu überprüfen.

iOS-Apps benötigen die richtigen Entitlements, um auf die Passkey-Funktionalität zugreifen zu können. Die Anforderungen unterscheiden sich geringfügig je nach Ihrem Implementierungsansatz.

Die Entitlements-Datei (oft Runner.entitlements in Flutter-Apps oder YourApp.entitlements in nativen iOS-Projekten genannt) definiert spezielle Berechtigungen und Fähigkeiten, die vom Apple-System gewährt werden. Für Passkeys konfiguriert diese Datei die Associated Domains.

Dateispeicherort: Typischerweise in Ihrem Xcode-Projekt unter ios/Runner/Runner.entitlements

Die native Implementierung und die eingebettete WebView erfordern die Associated Domains-Funktion, um Ihre App mit Ihrer Web-Domain zu verknüpfen. Die System-WebView (ASWebAuthenticationSession) benötigt dies nicht, da sie im Safari-Kontext läuft.

Setup in Xcode:

1. Öffnen Sie Ihr Projekt in Xcode
2. Wählen Sie Ihr App-Ziel aus
3. Gehen Sie zum Tab „Signing & Capabilities“
4. Klicken Sie auf „+ Capability“ und fügen Sie „Associated Domains“ hinzu
5. Fügen Sie Ihre Domain mit dem Präfix webcredentials: hinzu

Beispielkonfiguration:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>webcredentials:yourdomain.com</string>
        <string>webcredentials:subdomain.yourdomain.com</string>
    </array>
</dict>
</plist>

Mehrere Domains: Wenn Ihre App mit mehreren Domains arbeiten muss, benötigen Sie möglicherweise Related Origin Requests (ROR).

Android Embedded WebViews erhielten mit AndroidX WebKit 1.12 native WebAuthn-Unterstützung, was die Notwendigkeit von benutzerdefiniertem JavaScript-Bridge-Code überflüssig machte. System-WebView (Chrome Custom Tabs) erfordert keine Konfiguration – Anmeldeinformationen funktionieren automatisch.

Anforderungen:

• AndroidX WebKit 1.12.1 oder neuer (1.14.0+ empfohlen)
• Digital Asset Links konfiguriert
• WebView APK mit WebAuthn-Unterstützung (über Funktionserkennung prüfen)
• Hinweis: Die AndroidX Credentials-Bibliothek ist für WebView WebAuthn NICHT erforderlich, nur für vollständig native Implementierungen

Implementierung:

import androidx.webkit.WebSettingsCompat
import androidx.webkit.WebViewFeature
 
// Prüfen, ob Web Authentication unterstützt wird
if (WebViewFeature.isFeatureSupported(WebViewFeature.WEB_AUTHENTICATION)) {
    // Web Authentication aktivieren
    WebSettingsCompat.setWebAuthenticationSupport(
        webView.settings,
        WebSettingsCompat.WEB_AUTHENTICATION_SUPPORT_FOR_APP
    )
 
    // JavaScript aktivieren
    webView.settings.javaScriptEnabled = true
}

Wichtige Punkte:

• Keine JavaScript-Bridge erforderlich: WebAuthn funktioniert nativ in der WebView
• Funktionserkennung erforderlich: Überprüfen Sie immer WebViewFeature.WEB_AUTHENTICATION zur Laufzeit
• Conditional UI nicht unterstützt: mediation:"conditional" (Passkey-Autofill in Eingabefeldern) funktioniert nicht in der eingebetteten WebView
• Fallback-Strategie: Wenn die Funktion nicht verfügbar ist, verwenden Sie stattdessen Chrome Custom Tabs

Versionshinweise:

• Verwenden Sie WebKit 1.12.1 oder neuer (1.12.0 hatte ein Laufzeitverfügbarkeitsproblem)
• Die Funktionsunterstützung hängt von der WebView-APK-Version des Benutzers ab – ältere APKs auf dem Gerät stellen die Funktion nicht zur Verfügung

Vor AndroidX WebKit 1.12.0 gab es keine native WebAuthn-Unterstützung in der eingebetteten WebView. Teams mussten entweder:

1. Chrome Custom Tabs oder Auth Tab verwenden (empfohlen)
2. Eine benutzerdefinierte JavaScript-Bridge erstellen

Wenn Sie ältere Android-Versionen oder Geräte ohne aktualisierte WebView-APKs unterstützen müssen, finden Sie im Android's Credential Manager WebView Integration guide den Bridge-Code-Ansatz. Wir empfehlen jedoch dringend die Verwendung des nativen WebKit 1.12.1+-Ansatzes für moderne Apps.

Empfehlung: Verwenden Sie die native WebAuthn-Unterstützung mit AndroidX WebKit 1.12.1+. Falls zur Laufzeit nicht verfügbar, greifen Sie auf Chrome Custom Tabs zurück, die eine hervorragende Passkey-Unterstützung mit geteilten Anmeldeinformationen bieten.

Bei der Implementierung von Passkeys in nativen Apps müssen Sie ein Vertrauensverhältnis zwischen Ihrer App und Ihrer/Ihren Web-Domain(s) herstellen. Dieser Abschnitt behandelt den Umgang mit einzelnen Domains, mehreren verwandten Domains (ROR) und wie Sie überprüfen können, ob Ihre Well-Known-Zuordnungsdateien ordnungsgemäß konfiguriert sind.

Für Apps, die eine einzelne Domain verwenden (z. B. kayak.com), benötigen Sie:

• Eine AASA-Datei für iOS unter https://kayak.com/.well-known/apple-app-site-association
• Eine assetlinks.json für Android unter https://kayak.com/.well-known/assetlinks.json
• Associated Domains-Entitlement konfiguriert mit webcredentials:kayak.com

Related Origins (ROR) ist eine WebAuthn-Funktion, die es einem einzigen Satz von Passkeys ermöglicht, über mehrere verwandte Domains hinweg zu funktionieren (z. B. kayak.com, kayak.de, kayak.co.uk). ROR verwendet den /.well-known/webauthn-Endpunkt auf jeder Seite, um verwandte Ursprünge zu definieren, NICHT die AASA- oder assetlinks-Dateien.

Wichtige Punkte:

• ROR-Konfiguration: Jede Domain hostet /.well-known/webauthn mit der Liste der verwandten Ursprünge
• App-Zuordnungsdateien (AASA/assetlinks): Werden nur verwendet, um Apps ihren entsprechenden Websites zuzuordnen
• iOS 18+ Eingebettete WebView: Unterstützt ROR bei ordnungsgemäßer Konfiguration
• Associated Domains-Entitlements: Fügen Sie alle Domains hinzu, mit denen sich Ihre App authentifizieren muss

Konfigurationsbeispiel:

Wenn Ihre App mit kayak.com und kayak.de funktioniert, müssen beide Domains:

• Ihre jeweiligen AASA-Dateien mit derselben Team-ID und Bundle-ID hosten
• In den Associated Domains-Entitlements Ihrer App aufgeführt sein
• Ordnungsgemäß konfigurierte und zugängliche Well-Known-Dateien haben

Bevor Sie live gehen, überprüfen Sie, ob Ihre Well-Known-Dateien ordnungsgemäß konfiguriert und zugänglich sind. Apple und Google bieten CDN-basierte Test-URLs zur Überprüfung der Dateiverfügbarkeit:

Verwendung dieser Test-URLs:

• Klicken Sie auf die Links, um zu überprüfen, ob Apple/Google Ihre Well-Known-Dateien abrufen kann
• Der ?nocache=1-Parameter von Apple erzwingt einen frischen Abruf und umgeht den CDN-Cache
• Wenn die Dateien über diese URLs nicht zugänglich sind, funktioniert die Passkey-Funktionalität in Ihrer App nicht
• Ersetzen Sie kayak.com oder kayak.de in den obigen URL-Mustern durch Ihre eigene(n) Domain(s)

Test-Fallstrick: Stellen Sie sicher, dass alle Domains ordnungsgemäß konfigurierte Well-Known-Dateien haben. Eine fehlende oder falsch konfigurierte Datei auf einer beliebigen Domain kann die Passkey-Funktionalität für diese Domain unterbrechen.

Weitere Informationen: WebAuthn Relying Party ID in nativen Apps

Die Wahl des richtigen Implementierungsansatzes hängt von der Authentifizierungsarchitektur Ihrer App, den OAuth-Anforderungen und dem Bedarf an Sitzungskontrolle ab. Verwenden Sie diesen Entscheidungsbaum, um den besten Weg nach vorne zu bestimmen.

Beginnen Sie mit diesen Schlüsselfragen:

1. Verwendet Ihre App OAuth-basiertes Login (OAuth2, OIDC, Social-Login-Anbieter)?

   • Ja → System-WebView (Abschnitt 1.2)
     • iOS: Verwenden Sie ASWebAuthenticationSession
     • Android: Verwenden Sie Chrome Custom Tabs
     • Exzellente OAuth-Unterstützung mit geteilten Anmeldeinformationen

2. Möchten Sie die Web-Authentifizierung in einer nativ anmutenden Hülle wiederverwenden (keine URL-Leiste, volle UI-Kontrolle)?

   • Ja → Eingebettete WebView (Abschnitt 1.3) mit Konfiguration
   • iOS: WKWebView + Associated Domains-Entitlements
   • Android: WebView + AndroidX WebKit 1.12.1+-Konfiguration
   • Bietet ein natives Erscheinungsbild bei Wiederverwendung von Web-Komponenten
   • Hinweis: Conditional UI wird in der eingebetteten WebView nicht unterstützt
   • Nein → Erwägen Sie System-WebView oder native Implementierung

3. Erstellen Sie eine neue native App oder haben Sie native Anmeldebildschirme?

   • Ja → Native Implementierung (Abschnitt 1.1)
     • Beste Benutzererfahrung
     • Sofortige, stille Authentifizierung
     • Erfordert plattformspezifische Entwicklung

4. Haben Sie eine bestehende Web-Authentifizierung, die Sie wiederverwenden möchten?

   • Ja → System-WebView für eine schnelle Implementierung
   • Nein → Native Implementierung für optimale UX

So schneiden die einzelnen Ansätze in den Schlüsseldimensionen ab:

Erläuterung der Dimensionen:

• Passkeys erstellen: Wie einfach Benutzer mit diesem Ansatz Passkeys erstellen können
• Passkeys verwenden: Das Authentifizierungserlebnis bei der Verwendung vorhandener Passkeys
• Passkeys verwalten: Wie Benutzer Passkeys anzeigen, bearbeiten oder löschen
• Technische Komplexität: Entwicklungsaufwand und laufende Wartung
• OAuth-Unterstützung: Wie gut der Ansatz OAuth2/OIDC-Authentifizierungsabläufe handhabt
• Einrichtungszeit: Typischer Implementierungszeitraum

Empfohlen: System-WebView

Wenn Ihre App über OAuth2, OIDC oder Social-Login-Anbieter (Google, GitHub, Microsoft usw.) authentifiziert, ist die System-WebView die optimale Wahl:

• iOS: ASWebAuthenticationSession ist speziell für OAuth-Flows entwickelt
• Android: Chrome Custom Tabs bieten eine nahtlose OAuth-Integration
• Vorteile: Minimaler nativer Code, automatische Freigabe von Anmeldeinformationen
• Implementierung: Fügen Sie WebAuthn zu Ihrer Web-Authentifizierungsseite hinzu und laden Sie sie dann über die System-WebView

Beispiel: Reise-Apps wie kayak.com und kayak.de verwenden OAuth zur Authentifizierung. Die System-WebView ermöglicht es ihnen, ihre bestehende OAuth-Infrastruktur beizubehalten und gleichzeitig Passkey-Unterstützung über ihre Web-Authentifizierungsseiten hinzuzufügen.

Empfohlen: Hybrider Ansatz

Verwenden Sie die System-WebView für die anfängliche OAuth-Authentifizierung und dann die eingebettete WebView für Sitzungen nach der Authentifizierung:

1. Anfängliche Authentifizierung: Die System-WebView übernimmt OAuth + Passkey-Login
2. Sitzungsverwaltung: Wechseln Sie zur eingebetteten WebView für authentifizierte Webinhalte, bei denen Sie Cookie-/Sitzungskontrolle benötigen
3. Technisches Setup: Konfigurieren Sie sowohl die Anforderungen für die System- als auch für die eingebettete WebView – für Android stellen Sie sicher, dass AndroidX WebKit 1.12.1+ enthalten ist (siehe Abschnitt 5)

Wann zu verwenden: Apps, die über OAuth authentifizieren, aber dann authentifizierte Webinhalte anzeigen müssen, bei denen eine direkte Sitzungsmanipulation erforderlich ist.

Empfohlen: Native Implementierung

Entwickeln Sie von Grund auf neu oder haben Sie native Bildschirme? Gehen Sie vollständig nativ vor:

• iOS: Verwenden Sie das AuthenticationServices-Framework
• Android: Verwenden Sie die Credential Manager API
• Vorteile: Beste UX, sofortige Authentifizierung, volle Kontrolle
• Einzigartiger Vorteil: Verwenden Sie preferImmediatelyAvailableCredentials, um ein automatisches Passkey-Overlay beim App-Start anzuzeigen – exklusiv für native Implementierungen und bietet die höchsten Konversionsraten
• SDK-Empfehlung: Verwenden Sie Corbado SDKs (iOS, Android), um die Entwicklung mit in der Produktion getesteter Handhabung von Grenzfällen zu beschleunigen

Für neue Apps: Es wird dringend empfohlen, von Anfang an ein natives Login zu erstellen. Dies bereitet Sie auf eine optimale UX vor und vermeidet zukünftige Migrationen von WebView zu nativ.

Empfohlen: Phasengenaue Migration

• Phase 1: System-WebView-Passkeys - Fügen Sie Passkey-Unterstützung zum bestehenden Web-Login hinzu, laden Sie es über die System-WebView (ASWebAuthenticationSession/Chrome Custom Tabs). Schneller Erfolg mit minimalem nativen Code.
• Phase 2: Native Abfangung - Fügen Sie eine native Passkey-Prüfung hinzu, bevor die WebView angezeigt wird. Beispiel: kayak.com versucht zuerst eine native Passkey-Authentifizierung und greift bei Bedarf auf die WebView zurück. Dies bietet eine schnelle biometrische Anmeldung bei gleichzeitiger Wahrung der Abwärtskompatibilität.
• Phase 3: Vollständig nativ - Migrieren Sie schrittweise zu einer nativen Authentifizierung für Passkey-Benutzer und behalten Sie die WebView für ältere Methoden bei.

Dieser phasenweise Ansatz ermöglicht schrittweise Verbesserungen, ohne bestehende Benutzer zu stören.

Siehe Abschnitt 5 für detaillierte Konfigurationsanweisungen.

Das Testen von Passkeys in nativen Apps erfordert einen strukturierten, mehrschichtigen Ansatz. Folgen Sie der Testpyramide: Unit-Tests (isolierte Logik), Integrationstests (WebAuthn-Zeremonie auf Simulatoren/Emulatoren) und Systemtests (End-to-End auf physischen Geräten).

Wesentliche Testkategorien:

• Kernabläufe: Registrierung, Authentifizierung, geräteübergreifende Abläufe, Löschen von Passkeys
• Plattformabdeckung: iOS (nativ), Android (nativ), Webbrowser über verschiedene Betriebssystemversionen hinweg
• Domain-Zuordnung: Überprüfen Sie, ob AASA-Dateien (iOS) und Digital Asset Links (Android) zugänglich sind
• Abbruch-Abläufe: Testen Sie den Abbruch durch den Benutzer bei Betriebssystem-Aufforderungen und biometrischen Bildschirmen
• Fehlerbehandlung: Backend-Fehler, Netzwerk-Timeouts, Nichtübereinstimmung von Anmeldeinformationen
• Grenzfälle: Bildschirmsperre deaktiviert, iCloud/Google Password Manager deaktiviert
• OAuth-Abläufe: Vollständige OAuth + Passkey-Integration von Ende zu Ende
• Verwaltete Geräte: MDM-gesteuerte Umgebungen (siehe Tests auf verwalteten Geräten)
• Drittanbieter-Manager: Kompatibilität mit 1Password, Bitwarden, Dashlane
• Geräteübergreifende Authentifizierung: QR-Code-Abläufe und Hybrid-Transport-Tests
• Spezifisch für eingebettete WebView: Bei Verwendung von eingebetteter WebView, überprüfen Sie die Konfiguration von WebKit 1.12.1+ auf Android
• Produktionsüberwachung: Dashboard für Erfolgsraten, Fehler und Latenz

Für eine umfassende Testanleitung einschließlich Automatisierungsstrategien, plattformspezifischen Fallstricken und einer vollständigen Checkliste vor dem Start, siehe unseren dedizierten Leitfaden: Testen von Passkey-Flows in nativen iOS- und Android-Apps.

Erwägen Sie, Benutzer aufzufordern, Passkeys zu erstellen, nachdem eine erfolgreiche traditionelle Anmeldung (Passwort, OAuth) erfolgt ist. Dieser schrittweise Konvertierungsansatz:

• Stört bestehende Authentifizierungsabläufe nicht
• Ermöglicht eine geordnete Rückfallebene, wenn der Benutzer ablehnt
• Erhöht die Passkey-Akzeptanz im Laufe der Zeit, ohne Änderungen zu erzwingen
• Funktioniert gut mit allen drei Implementierungsansätzen

Beispiel: Nach dem OAuth-Login über die System-WebView eine native Aufforderung anzeigen: „Schnellere Anmeldung mit Face ID aktivieren?“ Bei Zustimmung wird ein Passkey über die in der System-WebView geladene Webseite erstellt.

Die Entscheidung, wie Passkeys implementiert werden – ob über native Implementierung, System-WebView oder eingebettete WebView – ist eine entscheidende Designentscheidung, die Sicherheit, Benutzererfahrung und Entwicklungskomplexität beeinflusst. Es gibt keine Einheitslösung.

Für OAuth-basierte Apps: System-WebView (ASWebAuthenticationSession, Chrome Custom Tabs) ist der empfohlene Ausgangspunkt. Sie bietet exzellente OAuth-Unterstützung, minimalen Implementierungsaufwand und automatische Freigabe von Anmeldeinformationen.

Für native Apps: Gehen Sie lieber früher als später nativ vor. Ein nativer Passkey-Login bietet die nahtloseste UX mit exklusiven Funktionen wie preferImmediatelyAvailableCredentials, das ein automatisches Passkey-Overlay beim App-Start ermöglicht – etwas, das WebView-Implementierungen nicht bieten können. Da iOS und Android nun erstklassige Unterstützung für Passkeys bieten, zeigen Erfolge in der Praxis eine hohe Akzeptanz. Die Werkzeuge (einschließlich Open-Source-SDKs und Plattformbibliotheken) sind so weit gereift, dass eine native Integration in einem angemessenen Zeitrahmen machbar ist. Obwohl man auf Gerätemanagement-Richtlinien, geräteübergreifende Synchronisierung und Drittanbieter achten muss, können diese Herausforderungen mit sorgfältiger Entwicklung und Tests bewältigt werden. Das Ergebnis ist ein App-Login, der die Benutzer mit seiner Einfachheit und Geschwindigkeit begeistert und gleichzeitig die Sicherheit erheblich verbessert.

Für Anforderungen an eingebettete WebView-Frames: Die eingebettete WebView wird in zwei realen Szenarien häufig verwendet. Erstens verwenden OAuth-basierte Apps oft die System-WebView für den anfänglichen Anmeldeablauf und wechseln dann zur eingebetteten WebView, um Passkey-Verwaltungsoptionen in Einstellungsbildschirmen darzustellen, wo eine Sitzungskontrolle erforderlich ist – obwohl einige Apps dies vereinfachen, indem sie die System-WebView für beide Abläufe beibehalten. Zweitens setzen Apps, die ihren Authentifizierungsablauf bereits vor der Einführung von Passkeys in WebView-Frames eingebettet hatten, dieses Muster aus Konsistenzgründen fort. Die eingebettete WebView mit nativer WebAuthn-Unterstützung (AndroidX WebKit 1.12.1+) erfordert Konfiguration und Einrichtung (Berechtigungen, Entitlements, WebView-Einstellungen), benötigt aber keinen benutzerdefinierten JavaScript-Bridge-Code mehr. Beachten Sie, dass Conditional UI in der eingebetteten WebView nicht unterstützt wird. Wählen Sie diesen Ansatz, wenn Sie bestehende eingebettete Authentifizierungsmuster beibehalten oder wenn Sie eine Sitzungs-/Cookie-Kontrolle für Bildschirme nach der Authentifizierung benötigen.

Letztendlich stellen Passkeys in nativen Apps einen gewaltigen Fortschritt in Bezug auf Benutzerfreundlichkeit und Sicherheit dar. Ob über Native, System-WebView oder Embedded WebView implementiert, sie eliminieren Phishing-Risiken und die Last der Passwortverwaltung für Ihre Benutzer. Praxisbeispiele wie die native App-Passkey-Integration von VicRoads zeigen, dass native Ansätze die höchste Benutzerakzeptanz und -zufriedenheit liefern, wenn sie ordnungsgemäß mit Funktionen wie automatischen Passkey-Overlays umgesetzt werden. Indem Sie Best Practices für eine benutzerfreundliche Authentifizierung befolgen und den Implementierungsansatz wählen, der zur Architektur Ihrer App passt – nativ für neue Apps, System-WebView für OAuth-Flows oder Embedded WebView für bestehende eingebettete Muster – können Sie passwortlose, biometrische Anmeldungen anbieten, die die Vision von Passkeys wirklich verwirklichen: einfache, sichere und begeisternde Authentifizierung für alle.

Wenn Passkeys in Ihrer nativen App nicht funktionieren, überprüfen Sie diese häufigen Probleme je nach Implementierungsansatz:

• Dateien werden über HTTPS mit gültigem Zertifikat bereitgestellt
• Korrekter MIME-Typ: application/json
• Keine Weiterleitungen auf dem .well-known-Pfad
• iOS: Team-ID und Bundle-ID stimmen in der AASA-Datei exakt überein
• Android: SHA256-Fingerabdruck stimmt mit Ihrem Signaturzertifikat in assetlinks.json überein
• Relying Party ID stimmt mit Ihrer Domain überein (kein Protokoll, kein Port)
• Keine abschließenden Schrägstriche in der RP-ID
• WebAuthn-Origin: https://your-domain.com (nicht app://)

• iOS: Associated Domains-Funktion in Xcode mit webcredentials:yourdomain.com aktiviert
• Android: Digital Asset Links in AndroidManifest.xml deklariert
• Benutzer hat Bildschirmsperre aktiviert (biometrisch oder PIN)
• Testen mit dem AASA-Validator von Apple und dem Digital Asset Links-Tool von Google
• Überprüfen Sie, ob die Runner.entitlements-Datei die korrekten zugehörigen Domains enthält

• iOS: Verwendung von ASWebAuthenticationSession (empfohlen) oder SFSafariViewController
• Android: Verwendung von Chrome Custom Tabs (nicht einfache WebView)
• iOS: Überprüfen Sie, ob Associated Domains bei Bedarf konfiguriert sind
• Testen Sie, ob Cookies/Anmeldeinformationen mit dem Systembrowser geteilt werden
• Überprüfen Sie, ob die Web-Authentifizierungsseite eine korrekte WebAuthn-Implementierung hat

• iOS: Mit den richtigen Entitlements konfiguriert
• iOS: Associated Domains umfassen alle relevanten Domains
• iOS: AASA-Datei zugänglich und korrekt formatiert
• iOS: Testen mit ?mode=developer während der Entwicklung (für die Produktion entfernen)
• Android: AndroidX WebKit 1.12.1+ (oder neuer) im Projekt enthalten
• Android: Laufzeit-Feature-Check für WebViewFeature.WEB_AUTHENTICATION
• Android: setWebAuthenticationSupport() mit WEB_AUTHENTICATION_SUPPORT_FOR_APP aufgerufen
• Android: JavaScript in den WebView-Einstellungen aktiviert
• Android: Die WebView-APK-Version des Benutzers unterstützt die WebAuthn-Funktion (Feature-Erkennung verwenden, nicht die Betriebssystemversion)
• Conditional UI nicht verwendet (wird in eingebetteter WebView nicht unterstützt)
• Fallback auf Chrome Custom Tabs, wenn die WebAuthn-Funktion nicht verfügbar ist

• Prüfen Sie, ob der Benutzer einen nicht standardmäßigen Anmeldeinformationsanbieter aktiv hat (1Password, Bitwarden usw.)
• Überprüfen Sie, ob der Anbieter Passkeys unterstützt (nicht alle Passwort-Manager tun dies)
• Testen Sie mit dem plattformeigenen Anmeldeinformationsmanager (iCloud Keychain, Google Password Manager)

"NotAllowedError: The request is not allowed by the user agent or the platform in the current context"

• Bedeutet normalerweise: Fehlende Entitlements (iOS) oder WebView-Funktion nicht verfügbar/aktiviert (Android Embedded WebView)
• Prüfen: Associated Domains-Konfiguration, Zugänglichkeit der AASA-Datei, WebKit-Version, Funktionserkennung, setWebAuthenticationSupport()-Aufruf

Keine Passkey-Aufforderung erscheint

• Könnte bedeuten: AASA/assetlinks.json wird nicht geladen, falscher WebView-Typ, gecachte AASA-Datei
• Versuchen Sie: Zuordnungsdateien validieren, ?mode=developer auf iOS zum Testen verwenden, WebView-Typ überprüfen

Für eine detaillierte Fehlersuche, siehe unseren Artikel über Relying Party IDs in nativen Apps.

Corbado Native SDKs:

• iOS SDK (Swift)
• Android SDK (Kotlin)
• Flutter Package

Plattform-Dokumentation:

• Apple: Supporting Passkeys
• Google: Credential Manager

Validierungs-Tools:

• Apple AASA Validator
• Google Digital Asset Links Generator