Passkeys & iframes: Wie man einen Passkey erstellt und sich damit anmeldet

Legende
✅ = unterstützt ❌ = nicht unterstützt

Woche für Woche kündigen immer mehr Unternehmen die Einführung von Passkeys an (wie kürzlich Visa, Mastercard oder Vercel). Da Entwickler und Produktmanager anderer Firmen diesen Vorbildern folgen, werden immer mehr Anwendungsfälle für die Implementierung von Passkeys diskutiert.

Eine Frage, die uns immer wieder gestellt wird, ist, wie Passkeys in iframes funktionieren, da iframes in der modernen Webentwicklung weit verbreitet sind, um Inhalte aus verschiedenen Quellen nahtlos einzubetten. Im Kontext von Passkeys und WebAuthn bringen iframes ihre eigenen Herausforderungen mit sich, insbesondere in Bezug auf Sicherheit und Nutzerinteraktionen.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Dieser Blogbeitrag bietet einen umfassenden Guide zur Verwendung von Passkeys und WebAuthn in iframes. Wir werden:

• die aktuellen Möglichkeiten erkunden
• die Unterstützung von Cross-Origin-iframes diskutieren
• die Vorteile der iframe-Integration hervorheben und
• eine schrittweise Anleitung zur Implementierung bereitstellen

Am Ende dieses Beitrags werden Sie ein klares Verständnis dafür haben, wie Sie Passkeys in iframes nutzen können.

iframes, oder Inline-Frames, sind HTML-Elemente, die es Entwicklern ermöglichen, ein anderes HTML-Dokument in das aktuelle Dokument einzubetten. Diese Fähigkeit wird häufig genutzt, um Inhalte aus externen Quellen wie Videos, Karten und anderen Webseiten in eine Website zu integrieren.

Werfen wir einen Blick auf die verschiedenen Arten von iframes.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Der einfache iframe ist der am häufigsten verwendete Typ. Er bettet einfach Inhalte von einer anderen URL in die aktuelle Seite ein.

<iframe src="https://example.com"></iframe>

Dieser einfache iframe wird oft verwendet, um statische Inhalte, wie einen Artikel, in eine Webseite einzubinden.

Responsive iframes sind so konzipiert, dass sie ihre Größe an die Bildschirmgröße oder den Container anpassen, in dem sie platziert sind. Dies stellt sicher, dass der eingebettete Inhalt auf allen Geräten gut aussieht, einschließlich Desktops, Tablets und Mobiltelefonen.

<iframe src="https://example.com" style="width: 100%; height: 500px;"></iframe>

CSS Media Queries können ebenfalls verwendet werden, um den iframe dynamisch an die Größe des Viewports anzupassen.

Get a free passkey assessment in 15 minutes.

Book free consultation

Ein sicherer oder Sandboxed-iframe schränkt die Aktionen ein, die innerhalb des iframes ausgeführt werden können. Dies ist nützlich, um Inhalte aus nicht vertrauenswürdigen Quellen einzubetten oder die Sicherheit zu erhöhen.

<iframe src="https://example.com" sandbox></iframe>

Das sandbox-Attribut kann verschiedene Einschränkungen enthalten, wie zum Beispiel:

<iframe src="https://example.com" sandbox="allow-scripts allow-same-origin"></iframe>

Das sandbox-Attribut erlaubt die Ausführung von Skripten, schränkt aber potenziell gefährliche Aktionen wie Formularübermittlungen oder die Verwendung von Plugins ein.

Become part of our Passkeys Community for updates & support.

Join

Cross-Origin-iframes betten Inhalte von einer anderen Domain ein. Sie werden häufig zur Integration von Drittanbieterdiensten wie Zahlungs-Gateways oder Social-Media-Widgets verwendet. Aufgrund von Sicherheitsbeschränkungen haben diese iframes nur begrenzten Zugriff auf den Inhalt der einbettenden Seite und umgekehrt.

Cross-Origin bedeutet, dass der geladene Inhalt von einem anderen Ursprung (Origin) stammt, wobei ein Origin durch die Kombination aus Schema (Protokoll), Host (Domain) und Portnummer definiert ist. Zum Beispiel werden https://example.com und http://example.com als unterschiedliche Origins betrachtet, da sie unterschiedliche Schemata (HTTP vs. HTTPS) verwenden.

Ebenso werden Subdomains als separate Origins von ihren übergeordneten Domains behandelt. Zum Beispiel sind https://example.com und https://sub.example.com Cross-Origin, obwohl sie dieselbe Basisdomain teilen. Diese Trennung stellt sicher, dass Skripte und Daten von einer Subdomain nicht ohne explizite Erlaubnis direkt mit denen einer anderen interagieren können, was die Sicherheit erhöht.

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.

Enterprises trust Corbado to protect their users and make logins more seamless with passkeys. Get your free passkey consultation now.

Get free consultation

Hier sind Beispiele, um die Konzepte von Cross-Origin und Same-Origin zu veranschaulichen:

Cross-Origin-Beispiel:

Einbetten von Inhalten von https://payment.example.com in eine Webseite, die auf https://www.mystore.com gehostet wird. Diese sind Cross-Origin, da sie unterschiedliche Domains haben.

Same-Origin-Beispiel:

Einbetten von Inhalten von https://www.example.com/shop in eine Webseite, die auf https://www.example.com/blog gehostet wird. Diese sind Same-Origin, da sie dasselbe Schema, denselben Host und denselben Port teilen.

Cross-Origin-iframes unterscheiden sich von einfachen iframes dadurch, dass die Quelle von einer anderen Domain stammt, während ein Same-Site-iframe seine Quelle von derselben Domain hat, auf der er eingebettet ist.

<iframe src="https://anotherdomain.com"></iframe>

Die Verwendung von Passkeys in iframes bringt neue Möglichkeiten und Einschränkungen mit sich, die Entwickler verstehen müssen. Diese drehen sich hauptsächlich um das Setzen der richtigen Berechtigungen und die Gewährleistung sicherer Nutzerinteraktionen im eingebetteten Kontext.

Früher war die Web Authentication API in Cross-Origin-iframes standardmäßig deaktiviert, hauptsächlich aus Sicherheitsgründen. Diese Einschränkung bedeutete, dass Entwickler Nutzer umleiten oder Pop-up-Fenster für die Authentifizierung verwenden mussten, was zu einer weniger nahtlosen User Experience führte.

Bei Passkeys / WebAuthn gibt es zwei Kernoperationen (auch Zeremonien genannt):

1. Registrieren / einen Passkey erstellen
2. Authentifizieren / mit einem Passkey anmelden

Die beiden Operationen wurden und werden in Cross-Origin-iframes nicht gleichermaßen unterstützt:

Zuerst wurde der Login über Cross-Origin-iframes ermöglicht, die Erstellung jedoch noch nicht, da es niemanden mit einem Anwendungsfall dafür gab.

Jüngste Fortschritte (z. B. in Chrome 123) haben unter bestimmten Bedingungen die Unterstützung für die Erstellung von Passkeys in Cross-Origin-iframes eingeführt. Stand Mai 2024 unterstützen jedoch nicht alle Browser die Erstellung von Passkeys über Cross-Origin-iframes vollständig, obwohl der Login mit den meisten Browsern möglich ist.

Darüber hinaus ist die Unterstützung für Cross-Origin-iframes (für Registrierungs- und Authentifizierungsoperationen) bereits in die laufende WebAuthn Level 3-Spezifikation integriert. Einige Browser müssen die Spezifikation noch einholen (z. B. Safari). Leider hat Apple noch nicht angekündigt, ob und wann es die Cross-Origin-Registrierung von Passkeys in Safari ermöglichen wird. Dies würde die bedeutendste technische Einschränkung für die Verwendung von Passkeys in Cross-Origin-iframes aufheben.

In den folgenden Teilen des Blogbeitrags gehen wir von der Verwendung von Cross-Origin-iframes aus.

Want to find out how many people use passkeys?

View Adoption Data

Die folgenden Tabellen geben einen Überblick über die Browser-/Standard-Unterstützung für die iframe-Authentifizierung und den iframe-Login per Passkey in Cross-Origin-iframe-Kontexten:

Stand Mai 2024 ist die Erstellung eines Passkeys in einem Cross-Origin-iframe noch nicht in allen Browsern möglich. Die folgende Tabelle gibt einen Überblick über die Browser-/Standard-Unterstützung für die Registrierung/Erstellung von Passkeys in Cross-Origin-iframes:

Wenn Sie an weiteren Hintergründen zu dieser Entwicklung und Unterstützung interessiert sind, empfehlen wir einen Blick auf dieses GitHub-Issue und diesen Pull Request.

Es gibt zwei Hauptanwendungsfälle für die Unterstützung von Passkeys in Cross-Origin-iframes.

Die Aktivierung von Passkeys in Cross-Origin-iframes ist entscheidend für föderierte Identitätsszenarien, bei denen mehrere Domains beteiligt sind, aber dieselben Benutzerkonten verwendet werden sollen.

Nehmen wir folgendes Szenario: Sie sind ein multinationales Unternehmen wie KAYAK und haben verschiedene Domains für verschiedene Regionen:

• www.kayak.com
• www.kayak.us
• www.kayak.de

Sie haben jedoch ein zentrales Identitätsmanagementsystem, das es den Nutzern ermöglicht, sich mit demselben Konto und denselben Anmeldedaten auf all diesen Domains anzumelden. Der WebAuthn-Standard würde für diese Szenarien eine Herausforderung darstellen, da die Passkeys nur an eine Domain (Relying Party ID) gebunden werden können, z. B. www.kayak.com.

Um diese Herausforderung zu meistern, würden Sie auf all Ihren anderen Domains einen iframe vom Ursprung www.kayak.com verwenden. Sie betten also einen iframe mit dem Ursprung www.kayak.com auf www.kayak.us und auf www.kayak.de ein (Cross-Origin-iframe). Andernfalls wäre die Verwendung Ihrer an „www.kayak.com“ gebundenen Passkeys auf diesen anderen Domains aufgrund der Phishing-Resistenz von Passkeys nicht möglich.

Nebenbei bemerkt: Auch die neue WebAuthn-Funktion der Related Origin Requests (RoR) könnte alternativ verwendet werden. Diese Funktion ermöglicht „verwandten Origins“ den Zugriff auf Passkeys ohne iframes, wird aber noch nicht von allen Browsern unterstützt.

Auch für nahtlose Zahlungsabläufe spielt die Verwendung von Passkeys in Cross-Origin-iframes eine wichtige Rolle. Betrachten wir folgendes Szenario: Ein Kunde möchte auf der Website eines Händlers (z. B. www.amazon.com) neue Schuhe kaufen. Die Website dieses Händlers ermöglicht es dem Kunden, über sein Bankkonto (z. B. bei www.revolut.com) zu bezahlen und erfordert daher, dass sich der Nutzer auf der Website der Bank anmeldet (dies ist ein vereinfachter Prozess). Der Nutzer meldet sich auf der Website der Bank mit einem Passkey an, der an die Relying Party ID der Bank gebunden ist, z. B. „revolut.com“.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Um zu vermeiden, dass der Nutzer während des Bezahlvorgangs von der Website des Händlers (www.amazon.com) auf die Website der Bank (www.revolut.com) umgeleitet wird, um sich dort in sein Bankkonto einzuloggen, kann ein Cross-Origin-iframe verwendet werden. Hierbei bleibt der Nutzer auf www.amazon.com und verwendet den Passkey im Cross-Origin-iframe zur Authentifizierung, den er für www.revolut.com erstellt hat.

Somit gewährleistet die Integration von Passkeys über Cross-Origin-iframes in Zahlungsabläufe sichere und optimierte Transaktionen zwischen Verbrauchern, Händlern und Banken:

Im Kontext von Zahlungen und Passkeys empfehlen wir auch einen Blick auf unseren Blogbeitrag über Secure Payment Confirmation (SPC) und dynamische Verknüpfung mit Passkeys. Beachten Sie auch die unten genannten Einschränkungen für den Third-Party-Kontext in nativen Apps.

Für eine detailliertere Ansicht von Cross-Origin-Zahlungsabläufen mit Passkeys, siehe unseren Beitrag Payment Provider Passkeys: How to Build a 3rd Party SDK.

Generell bietet die Integration von Passkeys in iframes mehrere Vorteile, hauptsächlich durch die Verbesserung der UX und der Sicherheit. Hier ist eine Aufschlüsselung dieser Vorteile:

Verbesserte User Experience

1. Keine Pop-ups oder Weiterleitungen: Nutzer können sich direkt in eingebetteten Inhalten authentifizieren, ohne Weiterleitungen oder Pop-ups, was zu einer reibungsloseren und weniger störenden Erfahrung führt.
2. Einheitliche UX über verschiedene Websites hinweg: Das Einbetten von Authentifizierungsabläufen in iframes gewährleistet eine konsistente User Experience über verschiedene Bereiche einer Website oder über verschiedene Websites hinweg, die denselben Authentifizierungsdienst nutzen.

Verbesserte Sicherheit

1. Sichere Transaktionen: In Szenarien wie Zahlungen erhöhen Passkeys in iframes die Sicherheit von Transaktionen, indem sie sicherstellen, dass die Authentifizierung in einem sicheren, eingebetteten Kontext stattfindet.
2. Nutzung eines Benutzerkontos auf verschiedenen Websites: In föderierten Identitäts-Setups ermöglichen Passkeys in Cross-Origin-iframes eine sichere und effiziente Identitätsprüfung über mehrere Domains hinweg.

Die Implementierung von Passkeys in iframes umfasst einige wichtige Schritte, um Sicherheit und Funktionalität zu gewährleisten. Wir bieten eine detaillierte Anleitung für Entwickler. Bitte sehen Sie sich auch die Beispielimplementierung unter https://cross-origin-iframe.vercel.app/ an.

Der HTTP-Header Permissions-Policy hilft dabei, die Verwendung bestimmter Browser-Funktionen in einem Dokument oder innerhalb eines iframe-Elements zu erlauben oder zu verbieten. Um Passkey-Logins in einem iframe zu ermöglichen, müssen Sie die Berechtigungsrichtlinien publickey-credentials-get und publickey-credentials-create festlegen. Die Richtlinien erlauben dem eingebetteten Inhalt, die notwendige WebAuthn-API-Methode aufzurufen, um sich mit einem Passkey zu authentifizieren (navigator.credentials.get({publicKey})) und einen Passkey zu erstellen (navigator.credentials.create({publicKey})).

<iframe src="https://passkeys.eu" allow="publickey-credentials-get; publickey-credentials-create"></iframe>

Die HTTP Permissions Policy hieß früher Feature Policy. Unter Feature Policy konnte man einer Cross-Origin-iframe eine Funktion gewähren, indem man entweder den Ursprung zur Header-Ursprungsliste hinzufügte oder ein allow-Attribut im iframe-Tag einfügte. Mit Permissions Policy erfordert das Hinzufügen eines Cross-Origin-Frames zur Ursprungsliste, dass das iframe-Tag für diesen Ursprung das allow-Attribut enthalten muss. Wenn die Antwort keinen Permissions Policy-Header enthält, wird die Ursprungsliste standardmäßig auf * (alle Ursprünge) gesetzt. Das Einfügen des allow-Attributs in den iframe gewährt den Zugriff auf die Funktion.

Um sicherzustellen, dass Cross-Origin-iframes, die nicht in der Ursprungsliste angegeben sind, vom Zugriff auf die Funktion blockiert werden, selbst wenn das allow-Attribut vorhanden ist, können Entwickler den Permissions Policy-Header explizit in der Antwort setzen.

In Chrome 88+ kann Feature Policy immer noch verwendet werden, fungiert aber als Alias für Permissions Policy. Abgesehen von Syntaxunterschieden bleibt die Logik dieselbe. Wenn sowohl Permissions Policy- als auch Feature Policy-Header gleichzeitig verwendet werden, hat der Permissions Policy-Header Vorrang und überschreibt den vom Feature Policy-Header gesetzten Wert. Bitte sehen Sie sich auch diesen Blogbeitrag des Chrome-Teams für weitere Implementierungsdetails an.

Stellen Sie sicher, dass die HTTP-Antwort-Header von der Quell-URL des iframes die relevante ´Permissions-Policy` enthalten. Dies ist entscheidend für die Cross-Origin-Unterstützung.

Permissions-Policy: publickey-credentials-get=*, publickey-credentials-create=*

Für eine granularere Kontrolle können Sie bestimmte Ursprünge angeben, die den iframe-Inhalt einbetten dürfen.

Permissions-Policy: publickey-credentials-get=("https://passkeys.eu"), publickey-credentials-create=("https://passkeys.eu")

Stellen Sie sicher, dass der iframe-Inhalt eine Nutzeraktion erfordert, um die Passkey-Authentifizierung auszulösen. Dies kann durch Event-Listener für Klicks oder Formularübermittlungen innerhalb des iframes erfolgen. Dieser Prozess wird auch als transiente Aktivierung bezeichnet.

document.getElementById('loginPasskeyButton').addEventListener('click',
    async () => {
        try {
            const [publicKeyCredentialRequestOptions](/glossary/publickeycredentialrequestoptions) = { /* Configuration options */ };
 
            const credential = await navigator.credentials.get({publicKey: publicKeyCredentialRequestOptions});
            // Handle the created credential
        } catch (err) {
            console.error('Error authenticating via passkey:', err);
        }
    });

In diesem Zusammenhang siehe auch unseren Blogbeitrag zu den Anforderungen an Nutzergesten in Safari.

Im Folgenden finden Sie ein vollständiges Code-Beispiel einer index.html-Datei, die auf https://cross-origin-iframe.vercel.com gehostet wird und einen Cross-Origin-iframe für Passkeys über https://passkeys.eu verwendet.

<!doctype html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <meta
            http-equiv="Permissions-Policy"
            content="publickey-credentials-get=*; publickey-credentials-create=*"
        />
        <meta
            http-equiv="Content-Security-Policy"
            content="default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self'; img-src 'self'; frame-src https://passkeys.eu;"
        />
 
        <title>Cross-Origin iframe with Passkeys Demo</title>
        <style>
            body {
                font-family: Arial, sans-serif;
                padding: 20px;
                display: flex;
                flex-direction: column;
                justify-content: center;
                align-items: center;
                height: 100vh;
                margin: 0;
            }
 
            h1 {
                width: 100%;
                text-align: center;
            }
 
            .iframe-container {
                width: 80%;
                max-width: 800px;
                height: 80%;
                max-height: 600px;
                border: 1px solid #ccc;
                box-shadow: 0 0 10px rgba(0, 0, 0, 0.1);
                margin-top: 20px;
            }
 
            iframe {
                width: 100%;
                height: 100%;
                border: none;
            }
 
            @media (max-width: 768px) {
                h1 {
                    width: 95%;
                }
 
                .iframe-container {
                    width: 95%;
                }
            }
        </style>
    </head>
    <body>
        <h1>Cross-Origin iframe with Passkeys Demo</h1>
 
        <div class="iframe-container">
            <iframe
                src="https://passkeys.eu"
                allow="publickey-credentials-create; publickey-credentials-get"
            ></iframe>
        </div>
    </body>
</html>

Die Implementierung von Passkeys in iframes kann eine Reihe von Herausforderungen mit sich bringen, die Entwickler bewältigen müssen, um eine reibungslose und sichere User Experience zu gewährleisten. Hier ist ein detaillierter Blick auf häufige Herausforderungen und wie man sie überwindet.

Problem: Falsch konfigurierte Berechtigungsrichtlinien können den iframe daran hindern, auf WebAuthn-APIs zuzugreifen.

„NotAllowedError - The 'publickey-credentials-create' feature is not enabled in this document. Permissions Policy may be used to delegate Web Authentication capabilities to cross-origin child frames.“

Wenn Sie die Berechtigungsrichtlinien nicht korrekt hinzufügen, würde der Browser den folgenden Fehler ausgeben:

Lösung:

• Überprüfen Sie, ob das Allow-Attribut und die HTTP-Header gesetzt sind: Stellen Sie sicher, dass das allow-Attribut und die HTTP-Header korrekt gesetzt sind. Überprüfen Sie doppelt, dass die Berechtigungen publickey-credentials-get und publickey-credentials-create sowohl im iframe-Element als auch in den HTTP-Antwort-Headern des Servers enthalten sind.
• Meta-Header anstelle von Webserver-Headern: Verwenden Sie <meta/>-Header zur Definition der Berechtigungsrichtlinien anstelle der Header-Einstellung in Ihrem Webserver.
• Semikolon statt Komma in Permissions-Policy: Früher hieß Permissions-Policy Feature-Policy. Einzelne Elemente einer Feature-Policy wurden durch ein Komma anstelle eines Semikolons getrennt (was der Standard für Permissions-Policy ist). Die iframe Permissions-Policy folgt immer noch der Syntax von Feature-Policy und verwendet daher Kommas. Die sandbox / allow-Attribute werden jedoch weiterhin mit einem Semikolon getrennt (siehe Code-Snippet oben).

Tipp: Um richtig zu testen, ob Ihre Permission-Policy-Header korrekt gesetzt sind, empfehlen wir, die Entwicklertools Ihres Browsers zu öffnen, auf Application (hier: in den Chrome-Entwicklertools) zuzugreifen, zu Frames zu gehen und nach dem Ursprung des iframes zu suchen (hier: passkeys.eu/). Wenn die Permissions-Policy korrekt gesetzt ist, sollten publickey-credential-create und publickey-credential-get unter den Allowed Features aufgeführt sein:

Problem: Die Erstellung oder der Login mit einem Passkey im Cross-Origin-iframe funktioniert nicht, und Sie sehen den folgenden Fehler in Ihrer Browser-Konsole.

"NotAllowedError - The origin of the document is not the same as its ancestors."

Dieser Fehler tritt auf, wenn Sie den Safari-Browser verwenden und versuchen, einen Passkey aus dem iframe heraus zu erstellen, da Safari die Erstellung von Passkeys in Cross-Origin-iframes nicht unterstützt (siehe oben).

Lösung: Hier können Sie nicht wirklich etwas tun, da Safari die Erstellung eines Passkeys aus einem Cross-Origin-iframe (noch) nicht unterstützt.

Blocked a frame with origin "https://passkeys.eu" from accessing a frame with origin "https://cross-origin-iframe.vercel.app". Protocols, domains, and ports must match.

Dieser Fehler steht nicht direkt im Zusammenhang mit Passkeys, sondern eher mit Cross-Origin-iframes in Safari im Allgemeinen. Als Teil von Safaris / WebKits Initiative zur Blockierung von Drittanbieter-Cookies oder dem Zugriff auf LocalStorage in einem Drittanbieter-Kontext könnten Teile der JavaScript-Logik nicht mehr funktionieren.

Lösung: Hier müssen Sie sicherstellen, dass Sie keine Drittanbieter-Cookies in Ihren iframes verwenden, da dies einen Fehler verursacht.

Problem: Probleme mit der Browser-Kompatibilität von iframes treten auf, wenn verschiedene Browser unterschiedliche Unterstützungsniveaus für WebAuthn, iframe-Berechtigungen und Sicherheitsattribute haben, was zu inkonsistentem Verhalten führt.

Lösung: Um diese Probleme mit der Browser-Kompatibilität von iframes zu mindern, testen Sie die Implementierung über mehrere Browser hinweg, um die Kompatibilität sicherzustellen und browserspezifische Probleme zu identifizieren.

Schritte:

1. Führen Sie Cross-Browser-Tests mit Tools wie BrowserStack oder Sauce Labs durch.
2. Beheben Sie alle Diskrepanzen durch die Implementierung von browserspezifischen Korrekturen oder Fallbacks.

Problem: Bei der Verwendung von iframes, die Passkeys in nativen Apps erfordern, muss eine entscheidende Unterscheidung zwischen First-Party- und Third-Party-Kontexten gemacht werden:

• First-Party-Kontext: Die Passkeys sind an dieselbe Domain gebunden wie das Unternehmen, das die App betreibt. Zum Beispiel eine E-Commerce-App, die für die Benutzerauthentifizierung auf ihre eigene Domain angewiesen ist.
• Third-Party-Kontext: Eine andere Domain (z. B. ein Zahlungsanbieter oder Identitätsanbieter) übernimmt den Passkey-Erstellungs- oder Anmelde-Flow.

In einer eingebetteten WebView (EWV) wie WKWebView unter iOS oder einer Android WebView hat die aufrufende App weitreichende Kontrolle über die Web-Sitzung (z. B. das Abfangen von Anfragen). Dieses Setup unterstützt Passkeys typischerweise nur, wenn die Domain des Passkeys (die Relying Party ID) mit der Domain der App übereinstimmt (First-Party). In einem Third-Party-Szenario – wie dem Cross-Origin-Flow eines Zahlungsanbieters – kann eine eingebettete WebView jedoch im Allgemeinen nicht auf die benötigten Passkey-Anmeldedaten zugreifen, da die App des Händlers und der Dienst des Zahlungsanbieters unterschiedliche Ursprünge haben. Die erforderlichen „Bindungen“ für Passkeys (zwischen Domain, Anmeldedaten und Ursprung) stimmen im eingebetteten Kontext nicht überein.

Diese Einschränkung führt dazu, dass viele Apps einen System-WebView-Ansatz verfolgen (z. B. ASWebAuthenticationSession unter iOS oder Custom Tabs unter Android). System-WebViews isolieren die Drittanbieter-Website (z. B. den Zahlungsanbieter) in einer sicheren, browserähnlichen Umgebung, die Cross-Origin-Passkeys korrekt zulässt – sofern der Browser selbst dies unterstützt. Denken Sie jedoch daran, dass Safaris bestehende iframe-Einschränkungen auch für ASWebAuthenticationSession gelten. Wenn Safari also bestimmte Passkey-Operationen in Drittanbieter-iframes nicht zulässt, gilt dasselbe auch in der System-WebView. Es gibt derzeit keine „native“ Lösung; die beste Vorgehensweise für komplexe Flows – wie Checkouts mit externen Zahlungsanbietern – besteht darin, eine System-WebView anstelle einer eingebetteten zu öffnen.

Lösung: Für Zahlungsanbieter (und andere Drittanbieter, die auf Passkeys über Domains hinweg angewiesen sind), planen Sie die Integration sorgfältig, um sicherzustellen, dass der Nutzer aus einer eingebetteten WebView in eine System-WebView geleitet wird. Obwohl dies eine weniger nahtlose Erfahrung als ein rein eingebetteter Flow ist, ist es oft der einzige Weg, um zu garantieren, dass die Passkey-Funktionalität mit Drittanbieterdiensten funktioniert.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Weitere Details zum Umgang mit Drittanbieter-Passkeys in nativen Apps und WebViews finden Sie unter Payment Provider Passkeys: Third-Party Passkeys Payment SDK.

Obwohl die oben diskutierten Themen auf verschiedene Szenarien zutreffen, sind sie besonders wichtig für Zahlungsanbieter, bei denen Multi-Domain-Flows (z. B. Händlerseite und Zahlungs-Gateway) die Benutzerauthentifizierung in Cross-Origin-iframes einbetten müssen. In diesen Setups:

• Nutzer wünschen sich einen reibungslosen Checkout auf der Seite ohne Weiterleitungs-Pop-ups.
• Zahlungsanbieter müssen die Passkey-Registrierung oder den Login auf ihrer eigenen Domain (z. B. pay.provider.com) abwickeln, auch wenn sie in die Website eines Händlers eingebettet sind.
• Safari-Einschränkungen und eingebettete WebView-Limitierungen blockieren oft die Erstellung von Drittanbieter-Passkeys in iframes.

Um diese Herausforderungen zu bewältigen und eine sichere, nahtlose Erfahrung ähnlich wie bei Apple Pay zu schaffen, verfolgen Zahlungsanbieter oft einen hybriden Ansatz – sie kombinieren eine iframe-basierte Integration mit einem Redirect-Fallback für Safari (oder ältere Browser). In einigen Fällen werden System-Browser-Flows (z. B. ASWebAuthenticationSession unter iOS) zwingend erforderlich, wenn eine eingebettete WebView Passkeys überhaupt nicht zulässt.

Für einen Deep Dive in diese zahlungsspezifischen Szenarien – einschließlich Vergleichen von iframe vs. Redirect, Überlegungen zu nativen Apps und Best Practices für eine hohe Passkey-Akzeptanz – lesen Sie unseren dedizierten Artikel:

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

Get free Whitepaper

Insbesondere:

• Strategie A: Einbetten eines Cross-Origin-iframes erklärt, wie die Passkey-Erstellung und der Login inline gehandhabt werden, unter Bezugnahme auf die hier eingeführten Permissions-Policy-Einstellungen.
• Strategie B: Redirect-basierter Ansatz zeigt eine einfachere Integration, die die meisten Cross-Origin-Fallstricke umgeht, allerdings auf Kosten des Verlassens der Händlerdomain.
• System WebView ist für native Apps unerlässlich, da eingebettete WebViews häufig Drittanbieter-Passkey-Flows unterbrechen.

Dieser ergänzende Guide bietet tiefgehende Strategien zur Absicherung von Transaktionen, zur Überwindung der Cross-Origin-Beschränkungen von Safari und zur Optimierung der Passkey-Nutzung in Drittanbieter-Kontexten. Indem Sie die technischen Schritte in diesem Artikel mit diesen zahlungsorientierten Methoden kombinieren, können Sie einen reibungslosen, Phishing-resistenten Checkout-Flow direkt in einem iframe bereitstellen und so die nächste Stufe der Sicherheit und UX für Online-Zahlungen freischalten.

Die Integration von Passkeys in iframes verbessert die Benutzerauthentifizierung erheblich, indem sie sowohl die Sicherheit als auch die User Experience steigert. Dies ermöglicht eine nahtlose Authentifizierung ohne die Notwendigkeit von Weiterleitungen oder Pop-ups und gewährleistet eine konsistente UX über verschiedene Bereiche und Websites hinweg.

Implementierungen aus der Praxis, wie die Integration von Passkeys durch Shopify in ihrer Login-Komponente, zeigen die praktischen Vorteile und die Flexibilität dieses Ansatzes.