WebAuthn Relying Party ID (rpID) et clés d'accès : Domaines et applications natives

L'authentification par clé d'accès devient rapidement la norme, car des géants de la technologie tels que TikTok, GitHub, WhatsApp, X (Twitter), LinkedIn 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 simple et sécurisée.

Au-delà de l'expérience utilisateur fluide qu'offre l'authentification avec Face ID, Touch ID ou Windows Hello, les clés d'accès 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.

Aide-mémoire Passkeys. Conseils pratiques, modèles de déploiement et KPIs pour les programmes passkeys.

Obtenir l'aide-mémoire

Testez les passkeys dans une démo en direct.

Tester les passkeys

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 majeures comme Okta (un fournisseur d'authentification !) ou Retool ont été victimes d'attaques de harponnage (spear-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, et que le site est un faux, votre authentification échouera. C'est parce que les clés d'accès sont liées aux domaines pour lesquels elles ont été créées via le Relying Party ID.

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. 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) via une application web 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), auquel appartient l'application web ou native, correspond au 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 fonctionne et comment, en particulier, les applications natives sont sécurisées.

Le Relying Party ID 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 ci-dessous). C'est un composant crucial de la spécification WebAuthn, que vous pouvez approfondir ici. 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 des suffixes publics ici). 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 :

Dans ce qui suit, vous voyez les PublicKeyCredentialCreationOptions analysées :

{
    "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 qui est un faux site web tentant de voler vos identifiants PayPal pour se connecter en votre nom et envoyer de l'argent sur le compte de l'attaquant. Ce faux site web PayPal 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:<SHA256_fingerprint>. 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). 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.

Rejoignez notre communauté passkeys pour les mises à jour et le support.

Rejoindre

Pour implémenter les clés d'accès dans une application native, un développeur peut décider de les ajouter via une WebView ou nativement. Examinons les avantages et inconvénients des deux approches dans la suite.

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 (WKWebView, SFSafariViewController ou SFAuthenticationSession / ASWebAuthenticationSession pour les flux d'authentification basés sur OAuth/OpenID Connect) et Android (WebView, CCT-Chrome Custom Tabs). Consultez cet article de blog pour plus de détails. Nous recommandons d'utiliser SFSafariViewController/ ASWebAuthenticationSession et Chrome Custom Tabs dans le contexte des clés d'accès si vous ne voulez pas d'une intégration native._

Découvrez combien de personnes utilisent réellement les passkeys.

Voir les données d'adoption

L'intégration native implique de construire la fonctionnalité de clé d'accès directement dans l'application iOS ou 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 et une WebView. Cela permet également de meilleures performances et une apparence plus cohérente. D'un point de vue 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). 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.

Découvrez combien de personnes utilisent réellement les passkeys.

Voir les données d'adoption

Les applications natives (par ex. les applications iOS ou 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 et devrait être utilisée pour le même Relying Party ID sur une application native (et vice versa).

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.

{
    "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://<Relying Party ID>/.well-known/apple-app-site-association).

Voir un exemple en direct ici.

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.

[
    {
        "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.

Pour que les applications Android fonctionnent, le fichier assetlinks.json doit être stocké sous le répertoire /.well-known du Relying Party ID https://<Relying Party ID>/.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 / iOS et une application web.

Expérimentez les parcours passkey dans le Passkeys Debugger.

Essayer gratuitement

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.

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

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.

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://<Relying Party ID>./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.

Abonnez-vous à notre Substack passkeys pour les dernières actualités.

S'abonner

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.

Pour Flutter, la règle respective d'Android ou iOS s'applique. Le seul paramètre spécifique à Flutter est le registre des fichiers d'association, où vous devez ajouter :

• Pour Android : flutter_deeplinking_enabled dans AndroidManifest.xml
• Pour iOS : FlutterDeepLinkingEnabled true dans Info.plist

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.

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.

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.

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.

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.

Rejoignez notre communauté passkeys pour les mises à jour et le support.

Rejoindre

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.

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 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.

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 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 et Android.

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 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).

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.

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).

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.

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.

• 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

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)

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)

• 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

• 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)

• 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/<association file>
• Aucune tâche DNS à effectuer pour vous

• 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/<association file>
• 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.

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 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.

Si vous avez d'autres questions ou avez besoin d'aide, n'hésitez pas à nous contacter.

À propos de Corbado

Corbado est la Passkey Intelligence Platform pour les équipes CIAM qui gèrent l'authentification client à grande échelle. Nous vous montrons ce que les logs IDP et les outils d'analytics génériques ne voient pas : quels appareils, versions d'OS, navigateurs et gestionnaires de credentials prennent en charge les passkeys, pourquoi les enrôlements ne deviennent pas des connexions, où le flux WebAuthn échoue et quand une mise à jour OS ou navigateur casse silencieusement la connexion — le tout sans remplacer Okta, Auth0, Ping, Cognito ni votre IDP interne. Deux produits : Corbado Observe ajoute l'observabilité pour les passkeys et toute autre méthode de connexion. Corbado Connect apporte des passkeys managés avec analytics intégrés (aux côtés de votre IDP). VicRoads gère les passkeys pour plus de 5M d'utilisateurs avec Corbado (+80 % d'activation passkey). Parler à un expert Passkey →

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.

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.

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.

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.uk, configurez les Related Origin Requests via .well-known/webauthn pour permettre la réutilisation des clés d'accès entre eux.