Origines liées WebAuthn : le guide des passkeys inter-domaines

Les passkeys sont le nouveau standard pour une authentification sécurisée et conviviale. Basés sur les standards FIDO/WebAuthn, ils exploitent la cryptographie à clé publique pour offrir une résistance inhérente au phishing et au bourrage d'identifiants, améliorant considérablement la sécurité tout en simplifiant l'expérience de connexion pour les utilisateurs. Pour les entreprises, cela se traduit par des avantages commerciaux tangibles : réduction des coûts opérationnels liés aux réinitialisations de mots de passe et aux SMS OTP, atténuation des risques financiers liés à la fraude par prise de contrôle de compte, et augmentation des revenus grâce à des taux de conversion plus élevés.

Cependant, l'une des plus grandes forces de sécurité de WebAuthn — sa nature stricte et liée à l'origine — crée un défi de taille dans le monde réel pour les marques mondiales et les entreprises ayant une empreinte numérique diversifiée. Par conception, un passkey créé pour un domaine web spécifique est cryptographiquement verrouillé à ce domaine, un principe fondamental qui empêche les attaques de phishing. Bien que ce soit une fonctionnalité de sécurité puissante, elle entraîne une expérience utilisateur fragmentée et déroutante lorsqu'une seule marque opère sur plusieurs domaines.

Un exemple marquant de ce défi est le changement de nom de Twitter en X. Un utilisateur qui avait créé un passkey sur twitter.com l'aurait trouvé inutilisable sur x.com, forçant l'entreprise à mettre en place des redirections complexes ou à demander aux utilisateurs de se réinscrire, créant ainsi une friction qui freine directement l'adoption. Ce n'est pas un cas isolé. De grandes entreprises comme Amazon opèrent sur de nombreux domaines de premier niveau de code de pays (ccTLD) tels que amazon.com, amazon.de et amazon.co.uk, qui partagent tous un système de compte utilisateur commun. Dans un monde pré-passkey, les gestionnaires de mots de passe gèrent habilement cette complexité, mais le comportement par défaut de WebAuthn exigerait un passkey distinct pour chaque domaine, frustrant les utilisateurs et sapant la promesse d'une connexion fluide.

Pour résoudre ce blocage critique à l'adoption, le W3C a introduit une nouvelle fonctionnalité dans le standard WebAuthn : les Requêtes d'Origines Liées (ROR). Ce mécanisme puissant fournit un moyen standardisé et sécurisé pour un ensemble de domaines de confiance de partager un seul passkey, créant une expérience d'authentification unifiée et transparente à travers tout l'écosystème numérique d'une marque. Cet article explore en profondeur les fondements techniques des ROR, fournit un guide pratique pour leur mise en œuvre et analyse leurs implications stratégiques pour l'architecture d'authentification moderne.

L'introduction des ROR marque une maturation significative du standard WebAuthn. Les spécifications initiales ont priorisé l'établissement de principes fondamentaux de cryptographie et de sécurité, la liaison stricte d'un identifiant à un ID de Relying Party (rpID) étant une pierre angulaire de sa conception anti-phishing. À mesure que les déploiements d'entreprise à grande échelle par des sociétés comme Amazon et Google sont devenus une réalité, la friction pratique causée par cette rigidité est devenue évidente. Cette friction est un obstacle direct à l'atteinte d'un taux d'adoption élevé par les utilisateurs, qui est la mesure ultime du succès de tout projet de passkeys. Le développement des ROR est une réponse directe à ces retours d'expérience des entreprises, démontrant une évolution pragmatique du standard. Il reconnaît que pour qu'un protocole de sécurité obtienne un succès généralisé, son utilisabilité doit s'adapter pour tenir compte des réalités commerciales complexes et des stratégies de marque des organisations qui le déploient.

Ce guide complet répond à cinq questions essentielles pour la mise en œuvre des Requêtes d'Origines Liées de WebAuthn :

1. Pourquoi les passkeys ne fonctionnent-ils pas sur plusieurs domaines ? Comprendre le modèle de sécurité de WebAuthn lié à l'origine et ses points de friction dans le monde réel.
2. Comment fonctionnent techniquement les Requêtes d'Origines Liées ? Une analyse approfondie du flux de validation du navigateur et du mécanisme d'URI .well-known.
3. Que faut-il pour mettre en œuvre les ROR ? Configuration pas à pas côté serveur et client avec des exemples de code pratiques.
4. Quand choisir les ROR plutôt que la connexion fédérée ? Un cadre de décision stratégique comparant les ROR aux approches OIDC/SAML.
5. Comment gérer la compatibilité des navigateurs et les considérations de sécurité ? La matrice de support actuelle et les meilleures pratiques de sécurité.

Pour plus de détails techniques, consultez l'explication officielle des Requêtes d'Origines Liées de WebAuthn.

Pour apprécier pleinement l'élégance de la solution des Requêtes d'Origines Liées, il est essentiel de comprendre d'abord les concepts techniques sous-jacents qui rendent son existence nécessaire : la politique de même origine du web et les règles de portée de l'ID de la Relying Party (rpID) de WebAuthn. Ces mécanismes sont fondamentaux pour la sécurité du web mais créent la friction même que les ROR sont conçues pour atténuer.

Une "origine" web est un concept de sécurité essentiel défini par la combinaison unique du protocole (par ex., https), du domaine (par ex., app.example.com) et du port (par ex., 443) à partir desquels le contenu est servi. La Politique de même origine est un mécanisme de sécurité appliqué par les navigateurs qui restreint la manière dont un script chargé depuis une origine peut interagir avec une ressource d'une autre origine. C'est un élément important de la sécurité web, isolant efficacement les documents potentiellement malveillants et empêchant un site web frauduleux, par exemple, de lire des données sensibles de la session de messagerie web authentifiée d'un utilisateur dans un autre onglet.

Dans l'écosystème WebAuthn, la "Relying Party" (RP) est le site web ou l'application avec lequel un utilisateur tente de s'authentifier. Chaque passkey est cryptographiquement lié à un ID de Relying Party (rpID) au moment de sa création. Le rpID est un nom de domaine qui définit la portée et la limite de cet identifiant.

Par défaut, le rpID est le domaine effectif de l'origine où le passkey est créé. Les règles de portée de WebAuthn permettent à une origine de définir un rpID qui est soit égal à son propre domaine, soit un suffixe de domaine enregistrable. Par exemple, un script s'exécutant sur https://www.accounts.example.co.uk peut créer un passkey avec un rpID de :

• www.accounts.example.co.uk (le domaine complet)
• accounts.example.co.uk
• example.co.uk

Cette flexibilité permet à un passkey créé sur un sous-domaine d'être utilisé sur d'autres sous-domaines du même domaine parent, ce qui est un schéma courant et nécessaire. Cependant, les règles interdisent strictement de définir un rpID qui n'est pas un suffixe. Le même script sur www.accounts.example.co.uk ne pourrait pas créer un passkey avec un rpID de example.com, car .com est un domaine de premier niveau différent.

Cette liaison stricte a un objectif important : séparer les identifiants par portée de domaine. Un passkey créé pour mybank.com ne peut pas être utilisé sur phishing-site.com car le site malveillant ne peut pas revendiquer le rpID légitime de mybank.com. Le navigateur ne présentera même pas le passkey comme option.

Cependant, le rpID lui-même n'est pas le principal contrôle anti-phishing. La protection anti-phishing de WebAuthn provient en réalité de la vérification de l'origine dans l'objet clientDataJSON. Lors de chaque cérémonie WebAuthn, le navigateur crée un objet JSON contenant un contexte critique, y compris l'origine exacte qui a initié la requête. Cet objet entier est ensuite signé cryptographiquement par la clé privée de l'authentificateur. Le serveur (Relying Party) DOIT vérifier cette signature et, de manière cruciale, valider que le champ d'origine dans le clientDataJSON signé correspond à une valeur attendue et de confiance. C'est cette vérification de l'origine qui empêche les attaques de phishing.

Avec les Requêtes d'Origines Liées, la portée du rpID est assouplie — permettant à bar.com de revendiquer légitimement le rpID de foo.com après que le navigateur a validé le fichier .well-known/webauthn — mais l'exigence de vérification de l'origine reste inchangée. Le clientDataJSON rapportera toujours fidèlement l'origine comme étant bar.com. Le serveur à foo.com reçoit ces données signées, les vérifie, et voit que la requête vient de bar.com. Le serveur doit alors vérifier que bar.com est une origine liée attendue avant d'accepter l'authentification. Cela démontre une approche multicouche qui permet une plus grande flexibilité sans sacrifier le principe fondamental de la vérification de l'origine.

Le mécanisme des Requêtes d'Origines Liées introduit une manière élégante et standardisée pour les domaines de déclarer publiquement une relation de confiance dans le but de partager des passkeys. Il s'appuie sur un modèle web bien établi — l'URI /.well-known/ — pour créer une "liste blanche" vérifiable et lisible par machine que les navigateurs peuvent consulter.

Le concept de base est simple : un domaine qui sert de rpID principal et canonique pour un ensemble de sites liés peut héberger un fichier JSON spécial à une URL standardisée et "bien connue" : https://{rpID}/.well-known/webauthn. Ce fichier agit comme un manifeste public, listant explicitement toutes les autres origines qui sont officiellement autorisées à créer et utiliser des passkeys sous ce rpID principal.

Le flux de validation du navigateur est déclenché chaque fois qu'il rencontre une non-concordance entre l'origine actuelle et le rpID demandé :

1. Un utilisateur sur un site "lié", tel que https://example.co.uk, initie une opération de passkey (création ou authentification) où le code côté client spécifie un domaine différent comme rpID, par exemple, example.com.
2. Le navigateur détecte cette non-concordance. Selon les anciennes règles, cela entraînerait immédiatement une SecurityError.
3. Avec le support des ROR, le navigateur, avant d'échouer, effectue une requête HTTPS GET sécurisée vers l'URL bien connue du rpID revendiqué : https://example.com/.well-known/webauthn. Cette requête est faite sans identifiants utilisateur (comme les cookies) et sans en-tête referrer pour protéger la confidentialité de l'utilisateur et empêcher le suivi.
4. Le navigateur reçoit la réponse JSON du serveur. Il analyse le fichier et vérifie si l'origine actuelle (https://example.co.uk) est présente dans le tableau origins de l'objet JSON.
5. Si l'origine est trouvée dans la liste blanche, l'opération WebAuthn est autorisée à continuer en utilisant example.com comme rpID valide. Si l'origine n'est pas trouvée, ou si le fichier est manquant ou mal formé, l'opération échoue comme elle l'aurait fait auparavant.

Le choix d'utiliser un URI /.well-known/ est délibéré et aligne les ROR avec les standards web établis pour la découverte de services et la validation du contrôle de domaine. Ce chemin d'URI, défini par la RFC 8615, est déjà utilisé par de nombreux protocoles critiques, y compris l'acme-challenge pour l'émission de certificats SSL Let's Encrypt et assetlinks.json pour lier des sites web à des applications Android. En adoptant cette convention, le W3C s'appuie sur un modèle qui implique intrinsèquement la propriété du domaine. Pour placer un fichier à ce chemin spécifique et standardisé, il faut avoir le contrôle administratif du serveur web pour ce domaine. Cela fournit une preuve de contrôle simple mais efficace, rendant la déclaration de confiance vérifiable. Lorsque le propriétaire de example.com sert un fichier listant example.co.uk comme une origine liée, c'est une affirmation vérifiable. Cette approche native du web est bien plus simple et robuste que les alternatives qui ont été considérées et rejetées pendant le processus de standardisation, telles que l'utilisation de clés cryptographiques pour signer des autorisations (RP Keys) ou d'identifiants aléatoires non basés sur un domaine (RP UUIDs). Les ROR ancrent la relation de confiance dans le modèle de contrôle de domaine existant et bien compris du web.

La mise en œuvre des Requêtes d'Origines Liées nécessite des changements coordonnés à la fois côté serveur, pour autoriser les origines, et côté client, pour invoquer le rpID partagé. Cette section fournit les détails pratiques de code et de configuration nécessaires pour permettre une expérience de passkey unifiée sur vos domaines.

Le serveur hébergeant le rpID principal est responsable de la publication de la liste blanche des origines liées.

Le fichier d'autorisation doit être placé au chemin exact /.well-known/webauthn par rapport à la racine du domaine du rpID principal. Il est crucial que ce fichier soit servi dans les conditions suivantes :

• Protocole : Il doit être servi via HTTPS.
• Content-Type : L'en-tête de réponse HTTP Content-Type doit être défini sur application/json.
• Extension de fichier : L'URL ne doit pas inclure d'extension .json. Le chemin correct est /webauthn, pas /webauthn.json.

Le fichier doit contenir un seul objet JSON avec une clé, origins, dont la valeur est un tableau de chaînes de caractères. Chaque chaîne du tableau est l'origine complète (protocole, domaine et port optionnel) qui est autorisée.

{
    "origins": ["https://example.co.uk", "https://example.de", "https://example.fr"]
}

Exemple : Pour un rpID de example.com, le fichier doit être servi à l'adresse https://example.com/.well-known/webauthn (note : pas d'extension .json).

Une fois le serveur configuré avec le fichier .well-known/webauthn, tous les domaines liés doivent utiliser de manière cohérente le même rpID partagé dans leurs appels à l'API WebAuthn. Cette coordination est essentielle pour que les ROR fonctionnent correctement.

Exigences clés de coordination :

1. Responsabilité du backend : Le serveur génère le défi cryptographique et spécifie le rpID partagé dans les requêtes de création d'identifiant et d'authentification.
2. Responsabilité du frontend : Toutes les applications clientes (example.com, example.co.uk, example.de) doivent passer le même rpID partagé à l'API navigator.credentials du navigateur.
3. Gestion de la configuration : Le rpID partagé doit être traité comme une valeur de configuration globale critique, appliquée de manière cohérente sur tous les sites liés.

Une mauvaise configuration sur un seul site — où il utiliserait par défaut sa propre origine comme rpID au lieu de la valeur partagée — brisera l'expérience de passkey unifiée pour les utilisateurs de ce domaine.

Important : Le serveur DOIT vérifier le champ origin dans le clientDataJSON pour chaque requête, en s'assurant qu'il correspond à l'une des origines liées autorisées. Cette vérification de l'origine est le principal mécanisme de protection contre le phishing.

Les Requêtes d'Origines Liées (ROR) et les protocoles d'identité fédérée (OIDC/SAML) résolvent des problèmes différents. Les ROR ne remplacent pas le Single Sign-On — c'est un complément qui répond à un cas d'usage spécifique et étroit.

Les ROR sont appropriées pour une seule application logique distribuée sur plusieurs domaines liés qui partagent la même base de données utilisateurs :

• Une seule marque opérant sur plusieurs TLD de code de pays (par ex., amazon.com, amazon.de, amazon.co.uk)
• Tous les domaines partagent le même système d'authentification backend et la même base de données utilisateurs
• Vous voulez éviter les flux basés sur la redirection et garder l'authentification contextuelle à chaque domaine
• Vos domaines respectent la limite de 5 étiquettes
• Les utilisateurs doivent percevoir tous les domaines comme un service unique et cohérent

Ce que les ROR fournissent : Le même passkey fonctionne sur tous les domaines liés, éliminant le besoin pour les utilisateurs de créer des passkeys distincts pour chaque site régional.

Utilisez les protocoles d'identité fédérée pour un véritable Single Sign-On entre des applications distinctes :

• Plusieurs services avec des bases de données utilisateurs ou des systèmes d'identité distincts
• Scénarios d'entreprise où les utilisateurs ont besoin d'accéder à de nombreuses applications différentes (Salesforce, Office 365, outils internes)
• Intégration d'applications tierces
• Vous avez besoin d'un contrôle d'accès centralisé, de pistes d'audit et d'une gouvernance des identités
• Vous dépassez la limite de 5 étiquettes pour les origines liées

Ce que l'OIDC/SAML fournit : Une authentification centralisée où les utilisateurs se connectent une seule fois à un Fournisseur d'Identité (IdP) et accèdent à plusieurs Fournisseurs de Services (SP) via des jetons sécurisés.

Important : Les passkeys peuvent être utilisés avec les deux approches. Vous pouvez implémenter les passkeys au niveau d'un IdP centralisé pour le SSO fédéré, ou utiliser les ROR pour une application unique multi-domaines. Choisissez en fonction de votre architecture, pas de votre méthode d'authentification.

Bien que les ROR soient une solution technique puissante, leur mise en œuvre doit être une décision stratégique mûrement réfléchie. Les architectes et les chefs de produit doivent peser leurs avantages par rapport à d'autres modèles et comprendre leurs limites pour construire un système d'authentification robuste et pérenne.

Une contrainte clé des ROR est la "limite d'étiquettes". Une "étiquette" dans ce contexte fait référence au domaine de premier niveau effectif plus un niveau (eTLD+1), qui est la partie enregistrable d'un nom de domaine. Par exemple :

• shopping.com, shopping.co.uk, et shopping.ca partagent tous la même étiquette unique "shopping"
• myshoppingrewards.com introduit une nouvelle étiquette distincte : "myshoppingrewards"
• travel.shopping.com relève toujours de l'étiquette "shopping"

La spécification WebAuthn de niveau 3 exige que les implémentations de navigateur prennent en charge un minimum de cinq étiquettes uniques dans la liste origins. En 2025, aucun navigateur connu ne prend en charge plus que ce minimum de cinq étiquettes. Par conséquent, les organisations doivent concevoir leurs déploiements ROR avec cette limite stricte à l'esprit — considérez cinq comme le maximum effectif.

Cette limite est un mécanisme anti-abus délibéré conçu pour prévenir les usages détournés. Elle empêche des entités comme les fournisseurs d'hébergement partagé (par ex., wordpress.com) de créer un passkey universel qui pourrait fonctionner sur des milliers de sous-domaines clients non liés, ce qui saperait le modèle de sécurité.

Pour la plupart des organisations, même les grandes marques multinationales, cette limite de cinq étiquettes est suffisante. Par exemple, les divers TLD de code de pays d'Amazon (amazon.com, amazon.de, amazon.co.uk, etc.) partagent tous l'étiquette "amazon", laissant quatre emplacements d'étiquettes supplémentaires disponibles pour d'autres marques de leur portefeuille comme "audible" ou "zappos".

La complexité de la mise en œuvre des ROR dépend fortement de si elles sont introduites dans un nouveau système ou ajoutées à un système existant.

• Déploiements Greenfield : Pour les nouveaux projets, la stratégie est simple. Un domaine unique et canonique doit être choisi comme rpID partagé dès le départ (par ex., le domaine .com principal). Ce rpID doit ensuite être utilisé de manière cohérente dans la configuration de tous les sites web et applications liés dès le premier jour.
• Déploiements existants : Ajouter les ROR à un système qui a déjà des passkeys déployés avec différents rpID sur ses domaines est beaucoup plus complexe. Une migration directe n'est pas possible, car les passkeys existants sont liés de manière permanente à leurs rpID d'origine. L'approche recommandée dans ce scénario est de mettre en œuvre un flux de connexion "identifier-first". L'utilisateur est d'abord invité à entrer son nom d'utilisateur ou son e-mail. Le backend effectue ensuite une recherche pour déterminer à quel rpID son passkey existant est associé. Enfin, l'utilisateur est redirigé vers l'origine correcte correspondant à ce rpID pour terminer la cérémonie d'authentification. Après une connexion réussie, il peut être redirigé vers son site d'origine. Il s'agit d'une entreprise architecturale considérable qui nécessite une planification et une mise en œuvre minutieuses.

Comprendre comment des entreprises établies mettent en œuvre les Requêtes d'Origines Liées fournit des informations précieuses pour votre propre stratégie de déploiement. Voici des exemples basés sur des implémentations réelles (en date d'octobre 2025) :

Microsoft utilise les ROR pour son infrastructure d'authentification. La configuration réelle sur login.microsoftonline.com inclut :

// https://login.microsoftonline.com/.well-known/webauthn
{
    "origins": ["https://login.microsoftonline.com", "https://login.live.com"]
}

Cette approche conservatrice permet le partage de passkeys entre les portails de connexion d'entreprise et grand public de Microsoft tout en maintenant un périmètre de sécurité ciblé.

Shopify implémente les ROR pour unifier l'authentification sur des domaines sélectionnés :

// https://shopify.com/.well-known/webauthn
{
    "origins": ["https://shopify.com", "https://shop.app"]
}

Cette configuration permet à Shopify de connecter sa plateforme principale avec son application Shop, démontrant une approche ciblée des origines liées.

Amazon a un fichier assez volumineux :

// https://amazon.com/.well-known/webauthn
{
    "origins": [
        "https://www.amazon.com",
        "https://www.amazon.com.br",
        "https://www.amazon.com.mx",
        "https://www.amazon.ca",
        "https://www.amazon.co.uk",
        "https://www.amazon.de",
        "https://www.amazon.it",
        "https://www.amazon.es",
        "https://www.amazon.nl",
        "https://www.amazon.se",
        "https://www.amazon.sa",
        "https://www.amazon.pl",
        "https://www.amazon.com.tr",
        "https://www.amazon.fr",
        "https://www.amazon.com.au",
        "https://www.amazon.sg",
        "https://www.amazon.ae",
        "https://www.amazon.eg",
        "https://www.amazon.co.za",
        "https://www.amazon.in",
        "https://brandregistry.amazon.com",
        "https://sellercentral.amazon.com",
        "https://sellercentral.amazon.com.br",
        "https://sellercentral.amazon.com.mx",
        "https://sellercentral.amazon.ca",
        "https://sellercentral.amazon.co.uk",
        "https://sellercentral.amazon.de",
        "https://sellercentral.amazon.it",
        "https://sellercentral.amazon.es",
        "https://sellercentral.amazon.nl",
        "https://sellercentral.amazon.se",
        "https://sellercentral.amazon.sa",
        "https://sellercentral.amazon.pl",
        "https://sellercentral.amazon.com.tr",
        "https://sellercentral.amazon.fr",
        "https://sellercentral.amazon.com.au",
        "https://sellercentral.amazon.sg",
        "https://sellercentral.amazon.ae",
        "https://sellercentral.amazon.eg",
        "https://sellercentral.amazon.co.za",
        "https://sellercentral.amazon.in",
        "https://na.account.amazon.com",
        "https://vendorcentral.amazon.com",
        "https://vendorcentral.amazon.com.br",
        "https://vendorcentral.amazon.com.mx",
        "https://vendorcentral.amazon.ca",
        "https://vendorcentral.amazon.co.uk",
        "https://vendorcentral.amazon.de",
        "https://vendorcentral.amazon.it",
        "https://vendorcentral.amazon.es",
        "https://vendorcentral.amazon.nl",
        "https://vendorcentral.amazon.se",
        "https://vendorcentral.amazon.pl",
        "https://vendorcentral.amazon.com.tr",
        "https://vendorcentral.amazon.fr",
        "https://vendorcentral.amazon.com.au",
        "https://vendorcentral.amazon.co.za"
    ]
}

Ce modèle permettrait à une marque de fournir une authentification par passkey unifiée sur ses domaines régionaux tout en utilisant le domaine .com principal comme rpID.

Ces exemples concrets révèlent plusieurs modèles clés :

1. Domaine principal comme rpID : Toutes les entreprises utilisent leur domaine .com principal comme rpID canonique.
2. Regroupement logique : Les origines sont regroupées par fonction commerciale plutôt que par architecture technique.
3. Portée conservatrice : La plupart des implémentations restent bien en deçà de la limite de 5 étiquettes, utilisant généralement 3-4 origines.
4. Stratégie de sous-domaines : Beaucoup utilisent des sous-domaines du domaine principal pour maintenir la cohérence de la marque.

En tant que standard web moderne, les ROR ont été conçues avec la sécurité comme considération principale et sont activement adoptées par les principaux navigateurs.

Les Requêtes d'Origines Liées ne compromettent pas les garanties anti-phishing fondamentales de WebAuthn. Le mécanisme est soigneusement conçu pour maintenir une posture de sécurité solide :

• Vérification de l'origine : Comme discuté, le navigateur inclut toujours la véritable origine de la requête dans le clientDataJSON signé. Le serveur de la Relying Party DOIT vérifier cette origine pour s'assurer que la requête provient d'une source attendue, empêchant une origine liée compromise d'usurper l'identité d'une autre.
• Récupération sécurisée : La requête du navigateur vers le fichier .well-known/webauthn est effectuée via HTTPS. De plus, la spécification exige que cette récupération soit effectuée sans identifiants (par ex., cookies) et sans en-tête Referer. Cela empêche que la requête ne soit utilisée pour fuiter des informations sur l'utilisateur ou à des fins de suivi intersites.
• Sécurité du serveur : Le fichier .well-known/webauthn lui-même devient un atout de sécurité essentiel. Un attaquant qui prendrait le contrôle du serveur web hébergeant le rpID principal pourrait potentiellement modifier ce fichier pour ajouter son propre domaine malveillant à la liste blanche. Par conséquent, la sécurisation de l'infrastructure qui sert ce fichier est de la plus haute importance.

Les Requêtes d'Origines Liées sont une fonctionnalité de la spécification WebAuthn de niveau 3. Le support des navigateurs a commencé à être déployé fin 2024 :

Faits clés :

• Chrome et Edge : Support des ROR ajouté dans la version 128 (août 2024)
• Safari : Support des ROR ajouté dans Safari 18, disponible sur macOS 15 et iOS 18 (septembre 2024)
• Firefox : Pas de support actuel pour les ROR ; détecter la fonctionnalité et implémenter des flux de secours

Pour les applications devant prendre en charge les navigateurs plus anciens ou Firefox, mettez en œuvre une stratégie de fallback :

1. Détection de fonctionnalité : Vérifiez le support des ROR en utilisant PublicKeyCredential.getClientCapabilities()
2. Flux identifier-first : Demandez le nom d'utilisateur/e-mail, recherchez le rpID associé à l'utilisateur, puis redirigez vers l'origine appropriée pour l'authentification
3. Dégradation gracieuse : Permettez aux utilisateurs de créer des passkeys distincts par domaine si les ROR ne sont pas disponibles

Données basées sur les matrices de support actuelles en date d'octobre 2025.

L'implémentation des Requêtes d'Origines Liées nécessite une coordination minutieuse entre plusieurs équipes techniques et une expertise approfondie des protocoles WebAuthn. La plateforme d'adoption des passkeys de Corbado élimine cette complexité en fournissant des solutions prêtes pour l'entreprise pour les déploiements de passkeys multi-domaines.

Corbado gère la complexité technique des Requêtes d'Origines Liées grâce à :

• Configuration automatisée : Notre plateforme génère et héberge automatiquement les fichiers .well-known/webauthn requis avec les en-têtes de sécurité et le formatage JSON appropriés.
• Tableau de bord multi-domaines : Interface de gestion centralisée pour configurer les origines liées sur l'ensemble de votre portefeuille de domaines.
• Outils de validation : Tests et validations intégrés pour garantir que votre configuration ROR fonctionne correctement sur tous les navigateurs et plateformes.

Au-delà de l'implémentation technique, Corbado fournit le cadre de sécurité dont les entreprises ont besoin :

• Vérification de l'origine : Validation automatique des origines de clientDataJSON pour prévenir l'abus de domaines liés.
• Journalisation d'audit : Suivi complet de l'utilisation des passkeys sur tous les domaines liés pour la surveillance de la conformité et de la sécurité.
• Réponse aux incidents : Alertes en temps réel et réponses automatisées pour les tentatives d'authentification inter-domaines suspectes.

Pour les organisations ayant des déploiements de passkeys existants, Corbado offre :

• Outils de migration existants : Analyse automatisée des configurations de rpID existantes et recommandations de chemins de migration.
• Flux identifier-first : Composants de connexion pré-construits qui gèrent des scénarios complexes multi-rpID pendant les périodes de transition.
• Intégration API : API RESTful et SDK qui s'intègrent de manière transparente à votre infrastructure d'authentification existante.

Prêt à mettre en œuvre les Requêtes d'Origines Liées pour votre organisation ? L'équipe d'experts de Corbado peut vous aider à concevoir et à déployer une expérience de passkey unifiée sur l'ensemble de votre écosystème numérique. Contactez notre équipe de solutions pour discuter de vos besoins spécifiques et de votre calendrier.

La promesse des passkeys réside dans leur capacité à offrir un avenir à la fois plus sûr et remarquablement plus simple pour les utilisateurs. Cependant, pour que cet avenir devienne une réalité à l'échelle mondiale, le standard doit s'adapter aux complexités architecturales des marques numériques modernes. La friction créée par des passkeys strictement liés au domaine a été un obstacle important à l'adoption pour les organisations ayant des présences en ligne multiples.

Les Requêtes d'Origines Liées de WebAuthn fournissent la solution standardisée, sécurisée et élégante à ce problème. En permettant à un seul passkey de fonctionner de manière transparente sur un ensemble de domaines liés de confiance, les ROR éliminent un point majeur de confusion et de frustration pour l'utilisateur.

Ce guide a répondu à cinq questions essentielles pour la mise en œuvre des Requêtes d'Origines Liées de WebAuthn :

1. Pourquoi les passkeys ne fonctionnent-ils pas sur plusieurs domaines ? Le modèle de sécurité de WebAuthn, lié à l'origine, verrouille cryptographiquement les passkeys à des domaines spécifiques pour empêcher le phishing, mais cela crée une friction lorsque les marques opèrent sur plusieurs domaines comme différents TLD de pays.
2. Comment fonctionnent techniquement les Requêtes d'Origines Liées ? Les ROR utilisent un fichier standardisé .well-known/webauthn pour créer une liste blanche vérifiable de domaines liés, permettant aux navigateurs de valider l'utilisation de passkeys inter-domaines via un processus de récupération HTTPS sécurisé.
3. Que faut-il pour mettre en œuvre les ROR ? L'implémentation nécessite une configuration côté serveur du fichier manifeste .well-known/webauthn et une coordination côté client pour utiliser un rpID partagé de manière cohérente sur toutes les origines liées.
4. Quand choisir les ROR plutôt que la connexion fédérée ? Utilisez les ROR pour des expériences de marque unifiées sur des domaines liés avec des bases de données utilisateurs partagées ; utilisez OIDC/SAML pour un véritable SSO sur des applications distinctes ou lorsque vous dépassez la limite de 5 étiquettes.
5. Comment gérer la compatibilité des navigateurs et les considérations de sécurité ? Les ROR sont prises en charge dans les principaux navigateurs à partir de Chrome/Edge 128+, Safari sur macOS 15+, et iOS 18+, avec des stratégies de fallback disponibles pour les navigateurs plus anciens via des flux identifier-first.

Pour les équipes techniques et les chefs de produit, les points essentiels sont :

• Les ROR permettent une expérience de passkey unifiée pour une seule application logique répartie sur plusieurs domaines, comme ceux avec différents TLD de code de pays ou des marques alternatives.
• L'implémentation nécessite un effort coordonné : un fichier .well-known/webauthn côté serveur doit être publié sur le domaine du rpID principal, et toutes les applications côté client doivent être configurées pour utiliser ce même rpID partagé.
• La décision d'utiliser les ROR est stratégique. C'est un excellent outil pour ses cas d'usage spécifiques, mais il doit être pesé par rapport à une architecture de connexion fédérée plus traditionnelle (OIDC/SAML), en particulier dans les scénarios impliquant un véritable Single Sign-On sur des applications disparates.

Des fonctionnalités comme les Requêtes d'Origines Liées sont vitales pour la dynamique continue du mouvement sans mot de passe. Elles démontrent un engagement des organismes de normalisation à relever les défis de mise en œuvre du monde réel, garantissant que les avantages des passkeys — sécurité inégalée et expérience utilisateur sans effort — sont accessibles même aux organisations les plus grandes et les plus complexes. À mesure que cette fonctionnalité gagnera un support universel des navigateurs, elle jouera un rôle crucial dans la levée des dernières barrières vers un internet véritablement mondial et sans mot de passe.