WebAuthn Relying Party ID (rpID) & Passkeys: Domains & Native Apps

Die Passkey-Authentifizierung wird schnell zur Norm, da Tech-Giganten wie TikTok, GitHub, WhatsApp, X (Twitter), LinkedIn und Amazon sie einführen oder dies bereits getan haben. Es ist offensichtlich, dass die Tech-Welt die Bedeutung einer einfachen und sicheren Authentifizierung erkennt.

Über die nahtlose Benutzererfahrung der Authentifizierung mit Face ID, Touch ID oder Windows Hello hinaus bieten Passkeys eine beispiellose Sicherheit im Vergleich zu traditionellen Authentifizierungsmethoden wie Passwörtern. Eines der herausragenden Merkmale ist ihre starke Phishing-Resistenz.

Testen Sie Passkeys in einer Live-Demo.

Passkeys testen

Ein Phishing-Angriff ist ein Angriff, bei dem das Opfer dazu verleitet wird, Anmeldeinformationen an eine gefälschte Website weiterzugeben, die vorgibt, die Original-Website zu sein. Stellen Sie sich zum Beispiel vor, Sie erhalten eine E-Mail, die scheinbar von Ihrer Bank stammt und Sie auffordert, sich anzumelden. Sie klicken auf den Link, und die Website sieht legitim aus. Sie geben also Ihre Anmeldeinformationen ein, und der Angreifer kann diese nutzen, um sich auf der Original-Website anzumelden. Dies wird im digitalen Zeitalter zu einem immer größeren Problem, und selbst große Unternehmen wie Okta (ein Authentifizierungsanbieter!) oder Retool sind Opfer von Spear-Phishing-Angriffen geworden (einer speziellen Form des Phishings, bei der einzelne Opfer besonders gezielt mit sehr persönlichen Phishing-Tricks angegriffen werden), was die Notwendigkeit robuster Sicherheitsmaßnahmen unterstreicht.

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

Cheat Sheet erhalten

Wenn Sie hingegen einen Passkey verwenden und die Seite eine Fälschung ist, schlägt Ihre Authentifizierung fehl. Das liegt daran, dass Passkeys über die Relying Party ID an die Domains gebunden sind, für die sie erstellt wurden.

Dieser Mechanismus ist in WebAuthn integriert, dem Passkey-zugrundeliegenden Webstandard für passwortlose Authentifizierung. WebAuthn baut auf zwei Kernzeremonien auf: der Registrierungs- und der Authentifizierungszeremonie.

Während der Registrierungszeremonie (Anmeldung) wird über eine Web- oder native App ein neuer Passkey für einen Online-Dienst (die Relying Party) erstellt. In diesem Prozess wird die Domain (Relying Party ID), für die der Passkey erstellt wird, im Passkey gespeichert.

Dies ermöglicht es der Authentifizierungszeremonie (Login) zu prüfen, ob der Online-Dienst (die Relying Party), zu dem die Web- oder native App gehört, mit der im Passkey gespeicherten Relying Party ID übereinstimmt.

Im Folgenden werden wir uns im Detail ansehen, wie dieser Domain-Matching-Prozess funktioniert und wie insbesondere native Apps gesichert werden.

Die Relying Party ID ist im Wesentlichen eine Domain, die innerhalb des Passkeys gespeichert wird. Sie stellt sicher, dass der Passkey nur funktioniert, wenn die aktuelle Browser-URL (der Ursprung des Benutzers, der automatisch bei jeder Anfrage gesendet wird) damit übereinstimmt (siehe den Ansatz für native Apps unten). Sie ist eine entscheidende Komponente der WebAuthn-Spezifikation, in die Sie hier tiefer eintauchen können. Die Relying Party ID kann die Root-Domain (z. B. corbado.com) oder eine Subdomain (auth.corbado.com) sein. Sie können die Root-Domain nicht als Relying Party ID speichern, wenn sie auf der Public Suffix List steht (die Liste und Bibliotheken zur Erkennung öffentlicher Suffixe finden Sie hier). Das Ändern der Relying Party ID für einen Online-Dienst macht bestehende Passkeys ungültig (Ausnahmen: Die neue Relying Party ID ist eine Subdomain der alten Relying Party ID, oder Related Origin Requests sind über .well-known/webauthn konfiguriert, um die Wiederverwendung von Passkeys über verbundene Domains hinweg zu ermöglichen).

Während des Authentifizierungsprozesses wird die Relying Party ID gegen die Browser-URL (Ursprung des Benutzers) geprüft, um sicherzustellen, dass sie übereinstimmen. Übereinstimmung in diesem Sinne bedeutet, dass entweder:

• Die Browser-URL (Ursprung des Benutzers) exakt mit der Relying Party ID übereinstimmt ODER
• Die Browser-URL (Ursprung des Benutzers) eine Subdomain ist, die mit der Relying Party ID übereinstimmt, und die Parent-Domain registrierbar ist (z. B. funktionieren com oder andere Domains auf der Public Suffix List nicht).

Hier ist eine detaillierte Übersicht, welchem originalHost (zweite Spalte) der Zugriff auf seine Parent-Domain erlaubt ist:

Im Folgenden sehen Sie die geparsten PublicKeyCredentialCreationOptions:

{
    "publicKey": {
        "attestation": "direct",
        "authenticatorSelection": {
            "authenticatorAttachment": "platform",
            "requireResidentKey": false,
            "userVerification": "preferred"
        },
        "challenge": "qNqrdXUrk5S7dCM1MAYH3qSVDXznb-6prQoGqiACR10=",
        "excludeCredentials": [],
        "pubKeyCredParams": [
            {
                "alg": -7,
                "type": "public-key"
            }
        ],
        "rp": {
            "id": "corbado.com",
            "name": "Corbado"
        },
        "timeout": 30000,
        "user": {
            "displayName": "Corbado user",
            "id": "bz9ZDfHzOBLycqISTAdWwWIZt8VO-6mT3hBNXS5jwmY="
        }
    }
}

rp steht für Relying Party.

Einer der größten Vorteile der Relying Party ID ist die Verhinderung von Phishing-Angriffen. Stellen Sie sich folgendes Szenario vor:

1. Ein Angreifer entwickelt einen PayPal-Klon, eine gefälschte Website, die versucht, Ihre PayPal-Anmeldeinformationen zu stehlen, um sich in Ihrem Namen anzumelden und Geld auf das Konto des Angreifers zu überweisen. Diese gefälschte PayPal-Website wird auf der Domain paybal.com gehostet (daher ist auf den ersten Blick oft nicht ersichtlich, dass es sich um eine andere Domain handelt).
2. Sie haben in der Vergangenheit bereits einen Passkey für die legitime PayPal-Website erstellt. Dieser Passkey hat die Relying Party ID paypal.com gespeichert.
3. Sie besuchen die gefälschte PayPal-Website unter paybal.com (da Sie diese Seite besuchen, lautet der Ursprung Ihrer Anfrage paybal.com*) und die Seite sendet Ihrem Gerät (dem Authenticator) eine Challenge für die Relying Party ID paypal.com (hier versucht sie, Sie auszutricksen) und bittet Sie, diese mit Ihrem Passkey für die Relying Party ID paypal.com zu signieren.
4. Ihr Gerät (der Authenticator) prüft, ob der Ursprung der Anfrage (paypal.com) und die im Passkey gespeicherte Relying Party ID (paypal.com) übereinstimmen.
5. Da sie offensichtlich nicht übereinstimmen, schlägt die Authentifizierung fehl, und Sie davor bewahrt, einem Angreifer Zugang zu Ihrem PayPal-Konto zu verschaffen.

Das folgende Diagramm veranschaulicht diesen Phishing-Präventionsmechanismus.

Im Falle einer nativen App unterscheidet sich die Ursprungsverarbeitung je nach Plattform: Unter Android wird der Ursprung als android:apk-key-hash:<SHA256_fingerprint> formatiert. Unter iOS ist der WebAuthn-Ursprung der Web-Ursprung der RP (z. B. https://paypal.com). In beiden Fällen wird das Vertrauen zwischen Ihrer nativen App und dem Server über die entsprechende Assoziationsdatei verifiziert (siehe unten). Detaillierte Informationen darüber, wie die Ursprungsvalidierung für native Apps funktioniert, finden Sie in unserem speziellen Leitfaden zur WebAuthn-Ursprungsvalidierung für native Apps.

Werden Sie Teil unserer Passkeys Community für Updates und Support.

Beitreten

Um Passkeys in einer nativen App zu implementieren, kann ein Entwickler entscheiden, ob er sie über WebView oder nativ hinzufügen möchte. Lassen Sie uns im Folgenden die Vor- und Nachteile beider Ansätze untersuchen.

Die Verwendung einer WebView* zur Integration von Passkeys bedeutet, dass ein Webbrowser in die native App eingebettet wird, um den Authentifizierungsprozess abzuwickeln. Dieser Ansatz zeigt im Wesentlichen eine Webseite innerhalb der App an, was es einfacher macht, webbasierte Authentifizierungsflüsse wiederzuverwenden, ohne sie für die native Plattform neu schreiben zu müssen. Es gibt jedoch einige Nachteile. WebViews unterstützen möglicherweise nicht alle Passkey-Funktionen, und es besteht ein potenzielles Risiko von "Man-in-the-Middle"-Angriffen, wenn sie nicht sicher implementiert werden. Darüber hinaus ist die Benutzererfahrung möglicherweise nicht so reibungslos wie bei nativen Integrationen, und es kann Herausforderungen geben, ein konsistentes Verhalten über verschiedene Geräte und OS-Versionen hinweg aufrechtzuerhalten.

*Es gibt mehrere Arten von WebViews: Unter iOS (WKWebView, SFSafariViewController oder SFAuthenticationSession / ASWebAuthenticationSession für OAuth/OpenID Connect basierte Authentifizierungsflüsse) und Android (WebView, CCT-Chrome Custom Tabs). Details finden Sie in diesem Blogbeitrag. Wir empfehlen die Verwendung von SFSafariViewController/ ASWebAuthenticationSession und Chrome Custom Tabs im Kontext von Passkeys, wenn Sie keine native Integration wünschen.

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

Adoptionsdaten ansehen

Die native Integration beinhaltet die Einbindung der Passkey-Funktionalität direkt in die iOS- oder Android-App unter Verwendung plattformspezifischer APIs und Bibliotheken. Diese Methode bietet eine nahtlosere Benutzererfahrung, da kein Wechsel zwischen der nativen App und einer WebView erforderlich ist. Sie ermöglicht auch eine bessere Leistung und ein konsistenteres Look-and-Feel. Aus sicherheitstechnischer Sicht kann die native Integration einen verbesserten Schutz gegen bestimmte Arten von Angriffen bieten, insbesondere wenn sie mit plattformspezifischen Sicherheitsfunktionen kombiniert wird. Der Implementierungsaufwand kann jedoch höher sein, da Entwickler separaten Code für jede Plattform (Android und iOS) schreiben und pflegen müssen. Zudem könnte es erforderlich sein, die App häufiger zu aktualisieren, um mit den neuesten Passkey- / WebAuthn-Spezifikationen auf dem neuesten Stand zu bleiben.

Im Folgenden konzentrieren wir uns auf die native Passkey-Integration.

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

Adoptionsdaten ansehen

Native Apps (z. B. iOS- oder Android-Apps) stellen im Vergleich zu Web-Apps eine Herausforderung dar. Im Gegensatz zu Web-Apps gibt es keine Browser-URL, die gegen die Relying Party ID geprüft werden könnte. Dennoch werden, um das gleiche Sicherheitsniveau zu gewährleisten, Domains über Assoziationsdateien mit nativen Apps verbunden, sodass Vertrauen zwischen einer Domain und einer nativen App hergestellt wird.

Dies ist besonders wichtig, wenn ein Passkey in einer Web-App erstellt wurde und für dieselbe Relying Party ID in einer nativen App (und umgekehrt) verwendet werden soll.

iOS verwendet die apple-app-site-association-Datei. Diese Datei enthält verschiedene Berechtigungen (Entitlements), aber für WebAuthn und Passkeys ist das webcredentials-Entitlement wichtig.

{
    "webcredentials": {
        "apps": ["9RF9KY88B2.com.corbado.passkeys"]
    }
}

In webcredentials.apps müssen Sie Ihr Application Identifier Prefix (z. B. 9RF9KY77B2) und Ihren Bundle Identifier (z. B. com.corbado.passkeys) speichern.

Damit native iOS-Apps funktionieren, muss die apple-app-site-association-Datei im Verzeichnis /.well-known der Relying Party ID gespeichert werden (https://<Relying Party ID>/.well-known/apple-app-site-association).

Sehen Sie sich hier ein Live-Beispiel an.

Android verwendet die assetlinks.json-Datei, die wie ihr iOS-Pendant spezielle Konfigurationen für WebAuthn und Passkeys erfordert.

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.corbado.passkeys.pub",
            "sha256_cert_fingerprints": [
                "F8:90:4E:9A:99:01:71:75:25:38:D5:36:16:2D:B3:65:EB:41:51:D4:53:9A:72:BC:4B:56:C5:16:43:62:E2:C0"
            ]
        }
    }
]

Sie müssen die Relation-Werte delegate_permission/common.handle_all_urls und delegate_permission/common.get_login_creds setzen. Außerdem müssen Sie Ihren Paketnamen und den SHA-256-Fingerabdruck Ihres Signaturzertifikats hinzufügen.

Um das Teilen eines Passkeys zwischen einer nativen App und einer Web-App zu ermöglichen, müssen Sie zwei Einträge hinzufügen. Einen für den Namespace web und einen für den Namespace android_app.

Sehen Sie sich hier ein Live-Beispiel an.

Damit Android-Apps funktionieren, muss die assetlinks.json-Datei im Verzeichnis /.well-known der Relying Party ID gespeichert werden https://<Relying Party ID>/.well-known/assetlinks.json - also ziemlich ähnlich wie bei iOS.

Schauen Sie sich diesen Blogbeitrag an, um eine Beispielimplementierung zu sehen, die Passkeys zwischen einer nativen Android- / iOS-App und einer Web-App teilt.

Experimentieren Sie mit Passkey-Flows im Passkeys Debugger.

Kostenlos testen

Der Prozess, um Vertrauen zwischen einer iOS-App und einer Web-App herzustellen, sieht wie folgt aus:

1. Der iOS-App-Entwickler muss eine Liste von Domains angeben, die er mit der nativen App verknüpfen möchte. Diese Domains werden in den Entitlements der iOS-App hart codiert, z. B.:

• webcredentials:auth.Corbado.com
• webcredentials:*.Corbado.com

2. Jedes Mal, wenn die iOS-App installiert oder aktualisiert wird, lädt iOS die apple-app-site-association-Datei für jeden Eintrag in der Entitlement-Liste der iOS-App herunter.

3. Wenn eine Anmeldeinformation (z. B. ein Passkey) in einer iOS-App erstellt wird, validiert die iOS-App, ob die Domain des Relying-Party-Servers mit der iOS-App verknüpft ist, indem sie die folgenden zwei Aspekte überprüft:

• Existiert eine apple-app-site-association-Datei für diese Relying-Party-Server-Domain auf dem Gerät?
• Ist die iOS-App in dieser apple-app-site-association-Datei aufgeführt?

Wenn, und nur wenn, beide Fragen mit Ja beantwortet werden können, kann ein Passkey innerhalb der iOS-App erstellt werden.

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

Der Prozess, um Vertrauen zwischen einer Android-App und einer Web-App herzustellen, sieht wie folgt aus:

1. Der Android-App-Entwickler muss eine Liste von Domains angeben, die er mit der Android-App verknüpfen möchte. Diese Domains werden als Ziele (Targets) mit dem Namespace web in der assetlinks.json-Datei gespeichert. Um zu deklarieren, dass Android-Apps und Web-Apps Anmeldeinformationen teilen, muss delegate_permission/common.get_login_creds angegeben werden. Details finden Sie hier.

2. Wenn ein Passkey in der Android-App erstellt wird, validiert die Android-App, ob die Relying Party ID mit der Android-App verknüpft ist, indem sie die assetlinks.json überprüft:

• Existiert eine assetlinks.json-Datei für diese Relying Party ID unter https://<Relying Party ID>./well-known/assetlinks.json?
• Ist die Android-App korrekt als Ziel definiert?

3. Wenn, und nur wenn, beide Fragen mit Ja beantwortet werden können, kann ein Passkey innerhalb der Android-App erstellt werden.

Das Diagramm unten vergleicht diese Vertrauensbildungsprozesse nebeneinander.

Abonnieren Sie unseren Passkeys Substack für aktuelle News.

Abonnieren

Im Folgenden geben wir einen detaillierten Überblick über die verschiedenen Einstellungen, die erforderlich sind, um die Passkey-Authentifizierung für native Apps richtig einzurichten.

Für Flutter gilt die jeweilige Regel für Android oder iOS. Die einzige Flutter-spezifische Einstellung ist die Registrierung von Assoziationsdateien, wo Sie Folgendes hinzufügen sollten:

• Für Android: flutter_deeplinking_enabled zur AndroidManifest.xml
• Für iOS: FlutterDeepLinkingEnabled true zur Info.plist

Da wir selbst die Erfahrung gemacht haben, dass die Arbeit mit Relying Party IDs, verschiedenen Ebenen von (Sub-)Domains und CNAMEs eine recht herausfordernde Aufgabe sein kann, präsentieren wir vier verschiedene Beispiele und erklären, warum und wie sie funktionieren.

Beachten Sie, dass die CNAME-Tabellenzeile für die Passkey-Authentifizierung nicht erforderlich ist und nur ein Ergebnis unserer Recherchen ist, das wir hinzufügen wollten.

In diesem Beispiel kann die apple-app-site-association / assetlinks.json-Datei für Corbado.com bei der Installation / Aktualisierung der nativen App problemlos heruntergeladen werden, da sich die Datei am selben Ort wie die Relying Party ID befindet.

Ein Passkey für die Relying Party ID kann erstellt werden.

In diesem Beispiel kann die apple-app-site-association / assetlinks.json-Datei für auth.corbado.com problemlos heruntergeladen werden, wenn die native App installiert / aktualisiert wird, da sich die Datei am gleichen Ort wie die Relying Party ID befindet, da der CNAME von der Relying Party ID auf den gespeicherten Ort zeigt.

Ein Passkey für die Relying Party ID kann erstellt werden.

In diesem Beispiel kann die apple-app-site-association / assetlinks.json-Datei für auth.corbado.com problemlos heruntergeladen werden, wenn die native App installiert / aktualisiert wird, da sich die Datei aufgrund des CNAME an dem Ort befindet, an dem auth.corbado.com sie erwartet.

ABER: Die apple-site-association-file / assetlinks.json für corbado.com kann nicht heruntergeladen werden, wenn die native App installiert / aktualisiert wird, da sich die Datei nicht unter https://corbado.com/.well-known/apple-app-site-association / https://corbado.com/.well-known/assetlinks.json befindet, wo sie erwartet wird und kein CNAME darauf zeigt.

Ein Passkey für die Relying Party ID kann nicht erstellt werden.

In diesem Beispiel kann die apple-app-site-association-Datei für corbado.com problemlos heruntergeladen werden, wenn die native App installiert / aktualisiert wird, da sich die Datei dort befindet, wo sie erwartet wird, und das webcredentials-Entitlement (*.corbado.com) mit der Relying Party ID (auth.corbado.com) übereinstimmt. Beachten Sie, dass dieses Beispiel für Android nicht funktioniert, da Android nicht mit etwas wie (Wildcard-)Entitlements arbeitet. Im Allgemeinen wird diese Art der Definition von Relying Party IDs nicht empfohlen.

Ein Passkey für die Relying Party ID kann erstellt werden.

Werden Sie Teil unserer Passkeys Community für Updates und Support.

Beitreten

Fehler:

Sie haben mit der Entwicklung begonnen und eine Subdomain (z. B. login.acme.com) als Ihre Relying Party ID definiert. Die ersten Benutzer haben einen Passkey für diese Relying Party ID erstellt. Dann stellen Sie fest, dass Sie diese Passkeys auch für die Authentifizierung auf einer anderen Subdomain (z. B. app.acme.com) benötigen. Da der Ursprung eines Benutzers und die Relying Party ID für die neue Subdomain nicht übereinstimmen, kann sich der Benutzer nicht mit dem Passkey anmelden. Das Ändern der Relying Party ID in Ihren WebAuthn-Einstellungen auf acme.com würde alle bestehenden Passkeys ungültig machen, da der neue Ursprung und die in den bestehenden Passkeys gespeicherte Relying Party ID nicht übereinstimmen.

Lösung:

Prüfen Sie bei der anfänglichen Definition Ihrer Relying Party ID alles doppelt, da dies mehr oder weniger final ist. Wenn Sie sich unsicher sind und zukunftssicher sein möchten, was bedeutet, dass andere Subdomains in Zukunft möglicherweise den Passkey für die Authentifizierung benötigen, empfehlen wir, die Root-Domain (z. B. acme.com) als Relying Party ID zu verwenden, es sei denn, sie steht auf der Public Suffix List.

Fehler:

Sie entwickeln gleichzeitig eine native und eine Web-App. Um die Dinge zu beschleunigen, verwenden Sie zwei verschiedene WebAuthn-Server (mit unterschiedlichen Relying Party IDs für die native und die Web-App). Wenn Ihre Benutzer die ersten Passkeys erstellen, wird die jeweilige Relying Party ID im Passkey gespeichert. Ein geräte- / plattformübergreifendes Login mit demselben Passkey, z. B. mit einem in einer Web-App erstellten Passkey und dem Versuch, sich in einer nativen App anzumelden, ist nicht mehr möglich. Das Zusammenführen der beiden WebAuthn-Server macht die Passkeys, die beim alten WebAuthn-Server (alte Relying Party ID) registriert wurden, unbrauchbar, und Ihre Benutzer können sich mit diesen Passkeys nicht mehr anmelden.

Lösung:

Wenn Sie mehrere Anwendungen haben (z. B. eine Web-App und eine native App), haben Sie immer nur einen WebAuthn-Server und definieren Sie nur eine Relying Party ID für alle Ihre Apps. Die Verknüpfung zwischen diesen Apps kann über die oben beschriebenen Schritte erfolgen.

Fehler:

Sie beginnen mit der Entwicklung Ihrer Anwendung, haben die Assoziationsdateien konfiguriert und auf Ihrem Server bereitgestellt. Aus irgendeinem Grund erhalten Sie immer noch Fehlermeldungen und finden die Ursache nicht.

Lösung:

Eine mögliche Ursache für die Fehlermeldung könnte eine fehlerhafte oder nicht erreichbare Assoziationsdatei sein. Bevor Sie eine Assoziationsdatei auf einem Server bereitstellen, empfehlen wir dringend, die Gültigkeit und Erreichbarkeit (oft befinden sich diese Dateien hinter einem robusten VPN oder einer Firewall, die den ordnungsgemäßen Zugriff für die Crawler von Apple und Google verhindert) einer Assoziationsdatei über die für iOS und Android bereitgestellten Tools zu überprüfen.

Fehler:

Sie haben Ihre apple-app-site-association-Datei auf Ihrem Server bereitgestellt und möchten sofort damit beginnen, einen Passkey auf Ihrem Testgerät zu erstellen. Aus irgendeinem Grund können Sie den Passkey nicht erstellen und erhalten Fehlermeldungen.

Lösung:

Der Grund für diese Fehlermeldungen ist, dass iOS-Geräte die apple-app-site-association-Datei herunterladen, um die Relying Party zu validieren. Dazu senden iOS-Geräte keine direkte Anfrage an Ihren Server, sondern nutzen stattdessen ein CDN. Sowohl das Gerät als auch das CDN cachen die apple-app-site-association-Datei, nachdem sie erfolgreich abgerufen wurde. Aufgrund dieser Caching-Funktionalität spiegeln sich neue Änderungen an Ihrer apple-app-site-association-Datei nicht direkt in Ihrer App wider. Es kann bis zu 24 Stunden dauern, bis das CDN die apple-app-site-association-Datei gecacht hat. Um diese Einschränkung während der Entwicklung zu umgehen, können Sie ?mode=developer an die Relying Party ID anhängen und das Caching vollständig deaktivieren (z. B. wäre die Relying Party ID acme.com?mode=developer).

Fehler:

Sie beginnen mit der Entwicklung einer Android-App und möchten diese auf einem Android-Emulator testen. Aus irgendeinem Grund erhalten Sie Fehlermeldungen, obwohl Sie den Android-Emulator richtig eingerichtet haben und andere Apps darauf reibungslos zu funktionieren scheinen.

Lösung:

Android-Versionen, Play Store-Unterstützung und API-Versionen spielen eine große Rolle beim Testen einer Passkey-Anwendung. Außerdem müssen Sie in einem Google-Konto angemeldet sein. Weitere Details finden Sie in unserem Abschnitt zur Fehlerbehebung.

Unsere allgemeine Empfehlung ist, Ihre Relying Party ID basierend auf Ihrer Anwendungslandschaft und Ihren Anforderungen sorgfältig auszuwählen. Im Folgenden haben wir die gängigsten Anwendungsfälle gesammelt, aber unsere generelle Empfehlung lautet, dass Sie darauf abzielen sollten, Ihre Root-Domain als Ihre Relying Party ID zu wählen und Ihre Authentifizierung auf diese Weise zu konfigurieren. Mit Corbado haben wir dies ebenfalls bereits auf diese Weise für Sie vorkonfiguriert (da dies Teil unseres Ansatzes ist, eine nahtlose Passkey-Authentifizierung für alle technischen Setups anzubieten. Unsere UI-Komponenten und SDKs sind darauf vorbereitet, mit Ihrer Root-Domain als Relying Party ID verwendet zu werden).

Im Folgenden stellen wir einen sehr spezifischen Entscheidungsbaum zur Verfügung, der Ihnen helfen soll, die richtige Relying Party ID zu bestimmen und wie Sie Assoziationsdateien behandeln / hosten sollten, wenn Sie Corbado als Ihre Passkey-Lösung verwenden.

Die erste Entscheidung ist, ob Sie sich in einer Entwicklungs- oder Produktionsumgebung befinden. Die nächste Entscheidungsebene basiert auf Ihrer Anwendungslandschaft: Haben Sie nur eine native App oder eine native und eine Web-App?

Für die Entwicklungsumgebung gehen wir davon aus, dass Sie schnell mit der Entwicklung und dem Testen beginnen möchten. Die Relying Party ID kann später geändert werden, wenn Sie live gehen möchten.

• Setzen Sie Relying Party ID = pro-XXX.frontendapi.cloud.corbado.io (Standardwert)
• Corbado hostet die Assoziationsdatei für Sie
• Kein DNS ToDo für Sie

Es ist nicht ohne Weiteres möglich, sowohl die Web-App als auch die native App gleichzeitig zu testen.

Option 1:

Entweder Sie setzen Relying Party ID = pro-XXX.frontendapi.cloud.corbado.io (native App funktioniert) ODER Sie setzen Relying Party ID = localhost (Web-App funktioniert).

Option 2:

Die einzige Lösung, damit native und Web-App gleichzeitig funktionieren, ist die Verwendung eines lokalen Reverse Proxys (es ist eine ziemlich improvisierte Lösung):

• Setzen Sie Relying Party ID = acme-dev.com
• Setzen Sie CNAME von acme-dev.com => pro-XXX.frontendapi.cloud.corbado.io
• Fügen Sie einen lokalen /etc/hosts-Eintrag localhost acme-dev.com hinzu
• Fügen Sie einen Reverse Proxy (nginx) mit einer Regel für acme-dev.com => localhost:3000 hinzu (als Beispiel)

In der Produktionsumgebung müssen Sie entscheiden, ob Ihnen eine Subdomain als Relying Party ID ausreicht (z. B. auth.acme.com) oder ob Sie eine Root-Domain als Relying Party ID wünschen (z. B. acme.com).

• Setzen Sie Relying Party ID = auth.acme.com
• Corbado hostet die Assoziationsdatei für Sie
• Setzen Sie CNAME von auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io

• Setzen Sie Relying Party ID = auth.acme.com
• Corbado hostet die Assoziationsdatei für Sie
• Setzen Sie CNAME von auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io (wird auch für Cookies benötigt, wenn Sie das Session-Management von Corbado verwenden)

• Setzen Sie Relying Party ID = acme.com
• Hosten Sie die Assoziationsdatei selbst auf Ihrem eigenen Server unter acme.com/.well-known/<association file>
• Kein DNS ToDo für Sie

• Setzen Sie Relying Party ID = acme.com
• Hosten Sie die Assoziationsdatei selbst auf Ihrem eigenen Server unter acme.com/.well-known/<association file>
• Wenn Sie das Session-Management von Corbado verwenden, müssen Sie CNAME von auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io setzen, damit Cookies funktionieren (dieser CNAME wird nicht für die Relying Party ID benötigt, sondern ausschließlich für das Session-Management)

Der folgende Entscheidungsbaum fasst alle Konfigurationspfade zusammen.

Die Relying Party ID ist ein Eckpfeiler der WebAuthn- und Passkey-basierten Authentifizierung und bietet eine starke Phishing-Resistenz. Ihre richtige Konfiguration, das Verständnis der Feinheiten des Domain-Matchings und die Sicherstellung einer korrekten Bereitstellung für native Apps sind von entscheidender Bedeutung. Dieser Blogbeitrag hat Ihnen gezeigt, wie Sie sie richtig einrichten und wie Sie mit verschiedenen Fehlern umgehen. Sobald Ihre rpID-Konfiguration solide ist, konzentrieren Sie sich auf die Optimierung Ihrer Passkey-Erstellungs- und Login-Flüsse, um eine echte Akzeptanz zu fördern. Für weitere Einblicke in die Einrichtung von Passkeys für native Apps empfehlen wir, über Passkeys in Flutter zu lesen.

Wenn Sie weitere Fragen haben oder Unterstützung benötigen, zögern Sie nicht, uns zu kontaktieren.

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

Der Authenticator vergleicht den tatsächlichen Ursprung des Browsers mit der im Passkey gespeicherten Relying Party ID. Wenn ein Angreifer eine gefälschte Website auf einer anderen Domain hostet, führt die Nichtübereinstimmung des Ursprungs automatisch dazu, dass die Authentifizierung fehlschlägt, selbst wenn die gefälschte Challenge eine legitime RP ID beansprucht. Diese Bindung bedeutet, dass ein auf paypal.com registrierter Passkey nicht auf einer ähnlich aussehenden Domain wie paybal.com verwendet werden kann.

Das Ändern der RP ID macht alle bestehenden Passkeys ungültig, da die in jedem Credential gespeicherte RP ID nicht mehr mit dem neuen Wert übereinstimmt. Die einzigen Ausnahmen sind, wenn die neue RP ID eine Subdomain der alten ist oder wenn Related Origin Requests über .well-known/webauthn konfiguriert sind. Wählen Sie von Anfang an die Root-Domain als RP ID, um dieses irreversible Problem zu vermeiden.

iOS ruft die apple-app-site-association-Datei nicht direkt von Ihrem Server ab. Es verwendet das CDN von Apple, das bis zu 24 Stunden benötigen kann, um eine neu bereitgestellte oder aktualisierte Datei zu cachen. Hängen Sie während der Entwicklung ?mode=developer an die Relying Party ID an, um das Caching vollständig zu umgehen.

Die Verwendung der Root-Domain (z. B. acme.com) wird empfohlen, da auf einer beliebigen Subdomain erstellte Passkeys über alle Subdomains dieser Root hinweg authentifizieren können. Eine Subdomain-RP ID beschränkt die Passkey-Nutzung auf diese Subdomain und ihre untergeordneten Domains, was später flussübergreifende Subdomain-Abläufe unterbrechen kann. Wenn Sie mehrere Root-Domains wie acme.com und acme.co.uk haben, konfigurieren Sie Related Origin Requests über .well-known/webauthn, um die Wiederverwendung von Passkeys über diese hinweg zu ermöglichen.