Native App Passkeys: Native vs. WebView Implementierung

Hinweis: System- und Embedded-WebView werden oft kombiniert, wobei System-WebView den Login übernimmt (mit automatischem Teilen der Anmeldedaten), und Embedded-WebView dann das Passkey-Management in den Einstellungen rendert.

Wichtige Entscheidungsfaktoren:

• OAuth-basierter Login? → System-WebView (ASWebAuthenticationSession, Chrome Custom Tabs)
• Web-Auth in nativer Shell wiederverwenden? → Embedded-WebView (WKWebView, Android WebView mit WebKit 1.12.1+)
• Entwicklung einer Native-First-App? → Native Implementierung (Apple AuthenticationServices, Google Credential Manager)

Moderne mobile Plattformen bieten drei verschiedene Ansätze zur Integration von Passkeys in Ihre native App, jeweils mit unterschiedlichen Vor- und Nachteilen für UX, technische Komplexität und OAuth-Kompatibilität:

1. Native Implementierung: Erstellen Sie Passkey-Flows direkt in Ihrer App mithilfe von Plattform-APIs (iOS AuthenticationServices, Android Credential Manager). Bietet die beste UX mit nahtloser biometrischer Authentifizierung, erfordert jedoch einen mittleren bis hohen technischen Implementierungsaufwand.

2. System-WebView: Verwenden Sie die Browser-Komponente der Plattform (iOS ASWebAuthenticationSession / SFSafariViewController, Android Chrome Custom Tabs), um die Authentifizierung zu handhaben. Hervorragend geeignet für OAuth-basierte Login-Flows und teilt Anmeldedaten mit dem Systembrowser.

3. Embedded-WebView: Betten Sie einen anpassbaren Web View (iOS WKWebView, Android WebView) in Ihre App ein, um Web-Authentifizierung in einem nativen App-Rahmen wiederzuverwenden. Bietet ein natives Erscheinungsbild ohne URL-Leisten und volle Kontrolle über die WebView-UI. Erfordert zusätzliches Setup einschließlich Berechtigungen und Entitlements (iOS) sowie WebView-Konfiguration mit AndroidX WebKit 1.12.1+ (Android), um 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 UI benötigen und ob Sie Native-First entwickeln oder Web-Komponenten wiederverwenden.

Enterprise-Passkey-Whitepaper. Praxisnahe Leitfäden, Rollout-Muster und KPIs für Passkey-Programme.

Whitepaper erhalten

Eine native Passkey-Implementierung bietet die optimale UX, mit Authentifizierungs-Flows, die direkt über plattformspezifische APIs in die Benutzeroberfläche Ihrer App integriert sind. Nutzer profitieren von nativen Plattform-Dialogen, nahtloser biometrischer Verifizierung und den schnellstmöglichen Login-Zeiten.

Wann Sie die native Implementierung wählen sollten:

• Erstellung einer neuen nativen App oder Refactoring der Authentifizierung zu nativen Screens
• Sie möchten die bestmögliche UX mit sofortiger, stiller Authentifizierung
• Automatische Passkey-Prompts beim App-Start: Native Implementierungen können preferImmediatelyAvailableCredentials nutzen, um automatisch ein Passkey-Overlay anzuzeigen, wenn Passkeys verfügbar sind, was das schnellste Login-Erlebnis bietet, ohne dass eine Kennung eingegeben werden muss
• Sie benötigen volle Kontrolle über die Authentifizierungs-UI und den Flow
• Sie sind bereit, in plattformspezifische Implementierungen zu investieren (iOS Swift, Android Kotlin)

Wichtiger Vorteil: preferImmediatelyAvailableCredentials()

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

Das untenstehende Diagramm veranschaulicht, wie die native Authentifizierung einen schnelleren Nutzerpfad im Vergleich zum Conditional-UI-Ansatz des WebViews bietet:

Das automatische Overlay von Native bietet eine überlegene UX mit höheren Passkey-Nutzungsraten, da die Authentifizierung sofort beim App-Start beginnt, während WebView-Implementierungen erfordern, dass Nutzer zuerst mit Eingabefeldern interagieren.

Technische Anforderungen im Überblick:

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

1. App-Domain Association-Dateien gehostet unter /.well-known/
2. Korrekte Relying Party ID passend zu Ihrer Webdomain
3. Plattformspezifische Capabilities (detailliert in Abschnitt 4)

Der große Vorteil: Auf Ihrer Website erstellte Passkeys funktionieren nahtlos in Ihrer App und umgekehrt.

Die native Implementierung von Passkeys unter iOS umfasst das AuthenticationServices-Framework von Apple, das eine API für WebAuthn-Operationen bereitstellt:

Schlüsselkomponenten:

• ASAuthorizationController: Verwaltet den Authentifizierungs-Flow
• ASAuthorizationPlatformPublicKeyCredentialProvider: Erstellt Passkey-Anfragen
• Drei verschiedene UI-Modi zur Handhabung von Passkey-Logins:
  • Textfield-Login: Traditionelles Benutzernamenfeld mit Passkey-Login, der beim Button-Submit startet
  • Passkey-Modal-Overlay: OS-Dialog, der verfügbare Passkeys auflistet
  • Conditional UI: Passkey-Vorschläge in der QuickType-Leiste über der Tastatur

Entwickler-Tipps

• AASA Caching: Apple speichert die AASA-Datei aggressiv im Cache (bis zu 24 Stunden), was das Testen frustrierend machen kann. Lösung: Aktivieren Sie den Developer-Modus 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 Anmeldedaten enthalten, um reale Latenzen zu beobachten. Das System-Overlay könnte bei vielen gespeicherten Passkeys eine leichte Verzögerung aufweisen

Androids native Passkey-Implementierung nutzt die Credential Manager API (oder die ältere FIDO2 API für Abwärtskompatibilität):

Schlüsselkomponenten:

• CredentialManager: Zentrale API für alle Credential-Operationen
• CreatePublicKeyCredentialRequest: Für die Passkey-Registrierung
• GetCredentialRequest: Für die Passkey-Authentifizierung
• Zwei primäre UI-Modi:
  • Textfield-Login: Traditionelles Benutzernamenfeld mit Passkey-Login, der beim Button-Submit startet
  • Passkey-Modal-Overlay: OS-Dialog, der verfügbare Passkeys auflistet

Hinweis: Unter Android fehlen derzeit die iOS-Conditional-UI-Tastaturvorschläge in nativen Apps (obwohl Conditional UI in Web-Apps funktioniert)

Die native Implementierung von Passkeys bringt wichtige Herausforderungen und Lektionen mit sich: Die Integration auf Betriebssystemebene kann Probleme über verschiedene Geräte und OS-Versionen hinweg aufdecken.

1. Unser Team stieß beispielsweise auf Probleme wie das aggressive Caching der apple-app-site-association-Datei durch Apple (verwendet für die App/Web-Credential-Verknüpfung) und subtile UI-Unterschiede bei bestimmten biometrischen Prompts von Android-OEMs.
2. Bedenken Sie außerdem, dass in einigen Enterprise-Szenarien die Passkey-Synchronisierung auf verwalteten Geräten durch Richtlinien deaktiviert sein kann. In Unternehmensumgebungen, in denen die Synchronisierung von iCloud-Schlüsselbund oder Google Passwortmanager deaktiviert ist, werden Passkeys gerätegebunden und roamen nicht – ein wichtiges Szenario, das Sie einplanen sollten (z. B. sicherstellen, dass sich Nutzer noch einloggen können, wenn sie ein neues Smartphone erhalten).
3. Zusätzlich können Drittanbieter-Passwortmanager-Apps den Flow beeinflussen. Wenn ein Nutzer beispielsweise einen Passwortmanager wie 1Password als aktiven Credential-Provider festgelegt hat, fängt dieser oft die Erstellung und Speicherung von Passkeys ab und hat Vorrang vor dem nativen Credential Manager der Plattform.

Obwohl Sie Passkeys mit rohen Plattform-APIs implementieren können, beschleunigen speziell dafür entwickelte SDKs die Entwicklung erheblich, indem sie die Komplexität von WebAuthn, Edge-Cases und integrierte Telemetrie handhaben. SDKs bieten auch mockbare Schnittstellen für Unit-Tests (entscheidend, da Sie Biometrie in Simulatoren nicht testen können).

Empfehlung: Für native Implementierungen empfehlen wir die Verwendung der Corbado SDKs (iOS Swift Passkey SDK, Android Kotlin Passkey SDK), die zahlreiche Edge-Cases abdecken, die durch Produktions-Deployments entdeckt wurden, und zusätzliche Telemetrie und Testmöglichkeiten bieten.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

System-WebViews verwenden die native Browser-Komponente der Plattform, um die Authentifizierung innerhalb Ihrer App zu handhaben. Im Gegensatz zu vollständig nativen Implementierungen zeigen System-WebViews Webinhalte mit dem eigentlichen Systembrowser (Safari unter iOS, Chrome unter Android) an und behalten geteilte Cookies, gespeicherte Anmeldedaten und die bekannten Browser-Sicherheitsindikatoren bei.

Wann Sie System-WebView wählen sollten:

• Ihre App nutzt OAuth-basierten Login: System-WebView ist der empfohlene Ansatz für OAuth2/OIDC-Flows und bietet sichere Authentifizierung
• Sie möchten bestehende webbasierte Authentifizierung in mobilen Apps wiederverwenden
• Sie müssen mehrere Authentifizierungsmethoden (Passwörter, Social Login, Passkeys) unterstützen, ohne nativ neu zu bauen
• Sie möchten eine einzige Authentifizierungs-Codebasis über Web und Mobile hinweg beibehalten

Wichtige Vorteile:

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

Plattform-Komponenten:

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

Große Unternehmen wie Google und GitHub haben diesen Ansatz übernommen, um ihren mobilen Apps den Passkey-Login über WebView-Overlays auf bestehenden Web-Authentifizierungsseiten hinzuzufügen. Dies funktioniert gut, wenn vollständig native Authentifizierungs-Neubauten nicht sofort machbar sind.

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

ASWebAuthenticationSession (Empfohlen für Authentifizierung):

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

SFSafariViewController (Allgemeines Browsen):

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

Wenn Ihre App OAuth-basierten Login verwendet, ist ASWebAuthenticationSession die empfohlene Wahl, da es speziell für Authentifizierungsszenarien entwickelt wurde und die beste Balance aus Sicherheit und UX bietet.

Chrome Custom Tabs (CCT) bieten ein Chrome-basiertes Authentifizierungserlebnis innerhalb Ihrer App:

Wichtige Funktionen:

• Teilt Cookies und Anmeldedaten mit dem Chrome-Browser
• Zeigt URL und Sicherheitsindikatoren an
• Kann Toolbar-Farbe und 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.

Testen Sie Passkeys in einer Live-Demo.

Passkeys testen

Embedded-WebViews bieten volle Kontrolle über das Rendering von Webinhalten innerhalb Ihrer App und ermöglichen die direkte Manipulation von Cookies, Sitzungen und Navigation ohne URL-Leiste. Diese Kontrolle geht jedoch mit zusätzlichen technischen Anforderungen einher, um Passkey-Funktionalität zu aktivieren.

Wann Sie Embedded-WebView wählen sollten:

• Native-ähnliches Erlebnis: Ihre App bettet Authentifizierung bereits in einen angepassten WebView ein, um ein natives Erscheinungsbild (Look and Feel) aufrechtzuerhalten, und Sie möchten diese konsistente UX beibehalten
• Session/Cookie-Kontrolle erforderlich: Ihre App erfordert eine direkte Manipulation von Authentifizierungs-Tokens und Session-Status, nachdem die OAuth-Authentifizierung abgeschlossen ist
• Bestehender Authentifizierungs-Flow, bei dem die System-WebView-Authentifizierung zwar einen Auth-Code liefert, aber keine Session in eingebetteten Kontexten
• Authentifizierter Status muss über mehrere eingebettete Web-Screens hinweg aufrechterhalten werden
• Nur First-Party-Authentifizierung: Ihre App verarbeitet Authentifizierung direkt; für Passkey-Implementierungen von Drittanbietern siehe hier
• AndroidX WebKit 1.12.1+ mit Laufzeit-Feature-Erkennung
• Akzeptanz der Conditional-UI-Einschränkung beim Login (wird im Embedded-WebView nicht unterstützt), nicht relevant für die Verwaltung in den Einstellungen

Wichtiger Kontext:

Viele Apps verwenden einen hybriden Ansatz: System-WebView übernimmt die anfängliche OAuth-Authentifizierung (wo Passkeys nahtlos funktionieren), dann wird zu Embedded-WebView für den Post-Auth-Bereich gewechselt, um Passkeys in den Einstellungen zu verwalten. Herausforderungen entstehen, wenn man versucht, Passkeys direkt innerhalb von Embedded-WebViews zu verwenden.

Technische Anforderungen:

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

1. iOS: Associated-Domains-Berechtigungen, AASA-Datei-Konfiguration
2. Android: AndroidX WebKit 1.12.1+ mit WebView WebAuthn Konfiguration (Feature-Erkennung erforderlich)
3. Beide: Richtig konfigurierte Well-known Association-Dateien 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 Berechtigungs-Setup (iOS)
• Geringere Passkey-Verbreitung: Nutzer können auf mehr Reibung stoßen im Vergleich zu nativen Apps
• Conditional UI nicht unterstützt: Passkey-Autofill in Eingabefeldern funktioniert in Android Embedded-WebViews nicht
• Begrenzte Plattformunterstützung: Einige Funktionen arbeiten 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 Embedded-WebViews entscheidend. Die drei oben skizzierten Ansätze (Native Implementierung, System-WebView und Embedded-WebView) bedienen jeweils unterschiedliche Anwendungsfälle.

Unter iOS haben Sie mehrere Optionen zur Anzeige von Webinhalten in der App:

• WKWebView ist ein anpassbares WebView, das Teil des WebKit-Frameworks ist (eingeführt in iOS 8). Es gibt Ihnen viel Kontrolle über Aussehen und Verhalten der Webinhalte.
• SFSafariViewController ist ein von Apple bereitgestellter View-Controller, der als ressourcenschonender Safari-Browser innerhalb Ihrer App fungiert. Er verwendet die Safari-Engine. Unter iOS 11+ verfügt er über 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 Login-Flows vorgesehen sind. Diese nutzen unter der Haube ebenfalls Safari, konzentrieren sich jedoch auf Auth-Flows und handhaben Dinge wie geteilte Cookies und Single Sign-On (SSO) automatisch.

Unter Android sind die Hauptoptionen:

• Android WebView ist das Standard-WebView-Widget (android.webkit.WebView), im Wesentlichen ein Mini-Browser, der in Ihre Activities eingebettet werden kann. Er ist stark anpassbar, läuft aber im Prozess Ihrer App.
• Chrome Custom Tabs (CCT) ist eine Funktion, die einen Chrome-basierten Tab innerhalb Ihres App-Kontexts öffnet. Custom Tabs erscheinen als Teil Ihrer App, werden aber vom Chrome-Browser (sofern installiert) bereitgestellt, mit Funktionen wie Pre-Loading, geteilten Cookies und der bekannten URL-Leiste für das Vertrauen der Nutzer.

In den folgenden Abschnitten werden wir uns etwas eingehender mit diesen WebView-Typen für iOS und Android befassen und diskutieren, welche für Passkey-Authentifizierungs-Flows am besten geeignet sein könnten.

Abonnieren Sie unseren Passkeys Substack für aktuelle News.

Abonnieren

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

Um das unterschiedliche WebView-Verhalten in iOS zu testen, empfehlen wir die App WebView - WKWebView and UIWebView rendering.

WKWebView ist eine vielseitige WebView-Komponente für iOS. Entwickler können ein WKWebView einbetten, um Webinhalte mit hohem Maß an Kontrolle über UI und Verhalten zu rendern. WKWebView verwendet dieselbe Rendering-Engine wie Safari, ist also sehr performant und unterstützt moderne Webfunktionen. Theoretisch kann WKWebView WebAuthn (und damit Passkeys) verarbeiten, wenn es richtig konfiguriert ist, beachten Sie jedoch, dass einige erweiterte Browserfunktionen aus Sicherheitsgründen eingeschränkt sein könnten. Worauf man achten muss, ist, dass WKWebView standardmäßig keine Cookies oder Schlüsselbunddaten mit Mobile Safari teilt. Nutzer müssen sich möglicherweise neu anmelden, da ihre WebView-Sitzung von der Safari-Sitzung isoliert ist. Da der WKWebView-Inhalt von der App vollständig angepasst werden kann, sieht der Nutzer auch keine Adressleiste oder Safari-UI – was großartig fürs Branding ist, aber bedeutet, dass der Nutzer weniger Hinweise hat, um die Legitimität der Seite zu überprüfen (ein Anliegen bezüglich 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 injiziert), man muss also vorsichtig sein, WKWebView auf sichere und vertrauenswürdige Weise zu nutzen.

SFSafariViewController bietet ein In-App-Safari-Erlebnis. Wenn Sie eine URL mit dem SFSafariViewController öffnen, ist es fast so, als ob Sie sie im echten Safari-Browser öffnen, außer dass der Nutzer innerhalb der UI Ihrer App bleibt. Der Vorteil für Passkeys ist erheblich: Da es im Wesentlichen Safari ist, sind der iCloud-Schlüsselbund und gespeicherte Passkeys des Nutzers zugänglich. Beachten Sie, dass Cookies unter iOS 11+ nicht geteilt werden. Das bedeutet, wenn der Nutzer bereits einen Passkey für Ihre Website hat, kann Safari ihn finden und sogar das Conditional UI Autocomplete für einen einfachen Login anzeigen. SFSafariViewController ist weniger anpassbar (Sie können die Toolbar nicht großartig ändern), handhabt aber automatisch viele Sicherheits- und Datenschutzfunktionen. Die URL-Leiste wird zusammen mit dem Vorhängeschloss-Symbol für HTTPS angezeigt, was Nutzern das Vertrauen gibt, dass sie sich auf der richtigen Domain befinden. Generell gilt SFSafariViewController als sicherer als ein rohes WKWebView und ist einfacher zu implementieren (Apple stellt es als Drop-in zur Verfügung). Der größte Kompromiss besteht darin, dass Sie etwas Kontrolle über das Look & Feel opfern. Für einen Authentifizierungs-Flow ist das normalerweise akzeptabel. Die Priorität liegt hier bei Sicherheit und einfacher Anmeldung, was SFSafariViewController hervorragend macht, indem er den Safari-Kontext nutzt.

SFAuthenticationSession / ASWebAuthenticationSession – Diese Klassen (letzteres ist der neuere, Swift-freundliche Name) sind speziell für Login-Flows wie OAuth oder OpenID Connect entwickelt. Wenn Sie einen Nutzer über eine Webseite (vielleicht bei einem externen IdP) authentifizieren müssen, sind diese Sitzungen die empfohlene Wahl unter iOS. Sie sind SFSafariViewController sehr ähnlich, da sie unter der Haube den Safari-Browser nutzen und Cookies/Speicher mit Safari teilen. Der entscheidende Unterschied ist, dass SFAuthenticationSession den Nutzer immer darauf hinweist, dass die App sich über eine Webseite authentifizieren möchte (für das Nutzerbewusstsein) und automatisch die vorhandene Safari-Sitzung des Nutzers verwendet, falls verfügbar.

Der Vorteil ist ein nahtloses SSO-Erlebnis – wenn der Nutzer bereits beim Anbieter in Safari eingeloggt ist, kann diese Sitzung das Cookie nutzen, um einen erneuten Login zu vermeiden. Für Passkeys ist dies wichtig, da dies bedeutet, dass jeder Passkey, der in Safari/im iCloud-Schlüsselbund gespeichert ist, auch hier verwendet werden kann. Apples offizielle Richtlinie lautet, ASWebAuthenticationSession für alles zu verwenden, was wie ein Login-Flow aussieht. Die Vorteile sind verbesserter Datenschutz (Ihre App sieht nie die Anmeldedaten oder Cookies, Safari handhabt das) und integrierter SSO-Support. Der Nachteil ist, dass es auf Auth-Flows beschränkt ist (Sie würden es nicht verwenden, um einfach nur beliebige Webinhalte in Ihrer App zu rendern). Zusammenfassend lässt sich sagen: Wenn Sie sich unter iOS für einen WebView-Ansatz entscheiden, ist ASWebAuthenticationSession typischerweise die beste Wahl für die Implementierung von Passkeys, da es sicher ist, den Status mit Safari teilt und speziell für die Authentifizierung entwickelt wurde.

Sehen Sie, wie viele Menschen Passkeys tatsächlich nutzen.

Adoptionsdaten ansehen

Unter Android liegt die Entscheidung für ein WebView zwischen dem klassischen WebView und Chrome Custom Tabs:

Um das unterschiedliche WebView-Verhalten unter Android zu testen, 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. Es ist ähnlich wie WKWebView, da es Ihnen volle Kontrolle gibt: Sie können Navigation abfangen, JavaScript einfügen, die UI anpassen usw. Es läuft ebenfalls innerhalb des Prozesses Ihrer App. Die Verwendung eines WebViews für Passkeys bedeutet, dass Ihre App Ihre Web-Login-Seite lädt und diese Seite eine WebAuthn-Passkey-Zeremonie einleiten kann. Modernes Android-WebView unterstützt WebAuthn (vorausgesetzt, die WebView-Implementierung des Geräts ist über das Android System WebView oder die Chrome-Komponente auf dem neuesten Stand). Ein wichtiger Aspekt: Standardmäßig teilt ein Android-WebView keine Cookies oder gespeicherten Anmeldedaten mit dem Chrome-Browser des Nutzers. Daher könnte jeder im WebView erstellte oder verwendete Passkey Chrome nicht bekannt sein und umgekehrt. Diese Isolation kann gut für die Sicherheit sein (Ihre App kann keine Browser-Cookies lesen), könnte Nutzer aber dazu zwingen, sich erneut anzumelden, wenn sie sich bereits in Chrome authentifiziert haben. Ein weiteres Problem ist Vertrauen. Ein einfaches WebView zeigt keine URL oder SSL-Schlosssymbol an, sodass Nutzer Ihrer App vollständig vertrauen müssen, dass sie sie nicht phishen. Google hat die Verwendung von WebView für Google OAuth-Logins wegen potenzieller Phishing-Risiken sogar verboten. Hinsichtlich Performance sind WebViews in Ordnung, können aber langsamer oder speicherintensiver sein als die Nutzung des Standardbrowsers des Nutzers, besonders beim Laden von schweren Seiten.

Chrome Custom Tabs (CCT) sind ein hybrider Ansatz. Sie ermöglichen Ihrer App, eine Chrome-gerenderte Seite zu öffnen, die so aussieht, als wäre sie Teil Ihrer App. Sie können die Toolbar-Farbe 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 Anmeldedaten des Nutzers mit dem Chrome-Browser, was bedeutet, dass, wenn der Nutzer einen Passkey über Chrome (Google Passwortmanager) gespeichert hat, der Custom Tab darauf zugreifen kann. Der Nutzer wird auch die tatsächliche URL und Sicherheitsindikatoren sehen, was Vertrauen schafft. Die Performance ist oft besser – Chrome kann im Hintergrund "aufgewärmt" werden für schnelleres Laden. Und ganz wichtig, die Sicherheit ist stark: Da es sich im Wesentlichen um die Chrome-App handelt, 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 Nutzer Chrome (oder einen unterstützten Browser) installiert und auf dem neuesten Stand haben muss. Das haben die meisten Android-Nutzer, aber auf einigen Geräten in bestimmten Regionen könnte dies ein Problem sein. Insgesamt, wenn Sie sich für einen eingebetteten Web-Ansatz unter Android entscheiden, werden Chrome Custom Tabs für Passkey-Flows empfohlen, da sie eine gute Balance aus Integration und Sicherheit bieten. Tatsächlich sind sie iOS's SFSafariViewController/ASWebAuthSession in vielerlei Hinsicht analog – indem sie den Standardbrowser zur Authentifizierung nutzen.

(Exkurs: Apples WKWebView vs SFSafariViewController und Androids WebView vs CCT weisen viele Parallelen auf. Sowohl Safari VC als auch Chrome Tabs teilen den Browserstatus und bieten bessere Sicherheit, während WKWebView/Android WebView mehr Kontrolle bieten, aber den Webinhalt isolieren. Für Passkeys ist das Teilen des Status (Cookies, Credential-Stores) in der Regel wünschenswert, damit der Passkey nahtlos abgerufen und erstellt werden kann.)

Unabhängig davon, welchen Implementierungsansatz Sie wählen, müssen bestimmte technische Anforderungen erfüllt sein, um die Passkey-Funktionalität zu aktivieren. Dieser Abschnitt bietet umfassende Anleitungen zur Konfiguration von Well-known Association-Dateien, iOS Entitlements und der Android WebView-Konfiguration.

Hinweis zu verwalteten Geräten: Das Passkey-Verhalten ändert sich erheblich auf verwalteten Geräten, wo Mobile Device Management (MDM)-Richtlinien die Speicherung von Anmeldedaten kontrollieren. Für das Testen von Passkeys auf verwalteten Geräten, siehe Passkeys auf verwalteten iOS- und Android-Geräten.

Native- und Embedded-WebView-Flows erfordern Association-Dateien, um kryptografisches Vertrauen zwischen Ihrer App und der Webdomain herzustellen. System-WebView (ASWebAuthenticationSession) und Chrome Custom Tabs erfordern keine App-to-Site-Association.

Die AASA-Datei stellt die Verbindung zwischen Ihrer iOS-App und Ihrer Webdomain her, sodass Passkeys plattformübergreifend funktionieren.

Speicherort der Datei: https://yourdomain.com/.well-known/apple-app-site-association

Konfigurationsanforderungen:

• Hosting 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
• Beinhaltet die Team ID und Bundle ID Ihrer App

Beispielhafte AASA-Datei:

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

AASA Caching und Testing:

Apple speichert AASA-Dateien aggressiv (bis zu 24-48 Stunden) mittels eines CDNs im Cache, was Entwicklung und Tests frustrieren kann. So umgehen Sie das Caching während der Entwicklung:

1. Aktivieren Sie den Developer Mode 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 hindert iOS daran, Ihre AASA-Datei ordnungsgemäß zu erkennen, was die Passkey-Funktionalität unterbricht.

Validierung: Verwenden Sie Apples AASA Validator, um Ihre Konfiguration zu überprüfen.

Android nutzt Digital Asset Links, um die Beziehung zwischen Ihrer App und Website zu verifizieren.

Speicherort der Datei: https://yourdomain.com/.well-known/assetlinks.json

Konfigurationsanforderungen:

• Hosting unter /.well-known/assetlinks.json auf Ihrer Domain
• Bereitstellung über HTTPS mit gültigem Zertifikat
• Content-Type: application/json
• Beinhaltet den SHA256-Fingerabdruck Ihrer App (aus dem Signierungszertifikat)

Beispielhafte 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 Googles Digital Asset Links Generator, um Ihre Konfiguration zu erstellen und zu überprüfen.

iOS-Apps benötigen korrekte Entitlements, um auf die Passkey-Funktionalität zugreifen zu können. Die Anforderungen unterscheiden sich je nach Implementierungsansatz leicht.

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

Speicherort der Datei: Typischerweise in Ihrem Xcode-Projekt unter ios/Runner/Runner.entitlements

Die native Implementierung und Embedded-WebView erfordern die Associated Domains Capability, um Ihre App mit Ihrer Webdomain zu verknüpfen. System-WebView (ASWebAuthenticationSession) benötigt dies nicht, da es 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 auf den Reiter "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

Beispiel-Konfiguration:

<?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 funktionieren muss, benötigen Sie möglicherweise Related Origin Requests (ROR).

Android Embedded-WebViews unterstützen Passkeys durch zwei unterschiedliche Ansätze: den neueren WebKit-basierten Ansatz (Abschnitt 5.3.1) und den älteren JavaScript-Bridge-Ansatz (Abschnitt 5.3.2). System-WebView (Chrome Custom Tabs) erfordert keine Konfiguration – Anmeldedaten funktionieren automatisch.

Android bietet offizielle WebView-Passkey-Beispiele, die beide Implementierungsansätze demonstrieren.

Moderne WebKit-Integration mit nativer Passkey-Handhabung. Dieser Ansatz bietet nativen WebAuthn-Support, ohne dass benutzerdefinierter Bridge-Code erforderlich ist.

Offizielles Beispiel: Webkit WebView MainActivity

Anforderungen:

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

Implementierung:

import androidx.webkit.WebSettingsCompat
import androidx.webkit.WebViewFeature
 
// Check if Web Authentication is supported
if (WebViewFeature.isFeatureSupported(WebViewFeature.WEB_AUTHENTICATION)) {
    // Enable Web Authentication
    WebSettingsCompat.setWebAuthenticationSupport(
        webView.settings,
        WebSettingsCompat.WEB_AUTHENTICATION_SUPPORT_FOR_APP
    )
 
    // Enable JavaScript
    webView.settings.javaScriptEnabled = true
}

Wichtige Punkte:

• Keine JavaScript-Bridge erforderlich: WebAuthn funktioniert nativ im WebView
• Feature-Erkennung erforderlich: Prüfen Sie zur Laufzeit immer auf WebViewFeature.WEB_AUTHENTICATION
• Conditional UI nicht unterstützt: mediation:"conditional" (Passkey-Autofill in Eingabefeldern) funktioniert nicht in Embedded-WebViews
• Fallback-Strategie: Wenn das Feature nicht verfügbar ist, verwenden Sie stattdessen Chrome Custom Tabs

Versionshinweise:

• Verwenden Sie WebKit 1.12.1 oder neuer (1.12.0 hatte ein Problem mit der Laufzeitverfügbarkeit)
• Die Feature-Unterstützung hängt von der WebView-APK-Version des Nutzers ab – ältere APKs auf dem Gerät werden das Feature nicht exponieren

Vor AndroidX WebKit 1.12.0 existierte kein nativer WebAuthn-Support in Embedded-WebViews. Dieser ältere Ansatz verwendet eine Web-to-Native-Bridge, um Passkeys für Geräte ohne nativen WebView-WebAuthn-Support zu handhaben.

Offizielle Beispiele:

• PasskeyWebListener (Bridge Handler)
• JavaScript encode utilities

Wann Sie dies nutzen sollten: Um ältere Android-Versionen oder Geräte mit veralteten WebView-Implementierungen zu unterstützen.

Teams mussten entweder:

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

Für eine detaillierte Implementierung, siehe den Android Credential Manager WebView Integration Guide. Jedoch empfehlen wir dringend die Nutzung des nativen WebKit 1.12.1+ Ansatzes für moderne Apps.

Empfehlung: Verwenden Sie nativen WebAuthn-Support mit AndroidX WebKit 1.12.1+. Falls zur Laufzeit nicht verfügbar, greifen Sie auf Chrome Custom Tabs zurück, die hervorragenden Passkey-Support mit geteilten Anmeldedaten bieten.

Wenn Sie Passkeys in nativen Apps implementieren, müssen Sie Vertrauen zwischen Ihrer App und der/den Webdomain(s) herstellen. Dieser Abschnitt behandelt, wie man mit einzelnen Domains umgeht, mehrere verwandte Domains (ROR) handhabt und wie Sie überprüfen können, ob Ihre Well-known Association-Dateien richtig konfiguriert sind.

Für Apps, die eine einzelne Domain (z. B. kayak.com) verwenden, 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 ein WebAuthn-Feature, das es ermöglicht, dass ein einziger Satz von Passkeys über mehrere verwandte Domains (z. B. kayak.com, kayak.de, kayak.co.uk) hinweg funktioniert. ROR nutzt den /.well-known/webauthn Endpunkt auf jeder Seite, um verwandte Origins zu definieren, NICHT die AASA- oder assetlinks-Dateien.

Wichtige Punkte:

• ROR-Konfiguration: Jede Domain hostet /.well-known/webauthn mit der Liste verwandter Origins
• App-Association-Dateien (AASA/assetlinks): Werden nur genutzt, um Apps auf ihre entsprechenden Websites zu mappen
• iOS 18+ Embedded-WebView: Unterstützt ROR, wenn es richtig konfiguriert ist
• Associated Domains Entitlements: Muss alle Domains umfassen, 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
• Über richtig konfigurierte und zugängliche Well-known Dateien verfügen

Bevor Sie live gehen, verifizieren Sie, dass Ihre Well-known Dateien richtig konfiguriert und zugänglich sind. Apple und Google bieten CDN-basierte Test-URLs an, um die Verfügbarkeit der Datei zu prüfen:

Verwendung dieser Test-URLs:

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

Tücke beim Testen: Stellen Sie sicher, dass alle Domains ordnungsgemäß konfigurierte Well-known Dateien haben. Eine fehlende oder falsch konfigurierte Datei auf nur einer 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 Session-Kontrolle ab. Verwenden Sie diesen Entscheidungsbaum, um den besten Weg zu bestimmen.

Das folgende Flussdiagramm führt Sie durch die Auswahl des richtigen Implementierungsansatzes basierend auf den Anforderungen Ihrer App:

Kurzreferenz für jeden Pfad:

• OAuth-basierter Login? → System-WebView (ASWebAuthenticationSession / Chrome Custom Tabs)
• Web-Auth in nativer Shell wiederverwenden? → Embedded-WebView mit Konfiguration (WKWebView / Android WebView + WebKit 1.12.1+)
• Native-First Entwicklung? → Native Implementierung (AuthenticationServices / Credential Manager)
• Bestehende Web-Auth wiederverwenden? → System-WebView für schnelle Implementierung; ansonsten Native für optimale UX

So schneidet jeder Ansatz in wichtigen Dimensionen ab:

Erklärungen der Dimensionen:

• Passkeys erstellen: Wie einfach Nutzer über diesen Ansatz Passkeys erstellen können
• Passkeys nutzen: Das Authentifizierungserlebnis bei der Nutzung bestehender Passkeys
• Passkeys verwalten: Wie Nutzer Passkeys anzeigen, bearbeiten oder löschen
• Technische Komplexität: Entwicklungsaufwand und laufende Wartung
• OAuth-Unterstützung: Wie gut der Ansatz OAuth2/OIDC-Authentifizierungs-Flows verarbeitet
• Setup-Zeit: Typische Implementierungszeitlinie

Empfohlen: System-WebView

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

• iOS: ASWebAuthenticationSession ist speziell für OAuth-Flows entwickelt
• Android: Chrome Custom Tabs bieten nahtlose OAuth-Integration
• Vorteile: Minimaler nativer Code, automatisches Teilen der Anmeldedaten
• Implementierung: Fügen Sie WebAuthn zu Ihrer Web-Authentifizierungsseite hinzu und laden Sie diese dann via System-WebView

Beispiel: Reise-Apps wie kayak.com und kayak.de nutzen OAuth für die Authentifizierung. System-WebView erlaubt es ihnen, ihre bestehende OAuth-Infrastruktur beizubehalten, während sie Passkey-Unterstützung über ihre Web-Authentifizierungsseiten hinzufügen.

Empfohlen: Hybrider Ansatz

Verwenden Sie System-WebView für die anfängliche OAuth-Authentifizierung und wechseln Sie dann für Post-Auth-Sessions zu Embedded-WebView:

1. Anfängliche Authentifizierung: System-WebView handhabt OAuth + Passkey-Login
2. Session Management: Wechsel zu Embedded-WebView für authentifizierte Webinhalte, bei denen Cookie/Session-Kontrolle erforderlich ist
3. Technisches Setup: Konfigurieren Sie sowohl System- als auch Embedded-WebView-Anforderungen – stellen Sie bei Android sicher, dass AndroidX WebKit 1.12.1+ enthalten ist (siehe Abschnitt 5)

Wann zu verwenden: Apps, die sich via OAuth authentifizieren, danach aber authentifizierte Webinhalte anzeigen müssen, bei denen direkte Session-Manipulation notwendig ist.

Empfohlen: Native Implementierung

Wenn Sie von Grund auf neu bauen oder native Screens haben, gehen Sie komplett nativ:

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

Für neue Apps: Wir empfehlen dringend, von Tag eins an native Logins zu bauen. Dies bringt Sie in Position für eine optimale UX und vermeidet zukünftige WebView-zu-Nativ-Migrationen.

Empfohlen: Phasenweise Migration

Das folgende Diagramm zeigt den inkrementellen Migrationspfad:

Jede Phase baut auf der vorherigen auf und ermöglicht inkrementelle Verbesserungen ohne Störung bestehender Nutzer.

Siehe Abschnitt 5 für detaillierte Konfigurationsanweisungen.

Das Testen von Passkeys in nativen Apps erfordert einen strukturierten, vielschichtigen 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 Test-Kategorien:

• Kern-Journeys: Registrierung, Authentifizierung, Cross-Device-Flows, Löschung von Passkeys
• Plattform-Abdeckung: iOS (nativ), Android (nativ), Webbrowser über OS-Versionen hinweg
• Domain-Association: Überprüfen Sie, ob AASA-Dateien (iOS) und Digital Asset Links (Android) zugänglich sind
• Abbruch-Flows: Testen Sie Nutzerabbrüche bei OS-Prompts und biometrischen Screens
• Fehlerbehandlung: Backend-Ausfälle, Netzwerk-Timeouts, Credential-Mismatches
• Edge Cases: Bildschirmsperre deaktiviert, iCloud/Google Passwortmanager deaktiviert
• OAuth-Flows: Komplette OAuth + Passkey-Integration End-to-End
• Verwaltete Geräte: MDM-kontrollierte Umgebungen (siehe Testing auf verwalteten Geräten)
• Drittanbieter-Manager: Kompatibilität mit 1Password, Bitwarden, Dashlane
• Cross-Device-Authentifizierung: QR-Code-Flows und Hybrid-Transport-Testing
• Embedded-WebView-spezifisch: Falls Embedded-WebView genutzt wird, WebKit 1.12.1+ Konfiguration unter Android verifizieren
• Production Monitoring: Dashboard für Erfolgsraten, Fehler und Latenz

Für umfassende Testanleitungen einschließlich Automatisierungsstrategien, plattformspezifischer Stolpersteine und einer kompletten Pre-Flight-Checkliste, siehe unseren dedizierten Leitfaden: Testing von Passkey-Flows in nativen iOS- und Android-Apps.

Erwägen Sie, Nutzer nach einem erfolgreichen traditionellen Login (Passwort, OAuth) zur Erstellung von Passkeys aufzufordern. Dieser graduelle Konversionsansatz:

• Stört bestehende Authentifizierungs-Flows nicht
• Erlaubt graceful degradation, falls der Nutzer ablehnt
• Erhöht die Passkey-Adoption über die Zeit, ohne Änderungen zu erzwingen
• Funktioniert gut mit allen drei Implementierungsansätzen

Beispiel: Zeigen Sie nach einem OAuth-Login über System-WebView einen nativen Prompt: "Schnelleren Login mit Face ID aktivieren?" Bei Annahme wird der Passkey über die im System-WebView geladene Webseite erstellt.

Die Entscheidung, wie Passkeys implementiert werden sollen - via Native Implementierung, System-WebView oder Embedded-WebView - ist eine wichtige Designentscheidung, die Sicherheit, UX und Entwicklungskomplexität beeinflusst. Es gibt keine One-size-fits-all-Lösung.

Für OAuth-basierte Apps: System-WebView (ASWebAuthenticationSession, Chrome Custom Tabs) ist der empfohlene Ausgangspunkt. Es bietet exzellente OAuth-Unterstützung, minimalen Implementierungsaufwand und automatisches Teilen der Anmeldedaten.

Für Native-First-Apps: Gehen Sie lieber früher als später den nativen Weg. Ein nativer Passkey-Login bietet die nahtloseste UX mit exklusiven Funktionen wie preferImmediatelyAvailableCredentials, das ein automatisches Passkey-Overlay beim App-Start ermöglicht - etwas, was WebView-Implementierungen nicht bieten können. Da iOS und Android nun erstklassige Unterstützung für Passkeys bieten, zeigen reale Erfolge eine hohe Verbreitung. Das Tooling (einschließlich Open-Source SDKs und Plattform-Bibliotheken) ist ausgereift genug, um native Integration in vernünftigen Zeitrahmen realisierbar zu machen. Obwohl Sie auf Geräteverwaltungsrichtlinien, geräteübergreifendes Synchronisieren und Drittanbieter achten müssen, können diese Herausforderungen durch sorgfältiges Engineering und Testing bewältigt werden. Das Ergebnis ist ein App-Login, der Nutzer durch Einfachheit und Schnelligkeit begeistert und gleichzeitig die Sicherheit deutlich erhöht.

Für Embedded-WebView-Anforderungen: Embedded-WebView wird häufig in zwei Praxis-Szenarien verwendet. Erstens nutzen OAuth-basierte Apps oft System-WebView für den anfänglichen Login-Flow und wechseln dann zu Embedded-WebView, um Passkey-Verwaltungsoptionen in Einstellungsbildschirmen zu rendern, in denen Session-Kontrolle benötigt wird – wobei einige Apps dies vereinfachen, indem sie System-WebView für beide Flows beibehalten. Zweitens setzen Apps, die ihren Authentifizierungs-Flow bereits vor der Einführung von Passkeys in WebView-Frames eingebettet haben, dieses Muster aus Konsistenzgründen fort. Embedded-WebView mit nativer WebAuthn-Unterstützung (AndroidX WebKit 1.12.1+) erfordert Konfiguration und Setup (Berechtigungen, Entitlements, WebView-Einstellungen), benötigt aber keinen benutzerdefinierten JavaScript-Bridge-Code mehr. Beachten Sie, dass Conditional UI in Embedded-WebViews nicht unterstützt wird. Wählen Sie diesen Ansatz, wenn Sie bestehende eingebettete Authentifizierungsmuster beibehalten möchten oder wenn Sie Session/Cookie-Kontrolle für Post-Auth-Screens benötigen.

Letztendlich stellen Passkeys in nativen Apps einen großen Sprung nach vorn in puncto Benutzerkomfort und Sicherheit dar. Egal ob über Native, System-WebView oder Embedded-WebView implementiert, sie eliminieren Phishing-Risiken und Passwortverwaltungs-Belastungen für Ihre Nutzer. Reale Implementierungen wie die native Passkey-Integration in der VicRoads-App zeigen, dass Native-First-Ansätze die höchste Nutzerakzeptanz und Zufriedenheit liefern, wenn sie richtig mit Features wie automatischen Passkey-Overlays umgesetzt werden. Wenn Sie die Best Practices für benutzerfreundliche Authentifizierung befolgen und den Implementierungsansatz wählen, der zur Architektur Ihrer App passt – Native-First für neue Apps, System-WebView für OAuth-Flows oder Embedded-WebView für bestehende eingebettete Muster –, können Sie passwortlose, biometrische Logins 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 exakt in der AASA-Datei ü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 Slashes in der RP ID
• WebAuthn Origin: https://your-domain.com (nicht app://)

• iOS: Associated Domains Capability in Xcode aktiviert mit webcredentials:yourdomain.com
• Android: Digital Asset Links im AndroidManifest.xml deklariert
• Nutzer hat die Bildschirmsperre aktiviert (Biometrie oder PIN)
• Testen Sie mit Apples AASA Validator und Googles Digital Asset Links Tool
• Überprüfen Sie, ob die Runner.entitlements-Datei die korrekten Associated Domains enthält

• iOS: Nutzung von ASWebAuthenticationSession (empfohlen) oder SFSafariViewController
• Android: Nutzung von Chrome Custom Tabs (kein einfaches WebView)
• iOS: Überprüfen Sie, ob Associated Domains konfiguriert sind, falls benötigt
• Testen Sie, ob Cookies/Anmeldedaten mit dem Systembrowser geteilt werden
• Überprüfen Sie, ob die Web-Authentifizierungsseite eine korrekte WebAuthn-Implementierung hat

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

• Prüfen Sie, ob der Nutzer einen Nicht-Standard-Credential-Provider aktiv hat (1Password, Bitwarden, etc.)
• Verifizieren Sie, ob der Anbieter Passkeys unterstützt (nicht alle Passwortmanager tun dies)
• Testen Sie mit dem plattformnativen Credential Manager (iCloud-Schlüsselbund, Google Passwortmanager)

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

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

Es erscheint kein Passkey-Prompt

• Könnte bedeuten: AASA/assetlinks.json laden nicht, falscher WebView-Typ, gecachte AASA-Datei
• Versuchen Sie: Association-Dateien validieren, ?mode=developer auf iOS zum Testen nutzen, WebView-Typ verifizieren

Für detailliertes Debugging, siehe unseren Artikel zu Relying Party IDs in nativen Apps.

Eine häufige Falle: Staging-Umgebungen mit eingeschränktem Zugriff (IP-Whitelisting, nur VPN) werden fehlschlagen, da Apple- und Google-CDNs in der Lage sein müssen, Ihre Association-Dateien abzurufen.

• AASA/assetlinks-Dateien sind öffentlich zugänglich (kein IP-Whitelisting, kein VPN-Zwang)
• Verifizieren, ob das Apple-CDN Ihre Datei erreichen kann: https://app-site-association.cdn-apple.com/a/v1/your-staging-domain.com?nocache=1
• Verifizieren, ob Google Ihre Datei erreichen kann: https://digitalassetlinks.googleapis.com/v1/statements:list/?source.web.site=https://your-staging-domain.com&relation=delegate_permission/common.handle_all_urls

Staging-Subdomain mit Produktions-rpID:

Wenn Ihre Staging-Umgebung (z. B. stg.login.example.com) die Produktions-Domain als rpID nutzt (z. B. example.com), erfolgt der AASA-Lookup auf der rpID-Domain, nicht auf Ihrer Staging-Subdomain. Dies bedeutet:

• Fügen Sie Staging-App-Bundle-IDs zu Ihrer Produktions-AASA-Datei hinzu
• Seien Sie sich bewusst, dass in Staging erstellte Passkeys in den Produktions-Login-Flows erscheinen werden (potenzielle Verwirrung)

Beispiel (mehrere Umgebungen, die sich eine AASA teilen):

{
    "webcredentials": {
        "apps": [
            "TEAMID123.com.example.app",
            "TEAMID123.com.example.app.dev",
            "TEAMID123.com.example.app.stg",
            "TEAMID123.com.example.app.pre"
        ]
    }
}

Empfehlung: Nutzen Sie eine separate Staging-rpID passend zu Ihrer Staging-Domain, um Credential-Überschneidungen zwischen Umgebungen zu vermeiden. Dies erfordert öffentlich zugängliche AASA-Dateien auf der Staging-Domain.

?mode=developer Klärung:

Der ?mode=developer Parameter in Associated Domains umgeht Apples CDN-Cache, aber umgeht nicht die Zugänglichkeitsanforderung. Ihre AASA-Datei muss für das Gerät immer noch erreichbar sein (nicht über Apples CDN, sondern direkt). Dies hilft während der Entwicklung, wenn über AASA-Änderungen iteriert wird, hilft aber nicht, wenn Ihr Staging-Server durch IP-Whitelisting geschützt ist.

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

Ü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 →

Die Wahl hängt von Ihrer Authentifizierungsarchitektur ab. Wenn Ihre App OAuth2 oder OIDC nutzt, erfordert System-WebView (ASWebAuthenticationSession unter iOS oder Chrome Custom Tabs unter Android) den geringsten Implementierungsaufwand und keine Einrichtung von Association-Dateien. Für neue Native-First-Apps bietet die native Implementierung eine überlegene UX, während Embedded-WebView für Apps geeignet ist, die Authentifizierung bereits in einem WebView-Frame einbetten und nach dem Login Sitzungs- oder Cookie-Kontrolle benötigen.

SFSafariViewController nutzt die Safari-Engine, zeigt die URL-Leiste mit SSL-Indikatoren an und bietet Phishing-Schutz, was ihn für Authentifizierungsabläufe vertrauenswürdiger macht. WKWebView bietet mehr UI-Anpassung, hat aber einen isolierten, von Safari getrennten Cookie-Speicher, erfordert Associated-Domains-Berechtigungen und eine AASA-Datei, um Passkeys zu aktivieren, und zeigt die URL-Leiste nicht an, was Vertrauenssignale für Nutzer verringert.

Chrome Custom Tabs teilen Cookies und gespeicherte Anmeldedaten mit dem Chrome-Browser des Nutzers, was bedeutet, dass im Google Passwortmanager gespeicherte Passkeys während der Authentifizierung zugänglich sind. Das Standard-Android-WebView hat einen isolierten Cookie-Speicher, zeigt weder die URL noch SSL-Indikatoren an und wurde von Google wegen Phishing-Risiken ausdrücklich für Google-Konto-Anmeldungen gesperrt.

Wenn ein Nutzer einen Drittanbieter-Passwortmanager wie 1Password als aktiven Provider festgelegt hat, fängt dieser oft die Erstellung und Speicherung von Passkeys ab und hat Vorrang vor dem nativen Credential Manager der Plattform (iCloud-Schlüsselbund oder Google Passwortmanager). Dies bedeutet, dass Passkeys möglicherweise in der Drittanbieter-App statt im Plattform-Schlüsselbund gespeichert werden, was sich auf das geräteübergreifende Synchronisieren und das Passkey-Management auswirkt.

Wenn MDM-Richtlinien die Synchronisation von Anmeldedaten deaktivieren, werden Passkeys gerätegebunden und können nicht auf ein Ersatzgerät übertragen werden, anders als in typischen Verbraucherszenarien. Apps, die auf Unternehmensumgebungen abzielen, sollten Fallback-Authentifizierungsmechanismen wie Passwort- oder Magic-Link-Login planen, um Fälle zu handhaben, in denen ein Nutzer ein neues verwaltetes Gerät erhält.