Passkeys in nativen Apps: Native vs. WebView-Implementierung

Dieser Artikel erklärt, wie man Passkeys in nativen Apps (iOS + Android) implementiert. Sie erfahren, welcher WebView-Typ für die Passkey-Authentifizierung empfohlen wird.

Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.

1. Implementierungsoptionen für Passkeys in nativen Apps#

Die Authentifizierung ist der Wächter, der Benutzerdaten schützt und sichere Interaktionen in nativen Apps gewährleistet. Das Aufkommen von Passkeys hat diesen Bereich revolutioniert und bietet einen robusten und benutzerfreundlichen Authentifizierungsmechanismus. Es gibt zwei Hauptwege, Passkeys in eine native App zu integrieren: entweder über eine native Implementierung oder über eine WebView. Schauen wir uns zunächst an, wie sich die beiden Wege vergleichen.

1.1 Native Implementierung: Großartige UX#

Eine native Implementierung wird oft als die beste Benutzererfahrung innerhalb einer App angesehen. Sie zeichnet sich durch ihre reibungslosen, integrierten und kohäsiven Benutzerinteraktionen aus, die genau auf die Umgebung des Betriebssystems zugeschnitten sind, sei es iOS oder Android. Die Voraussetzung für eine 100% native Implementierung ist, 100% passwortlos zu werden und wirklich Passkey-nativ zu sein. Dieser Ansatz befreit Sie von der potenziellen Reibung des Übergangs zwischen der nativen App und Webinhalten (die über eine WebView angezeigt werden).

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

1.2 WebView-Implementierung: Browser-ähnliche Erfahrung#

Bei der Entwicklung einer nativen App ist der Weg, vollständig nativ zu gehen, nicht immer möglich. In Szenarien, in denen Sie immer noch passwortbasierte Authentifizierung mit OAuth2 unterstützen müssen, ist eine vollständige native Integration möglicherweise nicht machbar, was WebView-Implementierungen zur einzig gangbaren Alternative macht. WebView fungiert als Brücke, die Webinhalte direkt in Ihre App einbettet und eine browserähnliche UX beim Navigieren durch Webseiten bietet. Dies ist besonders relevant, wenn Sie selbst ein OAuth2-Anbieter sind, Ihre zugrunde liegende Authentifizierungslösung auf OAuth2 basiert oder wenn Ihre Anmeldelösung soziale Logins über Drittanbieter wie Google oder GitHub verwendet. In diesen Fällen wird der Einsatz einer WebView unvermeidlich, da mit Webinhalten interagiert und verschiedene Benutzerauthentifizierungsflüsse verwaltet werden müssen, insbesondere wenn native App-Assoziationen erforderlich sind.

Zusammenfassend lässt sich sagen, dass native Implementierungen zwar eine unübertroffene, reibungslose Benutzererfahrung bieten, aber nicht immer eine praktikable Option sind, insbesondere in Verbindung mit passwortbasierten oder OAuth2-basierten Authentifizierungslösungen. Andererseits bieten WebView-Implementierungen einen flexiblen, wenn auch etwas weniger nahtlosen Weg, um Webinhalte zu integrieren und die Benutzerauthentifizierung innerhalb Ihrer App zu verwalten, sodass Sie die Komplexität verschiedener Authentifizierungsflüsse und Drittanbieter-Logins bewältigen können.

Die nächsten Abschnitte dieses Artikels konzentrieren sich auf die Implementierung über WebView. Um mehr über die native Passkey-Integration zu erfahren, lesen Sie unseren Artikel über das Flutter Passkeys Package.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

Über 10.000 Entwickler vertrauen Corbado und machen das Internet mit Passkeys sicherer. Haben Sie Fragen? Wir haben über 150 Blogbeiträge zu Passkeys verfasst.

Treten Sie der Passkeys-Community bei

2. Überblick über WebView-Optionen#

Beim Navigieren durch das Labyrinth der Authentifizierung in nativen Apps stehen Entwickler und Produktmanager vor einer entscheidenden Entscheidung: die Passkey-Authentifizierung nativ oder über eine WebView zu implementieren. Wenn man sich für Letzteres entscheidet, bieten sowohl die iOS- als auch die Android-Plattformen zwei verschiedene Arten von WebViews an, jede mit ihren einzigartigen Attributen und potenziellen Anwendungsfällen.

2.1 iOS WebViews#

WKWebView
SFSafariViewController
SFAuthenticationSession / ASWebAuthenticationSession (speziell für OAuth / OpenID Connect-basierte Authentifizierungsflüsse zugeschnitten)

2.2 Android WebViews#

WebView
Chrome Custom Tabs (CCT)

In den folgenden Abschnitten gehen wir tiefer auf diese WebView-Typen ein und führen Sie letztendlich zu einer fundierten Entscheidung, welche WebView für die Passkey-Authentifizierung in Ihren nativen Apps verwendet werden sollte (wenn eine rein native Implementierung keine Alternative ist).

Subscribe to our Passkeys Substack for the latest news.

3. WebViews in iOS#

iOS WebViews sind entweder WKWebView oder SFSafariViewController (bei der Arbeit mit OAuth / OIDC ist es SFAuthenticationSession / ASWebAuthenticationSession).

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

3.1 WKWebView#

WKWebView ist eine leistungsstarke und vielseitige WebView-Option für iOS-Entwickler. Mit iOS 8 eingeführt, ermöglicht es Entwicklern, Webinhalte direkt in eine App einzubetten und bietet eine breite Palette an Anpassungs- und Konfigurationsoptionen. WKWebView ist bekannt für seine Leistung, da es dieselbe Web-Rendering-Engine wie Safari verwendet und einen reichhaltigen Satz von APIs zur Interaktion mit Webinhalten, zur Verwaltung der Navigation, der Benutzerinteraktionen und mehr bietet.

3.2 SFSafariViewController#

SFSafariViewController ist eine WebView, die es Entwicklern ermöglicht, die Funktionen von Safari direkt in ihren Apps zu nutzen. Es bietet eine nahtlose Benutzererfahrung, indem es die Safari-Einstellungen des Benutzers wie gespeicherte Passwörter, Passkeys, Cookies und mehr verwendet, was ein konsistentes Webbrowsing gewährleistet, da es tatsächlich als Safari-Anwendung läuft. SFSafariViewController ist nicht so anpassbar wie WKWebView, bietet aber erweiterte Sicherheitsfunktionen und eine einfache Handhabung, was es zu einer bevorzugten Wahl für die Anzeige von einfachen Webinhalten in Apps macht.

	WKWebView	SFSafariViewController
Benutzererfahrung	- Natives Gefühl: Benutzer könnten das Gefühl haben, dass der Webinhalt ein nativer Teil der App ist, da Entwickler das Erscheinungsbild an das Design der App anpassen können. - Autofill: Autofill mit Daten aus Safari ist möglich	- Nahtlos: Nahtlose Benutzererfahrung durch Verwendung der Safari-Einstellungen des Benutzers, was ein konsistentes Webbrowsing zwischen nativer App und Browser gewährleistet.
Entwicklererfahrung	- Sehr anpassbar: Umfangreiche Anpassungs- und Konfigurationsmöglichkeiten verfügbar - Flexibel: Viele APIs zur Interaktion mit Webinhalten	- Mittelmäßig anpassbar: Begrenzte Anpassungsoptionen, insbesondere im Vergleich zu WKWebView, - Einfach: Einfacher zu implementieren im Vergleich zu WKWebView
Leistung	- Eher langsam: Abhängig von der Implementierung und dem Webinhalt können die Ladezeiten optimiert werden, sind aber aufgrund der zusätzlichen Verarbeitung von benutzerdefinierten Funktionen und Interaktionen möglicherweise immer noch langsamer als bei SFSafariViewController.	- Eher schnell: Bietet typischerweise eine bessere Leistung, da es die Safari-Engine nutzt, die für Geschwindigkeit und Effizienz optimiert ist und schnelle Ladezeiten für Webseiten bietet.
Vertrauen und Wiedererkennung	- URL-Anzeige nicht erforderlich: WKWebView zeigt oft die URL nicht an, was es für Benutzer schwieriger macht, die Webseite zu überprüfen. Potenzial für bösartige Apps, dieses Verhalten nachzuahmen und Anmeldeinformationen zu phishen.	- Browser-ähnliche Erfahrung: Rendert Webseiten mit Safari und bietet eine „browser-ähnliche“ Erfahrung. Benutzer können die URL sehen und auf die Auto-Fill-Funktionen von Safari zugreifen, was aufgrund der vertrauten Benutzeroberfläche potenziell mehr Vertrauen schafft.
Isolation	- Getrennt: Cookies und Sitzungen sind von Safari getrennt; Benutzer werden nicht automatisch in einer WKWebView angemeldet.	- Getrennt: Cookies und Sitzungen sind von Safari getrennt; Benutzer werden auch nicht automatisch in SFSafariViewController angemeldet.
Schwachstellen	- Sicher: Aufgrund des App-Sandboxing von Apple von Natur aus sicher, aber Verhalten und Sicherheit hängen von der Implementierung der App ab. Potenzielle Schwachstellen bei nicht korrekter Implementierung.	- Sicherer: Profitiert von den integrierten Sicherheitsfunktionen von Safari, einschließlich Anti-Phishing und Warnungen vor bösartigen Websites. Gilt aufgrund dieser Funktionen und der Vertrautheit der Benutzer mit Safari allgemein als sicherer für die Anzeige von Webinhalten als WKWebView.
Sonstiges	- Funktionen nicht verfügbar: Einige Browserfunktionen (z.B. WebAuthn) sind aufgrund von Sicherheitsbedenken und der Ausführung von WKWebView im Anwendungskontext möglicherweise nicht vollständig zugänglich. - JavaScript-Injektion: Einige Apps, z.B. TikTok, injizieren Tracking-JavaScript in ihre In-App-WKWebView oder schränken die Benutzersteuerung ein (z.B. Facebook) - Datenschutzprobleme: Mehr Community-Feedback bezüglich des Datenschutzes	- Keine JavaScript-Injektion: Erlaubt nicht die Ausführung von JavaScript aus der App, was Sicherheit und Datenschutz verbessert. Unterstützt auch keine JavaScript-Warnungen oder -Bestätigungen, was die Benutzererfahrung auf bestimmten Webseiten beeinträchtigen kann. - Reader-Modus: Bietet einen Lesemodus für eine saubere, leicht lesbare Version von Artikeln.

3.3 SFAuthenticationSession / ASWebAuthenticationSession#

SFAuthenticationSession und ASWebAuthenticationSession sind WebViews, die speziell auf OAuth / OpenID Connect-basierte Authentifizierungsflüsse zugeschnitten sind. Sie bieten einen sicheren und isolierten Raum für die Benutzerauthentifizierung, schützen die Anmeldeinformationen der Benutzer und stellen sicher, dass private Informationen nicht versehentlich mit der App geteilt werden. Diese Sitzungen teilen Cookies und Website-Daten mit Safari und bieten so eine konsistente und nahtlose Benutzererfahrung, insbesondere bei Authentifizierungsprozessen.

Vorteile:

Dedizierte Authentifizierung: Speziell für OAuth / OpenID Connect-basierte Authentifizierungsflüsse entwickelt, was einen optimierten Authentifizierungsprozess gewährleistet.
Datenschutz: Gewährleistet den Datenschutz der Benutzer, indem Cookies oder Website-Daten nicht mit der App geteilt werden.
SSO-Unterstützung: Unterstützt Single Sign-On, was eine bequeme Benutzererfahrung bietet.

Nachteile:

Begrenzter Anwendungsfall : Hauptsächlich auf die Authentifizierung mit OAuth / OpenID Connect ausgerichtet, was möglicherweise nicht für alle Anwendungsfälle geeignet ist.

Wenn die Hauptaufgabe die Benutzerauthentifizierung ist, insbesondere bei der Implementierung von SSO oder der Interaktion mit OAuth-Anbietern, sollten Sie SFAuthenticationSession / ASWebAuthenticationSession anstelle von SFSafariViewController verwenden.

Want to find out how many people use passkeys?

View Adoption Data

4. WebViews in Android#

Android WebViews sind entweder WebView oder Chrome Custom Tabs (CCT). Zum Testen des unterschiedlichen WebView-Verhaltens in Android empfehlen wir die App WebView vs Chrome Custom Tabs.

4.1 Android WebView#

WebView auf Android ist eine umfassende Komponente, die es Entwicklern ermöglicht, Webinhalte als Teil der Benutzeroberfläche der App anzuzeigen. Es ist vielseitig, bietet eine breite Palette von Anpassungsoptionen und gibt Entwicklern die Flexibilität, die WebView für verschiedene Bedürfnisse zu konfigurieren. WebView bietet einen reichhaltigen Satz von APIs zur Interaktion mit Webinhalten, zur Verwaltung von Benutzerinteraktionen und sogar zur Handhabung von JavaScript-Dialogen, Client-Zertifikaten und Berechtigungsanfragen.

4.2 Chrome Custom Tabs (CCT)#

Chrome Custom Tabs (CCT) bietet eine nahtlose, sichere und effiziente Möglichkeit, Webinhalte direkt in Ihre App zu integrieren. Durch die Nutzung der Funktionen und Sicherheitsmerkmale von Chrome bietet CCT eine Benutzererfahrung, die sowohl konsistent als auch leistungsstark ist.

CCT ist eine Komponente des Chrome-Browsers, die für die Integration mit dem Android-Framework entwickelt wurde und es Apps ermöglicht, Webinhalte in einem leichtgewichtigen, dedizierten Prozess zu öffnen. Bemerkenswerterweise öffnet es sich schneller als ein herkömmlicher Browser und kann, wenn es über seinen Warm-up-Aufruf vorgeladen wird, potenziell eine WebView übertreffen. Obwohl es JavaScript ausführt, arbeitet es in seinem eigenen Prozess und schützt Apps so vor der Ausführung von bösartigem Code. Darüber hinaus bietet die Benutzeroberfläche von CCT eine Aktionsleiste, die die URL und ein SSL-Verifizierungsschloss-Symbol für sichere Seiten anzeigt, wodurch die Benutzer von der Authentizität und Sicherheit der geladenen Seite überzeugt werden.

Im Allgemeinen kann man sagen, dass iOS WKWebView und Android WebView sowie SFSafariViewController und Chrome Custom Tabs (CCT) ähnlich sind.

Merkmal	WebView	Chrome Custom Tab
Benutzererfahrung	- Flexibilität: Bietet einen reichhaltigen Satz von APIs zur Interaktion mit Webinhalten und zur Verwaltung von Benutzerinteraktionen, einschließlich der Handhabung von JavaScript-Dialogen und Berechtigungsanfragen. - Konsistenz: Die Verwaltung einer konsistenten UX, insbesondere bei unterschiedlichen Webinhalten, kann eine Herausforderung sein.	- Browser-Funktionen: Teilt Funktionen wie Datensparmodus und synchronisiertes AutoComplete über Geräte hinweg. - Zurück-Button: Ermöglicht Benutzern die einfache Rückkehr zur App mit einem integrierten Zurück-Button. - Abhängigkeit: Hängt von der Chrome-App ab, die möglicherweise nicht auf allen Benutzergeräten verfügbar oder aktualisiert ist. - Weiterleitung zum Browser: Bestimmte Funktionalitäten könnten Benutzer zur Chrome-App weiterleiten, was die Benutzererfahrung potenziell stört. - Partielle Custom Tabs: Nur ein Teil des Bildschirms kann für den Chrome Custom Tab verwendet werden, während der Rest die native App anzeigt. - Side-Sheet: Im Querformat und auf Geräten mit großem Bildschirm wird der Chrome Custom Tab nur auf einer Seite des Bildschirms angezeigt, während der Rest des Bildschirms die native App zeigt.
Entwicklererfahrung	- Sehr anpassbar: Bietet umfangreiche Anpassungsoptionen/-bedürfnisse. - Interaktivität: Bietet zahlreiche APIs zur Interaktion mit Webinhalten und zur Verwaltung von Benutzerinteraktionen.	- Anpassbar: Ermöglicht die Anpassung der Symbolleistenfarbe, des Aktionsbuttons, der unteren Symbolleiste, benutzerdefinierter Menüpunkte und Ein-/Aus-Animationen. - Callback: Liefert bei einer externen Navigation einen Callback an die Anwendung. - Sicherheitsfunktionen: Bietet sofort einsatzbereite Funktionen, wodurch die Verwaltung von Anfragen, Berechtigungserteilungen oder Cookie-Speichern entfällt.
Leistung	- Mäßige Leistung: Bietet möglicherweise nicht das gleiche Leistungsniveau wie Chrome Custom Tabs (CCT).	- Pre-Warming: Beinhaltet das Vorwärmen des Browsers im Hintergrund und das spekulative Laden von URLs, um die Seitenladezeit zu verbessern. - Priorität: Verhindert, dass Apps, die einen Custom Tab starten, während seiner Nutzung aus dem Speicher entfernt werden, indem ihre Wichtigkeit auf die „Vordergrund“-Ebene angehoben wird.
Vertrauen und Wiedererkennung	- URL & SSL nicht sichtbar: Die URL- und SSL-Informationen sind in einer WebView nicht von Natur aus sichtbar. Sofern der App-Entwickler diese Funktionen nicht implementiert, wissen die Benutzer nicht, ob sie sich auf der richtigen Website oder einer Phishing-Seite befinden.	- URL & SSL sichtbar: Verwendet den tatsächlichen Chrome-Browser zum Rendern von Seiten. Benutzer können die URL und das SSL-Zertifikat sehen (was anzeigt, ob die Verbindung sicher ist). Dies kann den Benutzern das Vertrauen geben, dass sie sich nicht auf einer Phishing-Seite befinden.
Isolation	- Läuft im Prozess der App: Wenn eine App eine Schwachstelle hat, die die Ausführung von bösartigem Code ermöglicht, besteht das Risiko, dass die WebView kompromittiert wird. WebView erhält jedoch auch Updates, aber ihr Verhalten und ihre Sicherheit können stärker von der App abhängen, die sie verwendet. - Kein Teilen von Cookies / Sitzungen: Teilt keine Cookies oder Sitzungen mit dem Hauptbrowser des Geräts, was Isolation bietet, aber möglicherweise erfordert, dass sich Benutzer erneut anmelden.	- Läuft im Prozess von Chrome: Als Teil von Chrome laufen Custom Tabs im selben Prozess und haben dieselben Sicherheitsupdates und Funktionen wie Chrome. - Geteilter Cookie-Jar und Berechtigungsmodell: Stellt sicher, dass Benutzer sich nicht erneut auf Websites anmelden oder Berechtigungen erneut erteilen müssen. - Chrome-Einstellungen & Präferenzen: Nutzt die Einstellungen und Präferenzen von Chrome.
Schwachstellen	- Callbacks zum Stehlen von Anmeldeinformationen: Potenzielle Schwachstellen beinhalten, dass manchmal JavaScript erforderlich ist, was anderen Apps die Tür öffnet, bösartigen Code auszuführen, wie z.B. das Registrieren von Callbacks, die versuchen, Benutzernamen und Passwörter abzufangen. - Phishing: Zusätzlich könnte eine bösartige App eine andere Webseite öffnen, die den Link-Flow in einem Phishing-Versuch nachahmt.	- Google Safe Browsing: Setzt Googles Safe Browsing ein, um sowohl den Benutzer als auch das Gerät vor gefährlichen Websites zu schützen. - Sichere Browser-Dekoration: Stellt sicher, dass der Benutzer immer die genaue URL sieht, mit der er interagiert, und die Zertifikatsinformationen der Website einsehen kann, was das Phishing-Risiko verringert. Darüber hinaus erlauben Custom Tabs keine JavaScript-Injektion.
Sonstiges	- Google hat WebViews für die Anmeldung von Benutzern bei Google-Konten verboten

5. Empfehlung für die Implementierung von Passkeys in nativen Apps#

Unsere Kunden fragen uns kontinuierlich, wie Passkeys in nativen Apps implementiert werden sollten. Größtenteils lassen sich diese Kunden in verschiedene Gruppen einteilen:

Gruppe A:

Kunden, die ihre native App von Grund auf neu erstellen und direkt unsere passwortlose Authentifizierung nutzen können (keine alten Passwörter vorhanden).

Gruppe B:

Kunden mit bestehenden Benutzern und einer bestehenden Authentifizierungslösung. Oft haben sie auch bereits eine Web-App, die ebenfalls Passkeys in ihren Authentifizierungsprozess integrieren muss. Hier entscheiden sich viele Unternehmen für einen zweistufigen Prozess:

Fügen Sie Passkeys zu Ihrem bestehenden WebView-Authentifizierungsfluss hinzu (so haben es Google und GitHub in ihren nativen Apps implementiert)
Fügen Sie Passkeys zusätzlich über eine native Implementierung hinzu. Diese native Passkey-Implementierung prüft vor der alten WebView (z.B. für soziale Logins und Passwörter), ob sich der Benutzer mit einem Passkey anmelden kann (so hat es KAYAK in seiner nativen App implementiert).

Bestimmen Sie Ihre Gruppe

Um Ihren Benutzern die beste Passkey-Implementierung in einer nativen App zu bieten, müssen Sie entscheiden, zu welcher Gruppe Sie gehören, basierend auf Ihrem aktuellen technischen Setup und wie Sie Passkeys vorantreiben möchten (diese Frage ist für Unternehmen der Gruppe B relevant).

Empfehlung für Gruppe A: Native Implementierung

Wenn Sie eine völlig neue App erstellen (Gruppe A), empfehlen wir, eine native Passkey-Implementierung zu wählen und sofort komplett passwortlos zu werden (also wird keine Art von WebView verwendet). Bitte verwenden Sie die nativen SDKs & APIs für iOS und Android (z.B. über das passkeys Flutter package). Bitte lesen Sie auch diesen Artikel über Relying Party IDs.

Empfehlung für Gruppe B: Zuerst WebView, dann native Implementierung

Wenn Sie Passkeys heute aus irgendeinem Grund nicht nativ implementieren können (Gruppe B), können Sie mit einer WebView-Implementierung beginnen und dann in Zukunft auch zu einer nativen Passkey-Implementierung übergehen (dies funktioniert über die Erstellung von Assoziationsdateien, wie apple-app-site-association für iOS-Apps und assetlinks.json für Android-Apps). Gründe für eine WebView-Implementierung könnten sein:

Sie bieten bereits eine OAuth2-basierte Authentifizierung an und möchten diese Ihren Benutzern weiterhin anbieten (OAuth2 funktioniert nicht nativ, siehe den Standard hier)
Sie möchten die Passkey-Authentifizierung im selben Fenster / Bildschirm anbieten, in dem Sie auch Ihre anderen Authentifizierungsmethoden anbieten (z.B. Passwörter, soziale Logins, OAuth2)

Dies ist die Art und Weise, wie Google oder GitHub die Passkey-Authentifizierung derzeit in ihren nativen Apps implementiert haben. Bitte beachten Sie die nachstehende Empfehlung zur korrekten Einrichtung von WebViews für die Passkey-Authentifizierung. Wir empfehlen jedoch, eine native Passkey-Implementierung wie KAYAK in Betracht zu ziehen und direkt mit Schritt 2 zu beginnen.

Wenn Sie zur Gruppe B gehören und Passkeys nicht nativ implementieren können, neigt unsere Empfehlung zur Verwendung von SFAuthenticationSession / ASWebAuthenticationSession für iOS und Chrome Custom Tabs für Android (andernfalls funktionieren Passkeys sowieso nicht).

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Im Folgenden nennen wir die Gründe für diese Empfehlung:

5.1 Geteilte Cookies & Daten mit dem Browser#

SFAuthenticationSession / ASWebAuthenticationSession teilen Cookies und Website-Daten mit Safari und bieten so eine nahtlose Benutzererfahrung bei Authentifizierungsprozessen. Dasselbe gilt für Chrome Custom Tabs auf Android.

Benutzer profitieren von ihren gespeicherten Passwörtern, Auto-Fill-Daten und anderen im Browser gespeicherten Informationen, was den Authentifizierungsprozess reibungsloser und schneller macht.

5.2 Erhöhte Sicherheit#

SFAuthenticationSession / ASWebAuthenticationSession auf iOS und Chrome Custom Tabs auf Android bieten einen sicheren und isolierten Raum für die Benutzerauthentifizierung und stellen sicher, dass sensible Benutzeranmeldeinformationen geschützt und nicht versehentlich mit der App oder anderen Websites geteilt werden.

Sie halten sich an die strengen Sicherheitsprotokolle von Apple und Google und gewährleisten, dass Benutzerdaten sicher gehandhabt und die Privatsphäre gewahrt wird.

Darüber hinaus profitiert diese Designentscheidung von den laufenden Sicherheitsupdates und -verbesserungen von Safari und Chrome, wodurch sichergestellt wird, dass sie den neuesten Sicherheitsstandards und -protokollen entspricht.

5.3 Benutzererfahrung#

SFAuthenticationSession / ASWebAuthenticationSession auf iOS und Chrome Custom Tabs auf Android bieten eine konsistente und vertraute Benutzeroberfläche, da die Benutzer an die Benutzererfahrung des Browsers gewöhnt sind. Außerdem werden die Benutzereinstellungen und Präferenzen von Safari und Chrome angewendet.

Es bietet einen reibungslosen Übergang zwischen App-Inhalten und Webinhalten und stellt sicher, dass die Benutzer nicht durch den Wechsel zwischen den Oberflächen irritiert werden.

5.4 Leistung#

Chrome Custom Tabs nutzen die Leistung von Chrome und gewährleisten eine reibungslose und reaktionsschnelle Benutzererfahrung, was besonders bei Authentifizierungsprozessen entscheidend ist, um Benutzerfrustration oder -abbruch zu vermeiden.

Die Leistung von CCT ist oft besser als die von Android WebView-Optionen (dasselbe gilt für SFAuthenticationSession / ASWebAuthenticationSession auf iOS), was sicherstellt, dass Webinhalte und Authentifizierungsflüsse schnell und reibungslos abgewickelt werden.

Sehen Sie sich auch diesen Vergleich von Google an, um die Leistungsunterschiede zwischenChrome Custom Tabs , Android WebView und dem Standard-Chrome-Browser zu spüren.

5.5 Speziell für Authentifizierungsflüsse#

SFAuthenticationSession / ASWebAuthenticationSession ist speziell für die Handhabung von OAuth / OpenID Connect-basierten Authentifizierungsflüssen konzipiert und gewährleistet einen optimierten und sicheren Prozess für diese weit verbreiteten Authentifizierungsprotokolle. Es ist auch der empfohlene Weg für die WebAuthn / Passkey-Authentifizierung.

Auf Android gibt es keine dedizierte Klasse für Authentifizierungsflüsse, aber ein ähnliches Verhalten kann mit Chrome Custom Tabs und Android App Links implementiert werden.

Darüber hinaus erwarten wir, dass mehr Apps Passkeys wie TikTok einführen, indem sie diese einfach sammeln, wenn der Benutzer authentifiziert ist. Dies kann nativ (TikToks Implementierung) oder über eine WebView-Implementierung erfolgen. Ein geeigneter Ansatz ist es, Conditional UI nativ auszulösen. Wenn das nicht funktioniert, zeigen Sie die WebView-Implementierung an.

6. Fazit#

In der modernen Landschaft der digitalen Authentifizierung erweist sich die Implementierung von Passkeys über WebView in nativen Apps als ein Leuchtfeuer für sichere und benutzerfreundliche Praktiken. Auch wenn der Weg zur Wahl der optimalen WebView kompliziert sein mag, ist es entscheidend, technologische Entscheidungen mit Benutzererfahrung und Sicherheit in Einklang zu bringen.