--- url: 'https://www.corbado.com/de/blog/webauthn-relying-party-id-rpid-passkeys' title: 'WebAuthn Relying Party ID (rpID) & Passkeys: Domains & Native Apps' description: 'Dieser Blogbeitrag erklärt die WebAuthn Relying Party ID für die Passkey-Authentifizierung. Er beschreibt die richtige Konfiguration, das Domain-Matching und Konfigurationen für native Apps.' lang: 'de' author: 'Vincent Delitz' date: '2026-06-15T13:56:38.233Z' lastModified: '2026-06-16T06:02:13.237Z' keywords: 'relying party id, passkey authentifizierung, webauthn, domain matching, native apps' category: 'WebAuthn Know-How' --- # WebAuthn Relying Party ID (rpID) & Passkeys: Domains & Native Apps ## Key Facts - Die **Relying Party ID** ist eine Domain, die in jedem Passkey eingebettet ist. Die Authentifizierung schlägt fehl, wenn der Browser-Ursprung (Origin) nicht übereinstimmt, was Passkeys stark phishing-resistent macht. - Die **RP ID** darf nicht auf der **Public Suffix List** stehen, und eine Änderung macht alle bestehenden Passkeys ungültig. Verwenden Sie standardmäßig die Root-Domain, um zukunftssicher zu sein. - iOS-Apps erfordern eine **apple-app-site-association**-Datei unter `/.well-known/` unter der RP ID. Android erfordert eine **assetlinks.json** unter demselben Pfad. Es kann bis zu 24 Stunden dauern, bis neue Dateien gecacht sind. - Mehrere Root-Domains benötigen **Related Origin Requests** via `.well-known/webauthn` für das Teilen von Passkeys. Verwenden Sie einen einzigen WebAuthn-Server mit einer RP ID für alle Apps, egal ob Web oder nativ. ## 1. Einführung Die Passkey-[Authentifizierung](https://www.corbado.com/de/blog/komplexe-passwoerter-bald-geknackt) wird schnell zur Norm, da Tech-Giganten wie [TikTok](https://www.corbado.com/blog/tiktok-passkeys), GitHub, [WhatsApp](https://www.corbado.com/blog/whatsapp-passkeys), X (Twitter), [LinkedIn](https://www.corbado.com/blog/linkedin-passkeys) und Amazon sie einführen oder dies bereits getan haben. Es ist offensichtlich, dass die Tech-Welt die Bedeutung einer einfachen und sicheren [Authentifizierung](https://www.corbado.com/de/blog/komplexe-passwoerter-bald-geknackt) erkennt. Über die nahtlose Benutzererfahrung der [Authentifizierung](https://www.corbado.com/de/blog/komplexe-passwoerter-bald-geknackt) mit [Face ID](https://www.corbado.com/faq/is-face-id-passkey), Touch ID oder [Windows Hello](https://www.corbado.com/glossary/windows-hello) hinaus bieten Passkeys eine beispiellose [Sicherheit](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) im Vergleich zu traditionellen Authentifizierungsmethoden wie Passwörtern. Eines der herausragenden Merkmale ist ihre starke [Phishing](https://www.corbado.com/glossary/phishing)-Resistenz. Ein [Phishing](https://www.corbado.com/glossary/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 ](https://www.darkreading.com/application-security/okta-flaw-involved-mgm-resorts-breach-attackers-claim)(ein Authentifizierungsanbieter!) oder [Retool ](https://retool.com/blog/mfa-isnt-mfa/)sind Opfer von Spear-[Phishing](https://www.corbado.com/glossary/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. 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. > Sie können sich nicht mit einem Passkey auf einer anderen Website anmelden, was Passkeys > stark [phishing-resistent](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) macht (obwohl kein > System absolut immun gegen alle Angriffsvektoren ist). Dieser Mechanismus ist in WebAuthn integriert, dem Passkey-zugrundeliegenden Webstandard für [passwortlose Authentifizierung](https://www.corbado.com/de/glossary/ctap). WebAuthn baut auf zwei Kernzeremonien auf: der Registrierungs- und der Authentifizierungszeremonie. Während der Registrierungszeremonie (Anmeldung) wird über eine Web- oder [native App](https://www.corbado.com/blog/native-app-passkeys) ein neuer Passkey für einen Online-Dienst (die [Relying Party](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/relying-party)), zu dem die Web- oder [native App](https://www.corbado.com/blog/native-app-passkeys) gehört, mit der im Passkey gespeicherten [Relying Party](https://www.corbado.com/glossary/relying-party) ID übereinstimmt. Im Folgenden werden wir uns im Detail ansehen, wie dieser [Domain-Matching](#what-relying-party-id)-Prozess funktioniert und wie insbesondere native Apps gesichert werden. ## 2. Was ist die Relying Party ID? Die [**Relying Party ID**](https://www.w3.org/TR/webauthn-2/#relying-party-identifier) 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](#integration-options-native-apps)). Sie ist eine entscheidende Komponente der WebAuthn-Spezifikation, in die Sie [hier](https://www.w3.org/TR/webauthn-2/) 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](https://publicsuffix.org/learn/)). 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: ![relying party id table](https://www.corbado.com/website-assets/relying_party_id_table_4c98cc04f4.jpg) Im Folgenden sehen Sie die geparsten [**PublicKeyCredentialCreationOptions**](https://www.w3.org/TR/webauthn-2/#iface-pkcredential): ```json { "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](https://www.corbado.com/blog/paypal-passkeys)-Klon, eine gefälschte Website, die versucht, Ihre [PayPal](https://www.corbado.com/blog/paypal-passkeys)-Anmeldeinformationen zu stehlen, um sich in Ihrem Namen anzumelden und Geld auf das Konto des Angreifers zu überweisen. Diese gefälschte [PayPal](https://www.corbado.com/blog/paypal-passkeys)-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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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:` 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](#configuring-relying-party-native-apps)). 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._ ## 3. Die zwei verschiedenen Integrationsoptionen für native Apps Um Passkeys in einer nativen App zu implementieren, kann ein Entwickler entscheiden, ob er sie über [WebView](https://www.corbado.com/blog/native-app-passkeys) oder nativ hinzufügen möchte. Lassen Sie uns im Folgenden die Vor- und Nachteile beider Ansätze untersuchen. ### 3.1 Passkey-Integration via WebView ![Passkey Integration WebView (GitHub)](https://www.corbado.com/website-assets/650c601b1eb462e25702a870_android_webview_passkey_github_8bc81d9852.jpg) Die Verwendung einer **WebView**\* zur Integration von Passkeys bedeutet, dass ein Webbrowser in die [native App](https://www.corbado.com/blog/native-app-passkeys) 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._ ### 3.2 Native Passkey-Integration ![Native Passkey Integration (Kayak)](https://www.corbado.com/website-assets/650c625cac723f594137a029_android_native_passkey_kayak_0f689e761e.jpg) Die **native Integration** beinhaltet die Einbindung der Passkey-Funktionalität direkt in die [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)- oder [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)-App unter Verwendung plattformspezifischer APIs und Bibliotheken. Diese Methode bietet eine nahtlosere Benutzererfahrung, da kein Wechsel zwischen der nativen App und einer [WebView](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/how-to-enable-passkeys-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. ## 4. Konfiguration der Relying Party für native Apps Native Apps (z. B. [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)- oder [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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. ### 4.1 Assoziationsdateien unter iOS: apple-app-site-association 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. ```json { "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:///.well-known/apple-app-site-association`). Sehen Sie sich [hier](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/apple-app-site-association) ein Live-Beispiel an. ### 4.2 Assoziationsdateien unter Android: assetlinks.json [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) verwendet die `assetlinks.json`-Datei, die wie ihr iOS-Pendant spezielle Konfigurationen für WebAuthn und Passkeys erfordert. ```json [ { "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](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/assetlinks.json) ein Live-Beispiel an. Damit Android-Apps funktionieren, muss die assetlinks.json-Datei im Verzeichnis `/.well-known` der Relying Party ID gespeichert werden `https:///.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. ## 5. Vertrauen zwischen einer nativen App und einer Web-App herstellen ### 5.1 iOS 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. ### 5.2 Android 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](https://developer.android.com/training/sign-in/passkeys#add-support-dal). 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://./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. ## 6. Übersicht der Einstellungen für Android, iOS & Flutter Im Folgenden geben wir einen detaillierten Überblick über die verschiedenen Einstellungen, die erforderlich sind, um die Passkey-Authentifizierung für native Apps richtig einzurichten. | Funktion | iOS | Android | | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Offizieller Implementierungsleitfaden für native Passkey-Authentifizierung | Apple Developer | Google Developer | | Erlaubt das Teilen von Passkeys mit Web-Apps | Ja, via apple-app-site-association-Datei | Ja, via assetlinks.json | | Speicherort der Assoziationsdatei | [https://acme.com/.well-known/apple-app-site-association](https://acme.com/.well-known/apple-app-site-association) | [https://acme.com/.well-known/assetlinks.json](https://acme.com/.well-known/assetlinks.json) | | Datei gecacht | Ja (seit iOS 14), anfängliche Synchronisierung kann bis zu 24h dauern | Ja (durch Play Services) | | Umgehung möglich | Ja, mit alternate mode-Sektion | Nein | | Testbar mit | apple-app-site-association test | assetlinks.json test | | App-Identifier mit Beispiel | `.`, z. B. `T84QZS65DQ.com.facebook.Messenger` | SHA256-Fingerabdruck, z. B. `E3:F9:E1:E0:CF:99:D0:E5:6A:05:5B:A6: 5E:24:1B:33:99: 7F:CE:A5:24:32: 6B:0C:DD:6E:C1:32: 7E:D0:FD:C1` | | Wo man den App-Identifier findet | Das Team Application Identifier Prefix ist im Entwicklerkonto auf developer.apple.com zu finden, und der Bundle Identifier ist der genaue Name aus dem XCode-Projekt. | Wenn bereits hochgeladen: Google Play Console > Release management > App signing. Lokal: `keytool -list -v -keystore -alias -storepass -keypass ` | | Name der Sektion, die App mit Web verknüpft | applinks (nicht erforderlich für Passkeys) | `delegate_permission/common.handle_all_urls` (erforderlich für Passkeys) | | Name der Sektion, die das Teilen von Credentials zwischen App / Web erlaubt | webcredentials | `delegate_permission/common.get_login_creds` | | Registrierung aller Assoziationsdateien | Aktivieren und hinzufügen der assoziierten Domain in der XCode-Entwicklungsumgebung (Einstellung der Eigenschaft zur Generierung der Entitlements-Datei) | Bei Verwendung der Credential Manager API ist die Registrierung der assetlinks.json im Manifest für Passkeys nicht erforderlich (für Passwörter jedoch schon). Wenn Sie die Credential Manager API nicht verwenden, müssen Sie die Hostnamen mit einem ``-Eintrag in der AndroidManifest.xml in der spezifischen Activity auflisten (Teil des Android-App-Quellcodes). Der `` muss autoVerify=true sein. | Für [Flutter](https://www.corbado.com/blog/flutter-passkeys-package) gilt die jeweilige Regel für Android oder iOS. Die einzige [Flutter](https://www.corbado.com/blog/flutter-passkeys-package)-spezifische Einstellung ist die Registrierung von Assoziationsdateien, wo Sie Folgendes hinzufügen sollten: - Für Android: [flutter_deeplinking_enabled zur AndroidManifest.xml](https://docs.flutter.dev/cookbook/navigation/set-up-app-links) - Für iOS: [FlutterDeepLinkingEnabled true zur Info.plist](https://docs.flutter.dev/cookbook/navigation/set-up-universal-links) ## 7. Beispiele für gültige & ungültige Relying Party IDs & Assoziationsdateien 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. ### 7.1 Beispiel 1: Relying Party ist die Root-Domain | **Relying Party ID** | corbado.com | | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Entitlements (nur iOS)** | webcredentials:corbado.com | | **Speicherort der apple-app-site-association-Datei** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **Speicherort der assetlinks.json-Datei** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | n/a | 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.** ### 7.2 Beispiel 2: Relying Party ist eine Subdomain und CNAME ist gesetzt | Relying Party ID | auth.corbado.com | | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Entitlements (nur iOS)** | webcredentials:auth.corbado.com | | **Speicherort der apple-app-site-association-Datei** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **Speicherort der assetlinks.json-Datei** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | 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.** ### 7.3 Beispiel 3: Relying Party ist die Root-Domain und CNAME ist gesetzt | Relying Party ID | corbado.com | | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Entitlements (nur iOS)** | webcredentials:corbado.com; webcredentials:auth.corbado.com | | **Speicherort der apple-app-site-association-Datei** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **Speicherort der assetlinks.json-Datei** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | 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.** ### 7.4 Beispiel 4: Relying Party ist eine Subdomain & Wildcard-Entitlement ist gesetzt | Relying Party ID | auth.corbado.com | | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Entitlements (nur iOS)** | webcredentials:\*.corbado.com | | **Speicherort der apple-app-site-association-Datei** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **Speicherort der assetlinks.json-Datei** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | n/a | 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.** ## 8. Häufige Fehler bei der Relying Party ID & wie man sie vermeidet ### 8.1 Änderung der Relying Party ID von Subdomain zu Root-Domain **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](https://publicsuffix.org/learn/). ### 8.2 Verschiedene Relying Party IDs für native und Web-App **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. ### 8.3 Ungültige und nicht erreichbare Assoziationsdateien **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](https://cybernews.com/best-vpn/most-secure-vpns/) oder einer Firewall, die den ordnungsgemäßen Zugriff für die Crawler von Apple und Google verhindert) einer Assoziationsdatei über die für [iOS ](https://branch.io/resources/aasa-validator/)und Android bereitgestellten Tools zu überprüfen. ### 8.4 apple-app-site-association-Datei noch nicht vom Apple CDN gecacht **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`). ### 8.5 Inkompatibilität von Android-Emulator und API-Version **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. ## 9. Empfehlung ### 9.1 Allgemeine Empfehlung 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). | Fall | Empfehlung | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **A) Sie haben eine Root-Domain:**

Beispiel: acme.com

Alle Anwendungen und die Authentifizierung laufen auf dieser Root-Domain oder deren Subdomains | ✔️ Wählen Sie die Root-Domain als Ihre Relying Party ID, da dies keine Probleme für Web- oder native Apps verursacht. | | **B) Sie haben mehrere Root-Domains:**

Beispiel: kayak.com, kayak.co.uk, kayak.de

Sie bedienen Ihre Nutzer von verschiedenen internationalen Top-Level-Domains. Kayak.com für die USA und kayak.co.uk für Großbritannien, oder Sie haben völlig unterschiedliche Root-Domains, die denselben Nutzern den Login mit denselben Passkeys ermöglichen sollen. | ⚠️ Auf Ihren Web-Apps erfordert das Teilen von Passkeys die Konfiguration von Related Origin Requests via `.well-known/webauthn`, um spezifizierten Ursprüngen die Nutzung einer gemeinsamen RP ID zu erlauben (Browser-Unterstützung variiert; Kompatibilität prüfen). Alternativ wählen Sie eine gemeinsame Authentifizierungs-Root-Domain.

✔️ Sie können Ihre nativen Apps mit einer beliebigen Anzahl von Root-Domains verbinden, solange Sie die Kontrolle über die Root-Assoziationsdateien haben.

❌ Falls Sie später zu einer anderen Root-Domain migrieren möchten, um Ihre Website zu hosten, werden Sie Ihre bereits erstellten Passkeys nicht verwenden können, da Sie die Domain (Relying Party ID) ändern und umbenennen müssen. | | **C) Sie haben noch KEINE Root-Domain, Sie laufen nur auf dem Backend oder auf einer öffentlichen Subdomain. Es gibt einige Fälle, in denen dies passieren kann:**

1. Sie arbeiten auf einer frei verfügbaren Subdomain, bei der die Root-Domain nicht unter Ihrer Kontrolle ist (die Root-Domain ist z. B. auf [https://publicsuffix.org/](https://publicsuffix.org/) gelistet), beispielsweise CDN-URLs.

2. Sie arbeiten an einer nativen App. | ❌ Auf öffentlichen Subdomains können Sie die Assoziationsdateien nicht auf der Root-Ebene der Root-Domain kontrollieren. Daher werden Passkeys nicht nativ funktionieren.

⚠️ Die einzige Möglichkeit, dies für einige Dienste zu beheben, besteht darin, in einen kostenpflichtigen Plan zu wechseln, bei dem Sie einen CNAME definieren oder eine benutzerdefinierte Root-Domain für sich selbst erhalten können. | ### 9.2 Empfehlung bei Verwendung von Corbado 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? #### A) Entwicklung 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. ##### A1) Nur nativ (Native-Only) - 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 ##### A2) Native App & Web-App 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) #### B) Produktion 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`). ##### B1) Subdomain als Relying Party ID ###### B1.1) Nur nativ (Native-Only) - 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` ###### B1.2) Native App & Web-App - 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) ##### B2) Root-Domain als Relying Party ID ###### B2.1) Nur nativ (Native-Only) - Setzen Sie Relying Party ID = `acme.com` - Hosten Sie die Assoziationsdatei selbst auf Ihrem eigenen Server unter `acme.com/.well-known/` - Kein DNS ToDo für Sie ###### B2.2) Native App & Web-App - Setzen Sie Relying Party ID = `acme.com` - Hosten Sie die Assoziationsdatei selbst auf Ihrem eigenen Server unter `acme.com/.well-known/` - 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. ## 10. Fazit 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](https://www.corbado.com/blog/flutter-passkeys-package) zu lesen. Wenn Sie weitere Fragen haben oder Unterstützung benötigen, zögern Sie nicht, [uns zu kontaktieren](https://bit.ly/passkeys-community). ## Häufig gestellte Fragen ### Wie verhindert die Relying Party ID Phishing bei der Passkey-Authentifizierung? Der [Authenticator](https://www.corbado.com/glossary/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. ### Was passiert, wenn ich meine WebAuthn Relying Party ID ändere, nachdem Benutzer bereits Passkeys registriert haben? 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. ### Warum funktioniert mein iOS-Passkey nicht sofort, nachdem ich die apple-app-site-association-Datei bereitgestellt habe? 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. ### Sollte ich eine Subdomain oder eine Root-Domain als meine Relying Party ID für Passkeys verwenden? 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.