--- url: 'https://www.corbado.com/fr/blog/webauthn-relying-party-id-rpid-passkeys' title: 'WebAuthn Relying Party ID (rpID) et clés d''accès : Domaines et applications natives' description: 'Cet article explique le Relying Party ID WebAuthn pour l''authentification par clé d''accès. Il décrit la configuration, la correspondance des domaines et la configuration des applications natives.' lang: 'fr' author: 'Vincent Delitz' date: '2026-06-15T13:55:12.314Z' lastModified: '2026-06-17T06:04:20.679Z' keywords: 'relying party id, webauthn, clés d''accès, applications natives, sécurité, authentification, domaines' category: 'WebAuthn Know-How' --- # WebAuthn Relying Party ID (rpID) et clés d'accès : Domaines et applications natives ## Key Facts - Le **Relying Party ID** est un domaine intégré dans chaque clé d'accès. L'authentification échoue si l'origine du navigateur ne correspond pas, ce qui rend les clés d'accès fortement résistantes au hameçonnage. - Le **RP ID** ne doit pas figurer sur la **Public Suffix List** (liste des suffixes publics) et sa modification invalide toutes les clés d'accès existantes. Utilisez le domaine racine par défaut pour pérenniser votre système. - Les applications iOS nécessitent un fichier **apple-app-site-association** à `/.well-known/` sous le RP ID. Android nécessite **assetlinks.json** au même chemin. La mise en cache des nouveaux fichiers peut prendre jusqu'à 24 heures. - Les domaines racines multiples nécessitent des **Related Origin Requests** via `.well-known/webauthn` pour le partage des clés d'accès. Utilisez un seul serveur WebAuthn avec un seul RP ID pour toutes les applications, web et natives. ## 1. Introduction L'[authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) par [clé d'accès](https://www.corbado.com/fr/blog/webauthn-transports-internes-hybrides) devient rapidement la norme, car des géants de la technologie tels que [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) et Amazon la déploient ou l'ont déjà fait. Il est évident que le monde de la technologie reconnaît l'importance d'une [authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) simple et sécurisée. Au-delà de l'expérience utilisateur fluide qu'offre l'[authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) avec [Face ID](https://www.corbado.com/faq/is-face-id-passkey), Touch ID ou [Windows Hello](https://www.corbado.com/glossary/windows-hello), les [clés d'accès](https://www.corbado.com/fr/glossary/cda) offrent une sécurité inégalée par rapport aux méthodes d'authentification traditionnelles telles que les mots de passe. L'une de leurs caractéristiques les plus remarquables est leur forte résistance au hameçonnage. Une attaque par hameçonnage (phishing) est une attaque où la victime est trompée pour fournir des identifiants à un faux site qui prétend être le site original. Par exemple, imaginez recevoir un e-mail qui semble provenir de votre banque, vous demandant de vous connecter. Vous cliquez sur le lien, et le site web semble légitime, donc vous saisissez vos identifiants et l'attaquant peut les utiliser pour se connecter au site original. Cela devient un problème de plus en plus croissant à l'ère numérique et même des [entreprises](https://www.corbado.com/fr/blog/violations-donnees-japon) majeures comme [Okta ](https://www.darkreading.com/application-security/okta-flaw-involved-mgm-resorts-breach-attackers-claim)(un fournisseur d'authentification !) ou [Retool ](https://retool.com/blog/mfa-isnt-mfa/)ont été victimes d'attaques de harponnage (spear-[phishing](https://www.corbado.com/glossary/phishing), une forme spéciale de hameçonnage où des victimes uniques sont particulièrement ciblées avec des astuces de hameçonnage très personnelles), soulignant le besoin de mesures de sécurité robustes. À l'inverse, si vous utilisez une [clé d'accès](https://www.corbado.com/fr/blog/webauthn-transports-internes-hybrides), et que le site est un faux, votre authentification échouera. C'est parce que les [clés d'accès](https://www.corbado.com/fr/glossary/cda) sont liées aux domaines pour lesquels elles ont été créées via le **Relying Party ID**. > Vous ne pouvez pas vous connecter avec une > [clé d'accès](https://www.corbado.com/fr/blog/webauthn-transports-internes-hybrides) sur un autre site, ce qui > rend les [clés d'accès](https://www.corbado.com/fr/glossary/cda) fortement résistantes au hameçonnage (bien > qu'aucun système ne soit absolument immunisé contre tous les vecteurs d'attaque). Ce mécanisme est intégré dans WebAuthn, la norme web sous-jacente aux clés d'accès pour l'[authentification sans mot de passe](https://www.corbado.com/fr/blog/pourquoi-implementations-cles-acces-echouent). WebAuthn repose sur deux cérémonies principales : la cérémonie d'enregistrement et la cérémonie d'authentification. Pendant la cérémonie d'enregistrement (inscription), une nouvelle clé d'accès est créée pour un service en ligne (le [Relying Party](https://www.corbado.com/glossary/relying-party)) via une [application web](https://www.corbado.com/fr/blog/application-crud-react-nodejs-express-mysql) ou native. Dans ce processus, le domaine (Relying Party ID) pour lequel la clé d'accès est créée est stocké dans la clé d'accès. Cela permet à la cérémonie d'authentification (connexion) de vérifier si le service en ligne (le [Relying Party](https://www.corbado.com/glossary/relying-party)), auquel appartient l'[application web](https://www.corbado.com/fr/blog/application-crud-react-nodejs-express-mysql) ou native, correspond au [Relying Party](https://www.corbado.com/glossary/relying-party) ID stocké dans la clé d'accès. Dans ce qui suit, nous verrons en détail comment ce processus de [correspondance de domaine](#what-relying-party-id) fonctionne et comment, en particulier, les applications natives sont sécurisées. ## 2. Qu'est-ce que le Relying Party ID ? Le [**Relying Party ID**](https://www.w3.org/TR/webauthn-2/#relying-party-identifier) est essentiellement un domaine stocké au sein de la clé d'accès, garantissant que la clé d'accès ne fonctionne que si l'URL du navigateur actuel (l'origine de l'utilisateur qui est automatiquement envoyée à chaque requête) lui correspond (voir l'approche de l'[application native](https://www.corbado.com/fr/blog/applications-natives-passkeys) [ci-dessous](#integration-options-native-apps)). C'est un composant crucial de la spécification WebAuthn, que vous pouvez approfondir [ici](https://www.w3.org/TR/webauthn-2/). Le Relying Party ID peut être le domaine racine (par ex. `corbado.com`) ou un sous-domaine (`auth.corbado.com`). Vous ne pouvez pas stocker le domaine racine comme Relying Party ID s'il figure sur la liste des suffixes publics (trouvez la liste et les bibliothèques pour la [détection](https://www.corbado.com/fr/blog/le-role-de-lia-dans-la-detection-des-cybermenaces) des suffixes publics [ici](https://publicsuffix.org/learn/)). Changer le Relying Party ID pour un service en ligne brisera les clés d'accès existantes (exceptions : le nouveau Relying Party ID est un sous-domaine de l'ancien Relying Party ID, ou les Related Origin Requests sont configurées via `.well-known/webauthn` pour permettre la réutilisation des clés d'accès entre des domaines apparentés). Pendant le processus d'authentification, le Relying Party ID est vérifié par rapport à l'URL du navigateur (l'origine de l'utilisateur) pour s'assurer qu'ils correspondent. La correspondance dans ce sens signifie que soit : - L'URL du navigateur (origine de l'utilisateur) correspond précisément au Relying Party ID OU - L'URL du navigateur (origine de l'utilisateur) est un sous-domaine qui correspond au Relying Party ID et le domaine parent est enregistrable (par ex. `com` ou n'importe quel domaine de la Public Suffix List ne fonctionnent pas) Voici une présentation détaillée indiquant quel _originalHost_ (deuxième colonne) est autorisé à accéder à son domaine parent : ![tableau du relying party id](https://www.corbado.com/website-assets/relying_party_id_table_4c98cc04f4.jpg) Dans ce qui suit, vous voyez les [**PublicKeyCredentialCreationOptions**](https://www.w3.org/TR/webauthn-2/#iface-pkcredential) analysées : ```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` signifie Relying Party. L'un des principaux avantages du Relying Party ID est la prévention des attaques par hameçonnage. Imaginez le scénario suivant : 1. Un attaquant développe un clone de [PayPal](https://www.corbado.com/blog/paypal-passkeys) qui est un faux site web tentant de voler vos identifiants [PayPal](https://www.corbado.com/blog/paypal-passkeys) pour se connecter en votre nom et envoyer de l'argent sur le compte de l'attaquant. Ce faux site web [PayPal](https://www.corbado.com/blog/paypal-passkeys) est hébergé sur le domaine paybal.com (il n'est donc souvent pas visible qu'il s'agit d'un domaine différent au premier coup d'œil). 2. Vous avez déjà créé une clé d'accès dans le passé pour le site légitime de PayPal. Cette clé d'accès a stocké le Relying Party ID paypal.com. 3. Vous visitez le faux site web de PayPal à l'adresse paybal.com (lorsque vous visitez ce site, l'origine de votre requête est paybal.com\*) et le site envoie à votre appareil (l'authentificateur) un challenge pour le Relying Party ID `paypal.com` (ici, il essaie de vous tromper) et vous demande de le signer avec votre clé d'accès pour le Relying Party ID paypal.com. 4. Votre appareil (l'authentificateur) vérifie si l'origine de la requête (`paybal.com`) et le Relying Party ID qu'il a stocké dans la clé d'accès (`paypal.com`) correspondent. 5. Comme ils ne correspondent évidemment pas, l'authentification échoue et cela vous évite de donner à un attaquant l'accès à votre compte PayPal. Le diagramme suivant illustre ce mécanisme de prévention du hameçonnage. _Dans le cas d'une application native, la gestion de l'origine diffère selon la plateforme : Sur Android, l'origine est formatée comme `android:apk-key-hash:`. Sur iOS, l'origine WebAuthn est l'origine web du RP (par ex., `https://paypal.com`). Dans les deux cas, la confiance entre votre application native et le serveur est vérifiée via le fichier d'association correspondant (voir [ci-dessous](#configuring-relying-party-native-apps)). Pour des informations détaillées sur le fonctionnement de la validation d'origine pour les applications natives, consultez notre guide dédié sur la validation d'origine WebAuthn pour les applications natives._ ## 3. Les deux différentes options d'intégration pour les applications natives Pour implémenter les clés d'accès dans une [application native](https://www.corbado.com/fr/blog/applications-natives-passkeys), un développeur peut décider de les ajouter via une [WebView](https://www.corbado.com/blog/native-app-passkeys) ou nativement. Examinons les avantages et inconvénients des deux approches dans la suite. ### 3.1 Intégration de clé d'accès via WebView ![Intégration de clé d'accès WebView (GitHub)](https://www.corbado.com/website-assets/650c601b1eb462e25702a870_android_webview_passkey_github_8bc81d9852.jpg) L'utilisation d'une **WebView**\* pour intégrer les clés d'accès signifie intégrer un navigateur web au sein de l'application native pour gérer le processus d'authentification. Cette approche affiche essentiellement une page web à l'intérieur de l'application, ce qui facilite la réutilisation des flux d'authentification basés sur le web sans avoir à les réécrire pour la plateforme native. Cependant, il y a quelques inconvénients. Les WebViews peuvent ne pas prendre en charge toutes les fonctionnalités des clés d'accès, et il y a un risque potentiel d'attaques de l'homme du milieu (man-in-the-middle) s'il n'est pas implémenté de manière sécurisée. De plus, l'expérience utilisateur peut ne pas être aussi fluide qu'avec des intégrations natives, et il peut y avoir des défis pour maintenir un comportement cohérent sur différents appareils et versions d'OS. _\*Il existe plusieurs types de_ _WebViews_ \_ : Sur [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) (WKWebView, [SFSafariViewController](https://www.corbado.com/blog/native-app-passkeys) ou [SFAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) / [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) pour les flux d'authentification basés sur OAuth/OpenID Connect) et [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) (WebView, [CCT](https://www.corbado.com/blog/native-app-passkeys)-Chrome Custom Tabs). Consultez cet article de blog pour plus de détails. Nous recommandons d'utiliser [SFSafariViewController](https://www.corbado.com/blog/native-app-passkeys)/ [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) et Chrome Custom Tabs dans le contexte des clés d'accès si vous ne voulez pas d'une intégration native.\_ ### 3.2 Intégration native de clé d'accès ![Intégration native de clé d'accès (Kayak)](https://www.corbado.com/website-assets/650c625cac723f594137a029_android_native_passkey_kayak_0f689e761e.jpg) **L'intégration native** implique de construire la fonctionnalité de clé d'accès directement dans l'application [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) ou [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) en utilisant les API et bibliothèques spécifiques à la plateforme. Cette méthode offre une expérience utilisateur plus fluide, car il n'y a pas besoin de transition entre l'[application native](https://www.corbado.com/fr/blog/applications-natives-passkeys) et une [WebView](https://www.corbado.com/blog/native-app-passkeys). Cela permet également de meilleures performances et une apparence plus cohérente. D'un point de [vue](https://www.corbado.com/blog/vuejs-passkeys) de la sécurité, l'intégration native peut offrir une protection renforcée contre certains types d'attaques, en particulier lorsqu'elle est combinée avec des fonctionnalités de sécurité spécifiques à la plateforme. Cependant, l'effort d'implémentation peut être plus élevé, car les développeurs doivent écrire et maintenir un code séparé pour chaque plateforme (Android et [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)). De plus, rester à jour avec les dernières spécifications des clés d'accès / WebAuthn peut nécessiter des mises à jour d'application plus fréquentes. Dans ce qui suit, nous nous concentrons sur l'intégration native de la clé d'accès. ## 4. Configuration du Relying Party pour les applications natives Les applications natives (par ex. les applications iOS ou [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) présentent un défi par rapport aux applications web. Contrairement aux applications web, il n'y a pas d'URL de navigateur à comparer au Relying Party ID. Néanmoins, pour assurer le même niveau de sécurité, les domaines sont connectés aux applications natives via des **fichiers d'association**, de sorte qu'une confiance entre un domaine et une application native soit établie. C'est particulièrement important si une clé d'accès a été créée sur une [application web](https://www.corbado.com/fr/blog/application-crud-react-nodejs-express-mysql) et devrait être utilisée pour le même Relying Party ID sur une application native (et vice versa). ### 4.1 Fichiers d'association sur iOS : apple-app-site-association iOS utilise le fichier apple-app-site-association. Ce fichier contient divers droits (entitlements), mais pour WebAuthn et les clés d'accès, le droit webcredentials est important. ```json { "webcredentials": { "apps": ["9RF9KY88B2.com.corbado.passkeys"] } } ``` Dans webcredentials.apps, vous devez stocker votre préfixe d'identifiant d'application (Application Identifier Prefix, par ex. `9RF9KY77B2`) et votre identifiant de bundle (Bundle Identifier, par ex. `com.corbado.passkeys`). Pour que les applications natives iOS fonctionnent, le fichier apple-app-site-association doit être stocké dans le répertoire `/.well-known` du Relying Party ID (`https:///.well-known/apple-app-site-association`). Voir un exemple en direct [ici](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/apple-app-site-association). ### 4.2 Fichiers d'association sur Android : assetlinks.json Android utilise le fichier `assetlinks.json`, qui, comme son homologue iOS, nécessite des configurations particulières pour WebAuthn et les clés d'accès. ```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" ] } } ] ``` Vous devez avoir défini les valeurs de relation `delegate_permission/common.handle_all_urls` et `delegate_permission/common.get_login_creds`. De plus, vous devez ajouter le nom de votre package et l'empreinte SHA-256 de votre certificat de signature. Pour permettre le partage d'une clé d'accès entre une application native et une application web, vous devez ajouter deux entrées. Une pour le namespace web et une pour le namespace android_app. Voir un exemple en direct [ici](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/assetlinks.json). Pour que les applications Android fonctionnent, le fichier assetlinks.json doit être stocké sous le répertoire `/.well-known` du Relying Party ID `https:///.well-known/assetlinks.json` - donc presque comme sur iOS). Consultez cet article de blog pour voir un exemple d'implémentation qui partage des clés d'accès entre une [application native Android](https://www.corbado.com/fr/blog/applications-natives-passkeys) / iOS et une application web. ## 5. Établir la confiance entre une application native et une application web ### 5.1 iOS Le processus pour établir la confiance entre une application iOS et une application web se déroule comme suit : 1. Le développeur de l'application iOS doit spécifier une liste de domaines qu'il souhaite associer à l'application native. Ces domaines sont codés en dur dans les droits (entitlements) des applications iOS, par ex. : - webcredentials:auth.Corbado.com - webcredentials:\*.Corbado.com 2. Chaque fois que l'application iOS est installée ou mise à jour, iOS téléchargera le fichier apple-app-site-association pour chaque entrée de la liste de droits des applications iOS. 3. Lorsqu'un identifiant (par ex. une clé d'accès) est créé dans une application iOS, l'application iOS valide si le domaine du serveur Relying Party est associé à l'application iOS en vérifiant les deux aspects suivants : - Y a-t-il un fichier `apple-app-site-association` pour ce domaine de serveur Relying Party existant sur l'appareil ? - L'application iOS est-elle listée dans ce fichier `apple-app-site-association` ? Si, et seulement si, la réponse aux deux questions est oui, une clé d'accès peut être créée dans l'application iOS. ### 5.2 Android Le processus pour établir la confiance entre une application Android et une application web se déroule comme suit : 1. Le développeur de l'application Android doit spécifier une liste de domaines qu'il souhaite associer à l'application Android. Ces domaines sont stockés comme cibles avec le namespace web dans le fichier assetlinks.json. Pour déclarer que les applications Android et les applications web partagent des identifiants, `delegate_permission/common.get_login_creds` doit être spécifié. Trouvez des détails [ici](https://developer.android.com/training/sign-in/passkeys#add-support-dal). 2. Si une clé d'accès est créée au sein de l'application Android, l'application Android valide si le Relying Party ID est associé à l'application Android en vérifiant `assetlinks.json` : - Y a-t-il un fichier `assetlinks.json` pour ce Relying Party ID à l'adresse `https://./well-known/assetlinks.json` - L'application Android est-elle correctement définie en tant que cible. 3. Si, et seulement si, la réponse aux deux questions est oui, une clé d'accès peut être créée au sein de l'application Android. Le diagramme ci-dessous compare ces processus d'établissement de la confiance côte à côte. ## 6. Aperçu des paramètres pour Android, iOS et Flutter Dans la suite, nous fournissons un aperçu détaillé des différents paramètres nécessaires pour configurer correctement l'authentification par clé d'accès pour les applications natives. | Fonctionnalité | iOS | Android | | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Directives d'implémentation officielles pour l'authentification native par clé d'accès | Apple Developer | Google Developer | | Permet le partage de clés d'accès avec des applications web | Oui, via le fichier apple-app-site-association | Oui, via assetlinks.json | | Emplacement du fichier d'association | [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) | | Fichier mis en cache | Oui (depuis iOS 14), la synchronisation initiale peut prendre jusqu'à 24h | Oui (par Play Services) | | Contournement possible | Oui, avec la section mode alternatif | Non | | Testable avec | test apple-app-site-association | test assetlinks.json | | Identifiant de l'application avec exemple | `.`, par ex. `T84QZS65DQ.com.facebook.Messenger` | Empreinte SHA256, par ex. `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` | | Où trouver l'identifiant de l'application | Le Team Application Identifier Prefix peut être trouvé dans le compte développeur sur developer.apple.com et le Bundle Identifier est le nom exact depuis le projet XCode | Une fois téléchargé : Google Play Console > Release management > App signing Local : `keytool -list -v -keystore -alias -storepass -keypass ` | | Nom de la section qui lie l'application au web | applinks (non requis pour les clés d'accès) | `delegate_permission/common.handle_all_urls` (requis pour les clés d'accès) | | Nom de la section qui permet le partage d'identifiants entre l'application et le web | webcredentials | `delegate_permission/common.get_login_creds` | | Registre de tous les fichiers d'association | Activer et ajouter le domaine associé dans l'environnement de développement XCode (paramétrage de la propriété pour générer le fichier des droits) | Lors de l'utilisation de la Credential Manager API, le registre de l'assetlinks.json dans le manifeste n'est pas requis pour les clés d'accès (il l'est cependant pour les mots de passe). Sans la Credential Manager API, vous devez lister les noms d'hôtes avec l'entrée `` dans AndroidManifest.xml dans l'activité spécifique (faisant partie du code source de l'application Android). Le `` doit avoir autoVerify=true. | Pour [Flutter](https://www.corbado.com/blog/flutter-passkeys-package), la règle respective d'Android ou iOS s'applique. Le seul paramètre spécifique à [Flutter](https://www.corbado.com/blog/flutter-passkeys-package) est le registre des fichiers d'association, où vous devez ajouter : - Pour Android : [flutter_deeplinking_enabled dans AndroidManifest.xml](https://docs.flutter.dev/cookbook/navigation/set-up-app-links) - Pour iOS : [FlutterDeepLinkingEnabled true dans Info.plist](https://docs.flutter.dev/cookbook/navigation/set-up-universal-links) ## 7. Exemples de Relying Party ID et fichiers d'association valides et invalides Comme nous l'avons expérimenté nous-mêmes, travailler avec des Relying Party IDs, différents niveaux de (sous-)domaines et des CNAME peut être une tâche assez difficile, nous présentons quatre exemples distincts et expliquons pourquoi et comment ils fonctionnent. Notez que la ligne du tableau CNAME n'est pas requise pour l'authentification par clé d'accès et n'est que le résultat de nos recherches que nous voulions ajouter. ### 7.1 Exemple 1 : Le Relying Party est le domaine racine | **Relying Party ID** | corbado.com | | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Droits (iOS uniquement)** | webcredentials:corbado.com | | **Emplacement du fichier apple-app-site-association** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **Emplacement du fichier assetlinks.json** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | n/a | Dans cet exemple, le fichier `apple-app-site-association` / `assetlinks.json` pour Corbado.com peut être téléchargé sans aucun problème lorsque l'application native est installée / mise à jour, car le fichier se trouve au même emplacement que le Relying Party ID. **Une clé d'accès pour le Relying Party ID peut être créée.** ### 7.2 Exemple 2 : Le Relying Party est un sous-domaine et le CNAME est défini | Relying Party ID | auth.corbado.com | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Droits (iOS uniquement)** | webcredentials:auth.corbado.com | | **Emplacement du fichier apple-app-site-association** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **Emplacement du fichier assetlinks.json** | [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 | Dans cet exemple, le fichier `apple-app-site-association` / `assetlinks.json` pour auth.corbado.com peut être téléchargé sans aucun problème lorsque l'application native est installée / mise à jour, car le fichier se trouve à l'emplacement du Relying Party ID, étant donné que le CNAME pointe depuis le Relying Party ID vers l'emplacement de stockage. **Une clé d'accès pour le Relying Party ID peut être créée.** ### 7.3 Exemple 3 : Le Relying Party est le domaine racine et le CNAME est défini | Relying Party ID | corbado.com | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Droits (iOS uniquement)** | webcredentials:corbado.com; webcredentials:auth.corbado.com | | **Emplacement du fichier apple-app-site-association** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **Emplacement du fichier assetlinks.json** | [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 | Dans cet exemple, le fichier `apple-app-site-association` / `assetlinks.json` pour auth.corbado.com peut être téléchargé sans aucun problème lorsque l'application native est installée / mise à jour, car le fichier est, grâce au CNAME, à l'emplacement où `auth.corbado.com` l'attend. MAIS : Le fichier `apple-site-association-file` / `assetlinks.json` pour corbado.com ne peut pas être téléchargé lors de l'installation / la mise à jour de l'application native, car le fichier n'est pas à `https://corbado.com/.well-known/apple-app-site-association` / `https://corbado.com/.well-known/assetlinks.json`, où il est attendu, et aucun CNAME n'y pointe. **Une clé d'accès pour le Relying Party ID ne peut pas être créée.** ### 7.4 Exemple 4 : Le Relying Party est un sous-domaine et le droit Wildcard est défini | Relying Party ID | auth.corbado.com | | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Droits (iOS uniquement)** | webcredentials:\*.corbado.com | | **Emplacement du fichier apple-app-site-association** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **Emplacement du fichier assetlinks.json** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | n/a | Dans cet exemple, le fichier `apple-app-site-association` pour corbado.com peut être téléchargé sans aucun problème lors de l'installation / la mise à jour de l'application native, car le fichier est là où il est attendu et le droit webcredentials (`*.corbado.com`) correspond au Relying Party ID (`auth.corbado.com`). Notez que cet exemple ne fonctionne pas pour Android, car Android ne fonctionne pas avec quelque chose comme des droits (wildcard). En général, cette façon de définir les Relying Party IDs n'est pas recommandée. **Une clé d'accès pour le Relying Party ID peut être créée.** ## 8. Erreurs courantes du Relying Party ID et comment les éviter ### 8.1 Changer le Relying Party ID d'un sous-domaine vers le domaine racine **Erreur :** Vous avez commencé à développer et défini un sous-domaine (par ex. `login.acme.com`) comme votre Relying Party ID. Les premiers utilisateurs ont créé une clé d'accès pour ce Relying Party ID. Ensuite, vous remarquez que vous avez également besoin de ces clés d'accès pour l'authentification sur un autre sous-domaine (par ex. `app.acme.com`). Comme l'origine d'un utilisateur et le Relying Party ID pour le nouveau sous-domaine ne correspondent pas, l'utilisateur ne peut pas se connecter avec la clé d'accès. Modifier le Relying Party ID dans vos paramètres WebAuthn vers `acme.com` invaliderait toutes les clés d'accès existantes, car la nouvelle origine et le Relying Party ID stocké dans les clés d'accès existantes ne correspondent pas. **Solution :** Vérifiez deux fois initialement lors de la définition de votre Relying Party ID car c'est plus ou moins définitif. Si vous n'êtes pas sûr et souhaitez être prêt pour l'avenir, ce qui signifie que d'autres sous-domaines à l'avenir pourraient avoir besoin de la clé d'accès pour l'authentification, nous vous recommandons d'utiliser le domaine racine (par ex. acme.com) comme Relying Party ID sauf s'il figure sur la [Public Suffix List](https://publicsuffix.org/learn/). ### 8.2 Différents Relying Party IDs pour l'application native et web **Erreur :** Vous développez une application native et web simultanément. Pour accélérer les choses, vous utilisez deux serveurs WebAuthn différents (avec des Relying Party IDs différents pour l'application native et web). Lorsque vos utilisateurs créent les premières clés d'accès, le Relying Party ID respectif est stocké dans la clé d'accès. Permettre la [connexion](https://www.corbado.com/fr/faq/connexion-second-appareil-cle-acces-liee) multi-appareils / multi-plateformes avec la même clé d'accès, par ex. avec une clé d'accès créée dans une application web et en essayant de se connecter dans une application native, n'est plus possible. Fusionner les deux serveurs WebAuthn abandonnera les clés d'accès qui ont été enregistrées avec l'ancien serveur WebAuthn (ancien Relying Party ID) et vos utilisateurs ne pourront pas se connecter avec ces clés d'accès. **Solution :** Si vous avez plusieurs applications (par ex. une application web et une application native), ayez toujours un seul serveur WebAuthn et définissez un seul Relying Party ID pour toutes vos applications. La liaison entre ces applications peut se faire via les étapes décrites ci-dessus. ### 8.3 Fichiers d'association invalides et inaccessibles **Erreur :** Vous commencez à développer votre application, configurez les fichiers d'association et les déployez sur votre serveur. Pour une raison quelconque, vous obtenez toujours des messages d'erreur et ne trouvez pas la cause première. **Solution :** Une cause potentielle du message d'erreur pourrait être un fichier d'association malformé ou inaccessible. Avant de déployer tout fichier d'association sur un serveur, nous recommandons fortement de vérifier la validité et l'accessibilité (souvent ces fichiers peuvent être derrière [un VPN robuste](https://cybernews.com/best-vpn/most-secure-vpns/) ou un pare-feu qui empêche le bon accès pour les robots de recherche d'Apple et Google) d'un fichier d'association via les outils fournis pour [iOS ](https://branch.io/resources/aasa-validator/)et Android. ### 8.4 Fichier apple-app-site-association non encore mis en cache par le CDN d'Apple **Erreur :** Vous avez déployé votre fichier apple-app-site-association sur votre serveur et souhaitez commencer immédiatement à [créer une clé d'accès](https://www.corbado.com/fr/blog/meilleures-pratiques-creation-passkey) sur votre appareil de test. Pour une raison quelconque, vous ne pouvez pas créer la clé d'accès et obtenez des messages d'erreur. **Solution :** La raison de ces messages d'erreur est que les appareils iOS téléchargent le fichier `apple-app-site-association` pour valider le Relying Party. Pour ce faire, les appareils iOS ne n'envoient pas de requête directe à votre serveur mais utilisent un CDN à la place. L'appareil et le CDN mettent en cache le fichier `apple-app-site-association` une fois qu'il a été récupéré avec succès. En raison de cette fonctionnalité de mise en cache, les nouvelles modifications de votre fichier `apple-app-site-association` ne sont pas directement reflétées dans votre application. Cela peut prendre jusqu'à 24 heures jusqu'à ce que le CDN mette en cache le fichier `apple-app-site-association`. Pour contourner cette restriction pendant le développement, vous pouvez ajouter `?mode=developer` au Relying Party ID et désactiver complètement la mise en cache (par ex. le Relying Party ID serait `acme.com?mode=developer`). ### 8.5 Incompatibilité de la version de l'API et de l'émulateur Android **Erreur :** Vous commencez à développer une application Android et souhaitez la tester sur un émulateur Android. Pour certaines, raisons vous obtenez des messages d'erreur, même si vous avez configuré l'émulateur Android correctement et que d'autres applications semblent y fonctionner de manière fluide. **Solution :** Les versions d'Android, le support du Play Store et les versions de l'API jouent un rôle majeur lors du test d'une application de clés d'accès. Par ailleurs, vous devez être connecté à un compte Google. Veuillez vous référer à notre section de dépannage pour plus de détails. ## 9. Recommandation ### 9.1 Recommandation générale Notre recommandation globale est de choisir votre Relying Party ID avec soin en fonction de votre paysage applicatif et de vos exigences. Ci-dessous, nous avons rassemblé les cas d'utilisation les plus courants, mais notre recommandation générale est que vous devriez **viser à choisir votre domaine racine comme votre Relying Party ID** et configurer votre authentification de cette façon. Avec Corbado, nous avons également déjà préconfiguré de cette manière pour vous (car cela fait partie de notre approche visant à offrir une authentification transparente par clé d'accès pour toutes les configurations techniques. Nos composants d'interface utilisateur et nos SDK sont préparés pour être utilisés avec votre domaine racine comme Relying Party ID). | Cas | Recommandation | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **A) Vous avez un domaine racine :**

Exemple : acme.com

Toutes les applications et l'authentification s'exécutent sur ce domaine racine ou ses sous-domaines | ✔️ Choisissez le domaine racine comme votre Relying Party ID car cela ne posera aucun problème pour les applications web ou natives. | | **B) Vous avez plusieurs domaines racines :**

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

Vous servez vos utilisateurs à partir de différents domaines de premier niveau internationaux. Kayak.com pour les États-Unis et kayak.co.uk pour le Royaume-Uni, ou vous avez des domaines racines complètement différents qui devraient permettre aux mêmes utilisateurs de se connecter avec les mêmes clés d'accès. | ⚠️ Sur vos applications web, le partage des clés d'accès nécessite la configuration de Related Origin Requests via `.well-known/webauthn` pour autoriser des origines spécifiées à utiliser un RP ID commun (la prise en charge des navigateurs varie ; vérifiez la compatibilité). Alternativement, choisissez un domaine racine d'authentification commun.

✔️ Vous pouvez connecter vos applications natives à n'importe quel nombre de domaines racines tant que vous avez le contrôle sur les fichiers d'association racines.

❌ Au cas où vous voudriez plus tard migrer vers un autre domaine racine pour héberger votre site web, vous ne pourrez pas utiliser vos clés d'accès déjà créées, car vous devrez changer de marque et de domaine (Relying Party ID). | | **C) Vous N'AVEZ PAS encore de domaine racine, vous exécutez uniquement sur le backend ou sur un sous-domaine public. Il y a quelques cas où cela pourrait se produire :**

1. Vous travaillez sur un sous-domaine librement disponible, où le domaine racine n'est pas sous votre contrôle (le domaine racine est listé dans le [https://publicsuffix.org/](https://publicsuffix.org/)) par exemple les URL de CDN

2. Vous travaillez sur une application native. | ❌ Sur les sous-domaines publics, vous ne pouvez pas contrôler les fichiers d'association au niveau racine du domaine racine. Par conséquent, les clés d'accès ne fonctionneront pas nativement.

⚠️ La seule façon de résoudre ce problème pour certains services est de passer à un plan payant, où vous pouvez définir un CNAME ou obtenir un domaine racine personnalisé pour vous-même. | ### 9.2 Recommandation lors de l'utilisation de Corbado Dans ce qui suit, nous fournissons un arbre de décision très spécifique qui devrait vous aider à déterminer le bon Relying Party ID et comment vous devriez gérer / héberger les fichiers d'association lorsque vous utilisez Corbado comme votre solution de clé d'accès. La première décision est de savoir si vous êtes dans un environnement de développement ou de production. Le niveau suivant de décision que vous devez prendre est basé sur votre paysage applicatif : n'avez-vous qu'une application native ou une application native et une application web. #### A) Développement Pour l'environnement de développement, nous supposons que vous souhaitez commencer rapidement à développer et à tester. Le Relying Party ID peut être modifié ultérieurement si vous souhaitez passer en production. ##### A1) Natif uniquement - Définir Relying Party ID = `pro-XXX.frontendapi.cloud.corbado.io` (valeur par défaut) - Corbado héberge le fichier d'association pour vous - Aucune tâche DNS à effectuer pour vous ##### A2) Application native et application web Il n'est pas facile de tester à la fois l'application web et l'application native en même temps **Option 1 :** Soit vous définissez Relying Party ID = `pro-XXX.frontendapi.cloud.corbado.io` (l'application native fonctionne), SOIT vous définissez Relying Party ID = `localhost` (l'application web fonctionne) **Option 2 :** La seule solution pour que l'application native et l'application web fonctionnent en même temps est d'utiliser un reverse proxy local (c'est une solution plutôt bricolée) : - Définir Relying Party ID = `acme-dev.com` - Définir un CNAME de `acme-dev.com` => `pro-XXX.frontendapi.cloud.corbado.io` - Ajouter l'entrée locale `/etc/hosts` `localhost acme-dev.com` - Ajouter un reverse proxy (nginx) avec la règle pour `acme-dev.com` => `localhost:3000` (à titre d'exemple) #### B) Production Dans l'environnement de production, vous devez décider si un sous-domaine comme Relying Party ID vous convient (par ex. `auth.acme.com`) ou si vous voulez un domaine racine comme Relying Party ID (par ex. `acme.com`) ##### B1) Sous-domaine comme Relying Party ID ###### B1.1) Natif uniquement - Définir Relying Party ID = `auth.acme.com` - Corbado héberge le fichier d'association pour vous - Définir un CNAME de `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` ###### B1.2) Application native et application web - Définir Relying Party ID = `auth.acme.com` - Corbado héberge le fichier d'association pour vous - Définir un CNAME de `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` (également nécessaire pour que les cookies fonctionnent si vous utilisez la gestion de session de Corbado) ##### B2) Domaine racine comme Relying Party ID ###### B2.1) Natif uniquement - Définir Relying Party ID = `acme.com` - Hébergez vous-même le fichier d'association sur votre propre serveur à l'adresse `acme.com/.well-known/` - Aucune tâche DNS à effectuer pour vous ###### B2.2) Application native et application web - Définir Relying Party ID = `acme.com` - Hébergez vous-même le fichier d'association sur votre propre serveur à l'adresse `acme.com/.well-known/` - Si vous utilisez la gestion de session de Corbado, vous devez définir un CNAME de `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` pour faire fonctionner les cookies (ce CNAME n'est pas nécessaire pour le Relying Party ID uniquement pour la gestion de session) L'arbre de décision suivant résume tous les chemins de configuration. ## 10. Conclusion Le Relying Party ID est une pierre angulaire de WebAuthn et de l'authentification basée sur les clés d'accès et fournit une forte résistance au hameçonnage. Le configurer correctement, comprendre les subtilités de la correspondance de domaine et assurer un déploiement correct pour les applications natives est crucial. Cet article de blog vous a montré comment les configurer correctement et comment gérer les différentes erreurs. Une fois votre configuration rpID solide, concentrez-vous sur l'optimisation de vos flux de création de clés d'accès et flux de [connexion par clé d'accès](https://www.corbado.com/fr/blog/meilleures-pratiques-connexion-passkey) pour favoriser une véritable adoption. Pour d'autres informations sur la configuration des clés d'accès pour l'application native, nous vous recommandons de lire à propos des clés d'accès dans [Flutter](https://www.corbado.com/blog/flutter-passkeys-package). Si vous avez d'autres questions ou avez besoin d'aide, n'hésitez pas à [nous contacter](https://bit.ly/passkeys-community). ## Foire aux questions ### Comment le Relying Party ID prévient-il le hameçonnage dans l'authentification par clé d'accès ? L'authentificateur compare l'origine réelle du navigateur avec le Relying Party ID stocké dans la clé d'accès. Si un attaquant héberge un faux site sur un domaine différent, la non-correspondance de l'origine fait échouer automatiquement l'authentification, même si le challenge falsifié revendique un RP ID légitime. Cette liaison signifie qu'une clé d'accès enregistrée sur paypal.com ne peut pas être utilisée sur un domaine ressemblant comme paybal.com. ### Que se passe-t-il si je change mon WebAuthn Relying Party ID après que des utilisateurs ont déjà enregistré des clés d'accès ? La modification du RP ID invalide toutes les clés d'accès existantes car le RP ID stocké dans chaque identifiant ne correspondra plus à la nouvelle valeur. Les seules exceptions sont lorsque le nouveau RP ID est un sous-domaine de l'ancien ou lorsque les Related Origin Requests sont configurées via `.well-known/webauthn`. Choisissez le domaine racine comme RP ID dès le départ pour éviter ce problème irréversible. ### Pourquoi ma clé d'accès iOS ne fonctionne-t-elle pas immédiatement après le déploiement du fichier apple-app-site-association ? iOS ne récupère pas le fichier apple-app-site-association directement depuis votre serveur. Il utilise le CDN d'Apple, ce qui peut prendre jusqu'à 24 heures pour mettre en cache un fichier nouvellement déployé ou mis à jour. Pendant le développement, ajoutez `?mode=developer` au Relying Party ID pour contourner entièrement la mise en cache. ### Dois-je utiliser un sous-domaine ou un domaine racine comme Relying Party ID pour les clés d'accès ? L'utilisation du domaine racine (par ex. acme.com) est recommandée car les clés d'accès créées sur n'importe quel sous-domaine peuvent s'authentifier sur tous les sous-domaines de cette racine. Un RP ID de sous-domaine restreint l'utilisation de la clé d'accès à ce sous-domaine et à ses enfants, ce qui peut briser les flux inter-sous-domaines plus tard. Si vous avez plusieurs domaines racines tels que acme.com et acme.[co](https://www.corbado.com/fr/blog/conformite-cybersecurite).uk, configurez les Related Origin Requests via `.well-known/webauthn` pour permettre la réutilisation des clés d'accès entre eux.