Merci d'avoir participé à Google I/O ! Regarder des contenus à la demande

Autorisez la réutilisation des clés d'accès sur vos sites avec les requêtes d'origine associées

Maud Nalpas

Les clés d'accès sont liées à un site Web spécifique et ne peuvent être utilisées que pour se connecter au site Web pour lequel elles ont été créées.

Cela est spécifié dans l'ID de partie de confiance (RP), qui, pour les clés d'accès créées pour le domaine example.com, peut être www.example.com ou example.com.

Bien que les ID de RP empêchent l'utilisation des clés d'accès comme identifiant unique pour l'authentification partout, ils posent des problèmes pour les éléments suivants :

Sites avec plusieurs domaines : les utilisateurs ne peuvent pas utiliser la même clé d'accès pour se connecter sur différents domaines spécifiques à un pays (par exemple, example.com et example.co.uk) gérés par la même entreprise.
Domaines de marque : les utilisateurs ne peuvent pas utiliser les mêmes identifiants sur différents domaines utilisés par une seule marque (par exemple, acme.com et acmerewards.com).
Applications mobiles : les applications mobiles n'ont souvent pas leur propre domaine, ce qui rend la gestion des identifiants difficile.

Il existe des solutions de contournement basées sur la fédération d'identité et d'autres basées sur des iframes, mais elles sont parfois peu pratiques. Les requêtes d'origine associées offrent une solution.

Solution

Avec les requêtes d'origine associées, un site Web peut spécifier les origines autorisées à utiliser son ID de RP.

Cela permet aux utilisateurs de réutiliser la même clé d'accès sur plusieurs sites que vous exploitez.

Pour utiliser les requêtes d'origine associées, vous devez diffuser un fichier JSON spécial à une URL spécifique : https://{RP ID}/.well-known/webauthn. Si example.com souhaite autoriser les origines supplémentaires à l'utiliser comme ID de RP, il doit diffuser le fichier suivant à l'adresse https://example.com/.well-known/webauthn:

{
  "origins": [
    "https://example.co.uk",
    "https://example.de",
    "https://example-rewards.com"
  ]
}

La prochaine fois que l'un de ces sites effectuera un appel pour la création d'une clé d'accès (navigator.credentials.create) ou l'authentification (navigator.credentials.get) qui utilise example.com comme ID de RP, le navigateur remarquera un ID de RP qui ne correspond pas à l'origine de la requête. Si le navigateur est compatible avec les requêtes d'origine associées, il recherche d'abord un fichier webauthn à l'adresse https://{RP ID}/.well-known/webauthn. Si le fichier existe, le navigateur vérifie si l'origine à l'origine de la requête figure sur la allowlist. Si c'est le cas, il passe aux étapes de création ou d'authentification de la clé d'accès.

Si le navigateur n'est pas compatible avec les requêtes d'origine associées, il génère une SecurityError.

Prise en charge des navigateurs

Les requêtes d'origine associées sont compatibles avec Chrome et Safari. En janvier 2026, Firefox envisage toujours cette fonctionnalité. Vous pouvez suivre son état dans le problème de position des normes Mozilla.

Configurer les requêtes d'origine associées

La démonstration suivante utilise deux sites : https://ror-1.glitch.me et https://ror-2.glitch.me. Pour permettre aux utilisateurs de se connecter avec la même clé d'accès sur ces deux sites, elle utilise des requêtes d'origine associées pour autoriser ror-2.glitch.me à utiliser ror-1.glitch.me comme ID de RP.

Démo

https://ror-2.glitch.me implémente des requêtes d'origine associées pour utiliser ror-1.glitch.me comme ID de RP. Par conséquent, ror-1 et ror-2 utilisent ror-1.glitch.me comme ID de RP lors de la création d'une clé d'accès ou de l'authentification avec celle-ci. Nous avons également implémenté une base de données de clés d'accès partagée sur ces sites.

Observez l'expérience utilisateur suivante :

Vous pouvez créer une clé d'accès et vous authentifier avec celle-ci sur ror-2, même si son ID de RP est ror-1 (et non ror-2).
Une fois que vous avez créé une clé d'accès sur ror-1 ou ror-2, vous pouvez vous authentifier avec celle-ci sur ror-1 et ror-2. Étant donné que ror-2 spécifie ror-1 comme ID de RP, effectuer une requête de création ou d'authentification de clé d'accès à partir de l'un de ces sites revient à effectuer la requête sur ror-1. L'ID de RP est la seule chose qui lie une requête à une origine.
Une fois que vous avez créé une clé d'accès sur ror-1 ou ror-2, Chrome peut la remplir automatiquement sur ror-1 et ror-2.
Un identifiant créé sur l'un de ces sites aura un ID de RP ror-1.

Chrome remplit automatiquement les champs sur les deux sites. — Grâce aux requêtes d'origine associées, les utilisateurs peuvent utiliser les mêmes identifiants de clé d'accès sur ror-1 et ror-2. Chrome remplira également automatiquement les identifiants.

Voir le code :

Consultez le fichier /.well-known/webauthn configuré dans la base de code ror-1.
Consultez les occurrences RP_ID_ROR dans la base de code ror-2.

Étape 1 : Implémenter une base de données de comptes partagée

Si vous souhaitez que vos utilisateurs puissent se connecter avec la même clé d'accès sur site-1 et site-2, implémentez une base de données de comptes partagée sur ces deux sites.

Étape 2 : Configurez votre fichier JSON .well-known/webauthn dans site-1

Tout d'abord, configurez site-1.com de sorte qu'il autorise site-2.com à l'utiliser comme ID de RP. Pour ce faire, créez votre fichier JSON webauthn :

{
    "origins": [
        "https://site-2.com"
    ]
}

L'objet JSON doit contenir une clé nommée "origins" dont la valeur est un tableau d'une ou plusieurs chaînes contenant des origines Web.

Limitation importante : 5 libellés maximum

Chaque élément de cette liste sera traité pour extraire le libellé eTLD + 1. Par exemple, les libellés eTLD + 1 de example.co.uk et example.de sont tous deux example. Toutefois, le libellé eTLD + 1 de example-rewards.com est example-rewards. Dans Chrome, le nombre maximal de libellés est de 5.

Étape 3 : Diffusez votre fichier JSON .well-known/webauthn dans site-1

Ensuite, diffusez votre fichier JSON sous site-1.com/.well-known/webauthn.

Par exemple, dans Express :

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

Ici, nous utilisons express res.json, qui définit déjà le correct content-type ('application/json') ;

Étape 4 : Spécifiez l'ID de RP dans site-2

Dans votre base de code site-2, définissez site-1.com comme ID de RP partout où cela est nécessaire :

Lors de la création d'identifiants :
- Définissez site-1.com comme ID de RP dans les options de création d'identifiants transmises à l'appel frontend navigator.credentials.create, et généralement générées côté serveur.
- Définissez site-1.com comme ID de RP attendu lorsque vous exécutez des validations d'identifiants avant de l'enregistrer dans votre base de données.
Lors de l'authentification :
- Définissez site-1.com comme ID de RP dans les options d'authentification transmises à l'appel frontend navigator.credentials.get, et généralement générées côté serveur.
- Définissez site-1.com comme ID de RP attendu à valider sur le serveur lorsque vous exécutez des validations d'identifiants avant d'authentifier l'utilisateur.

Dépannage

Pop-up de message d'erreur dans Chrome. — Message d'erreur dans Chrome lors de la création d'identifiants. Cette erreur est générée si votre fichier `.well-known/webauthn` est introuvable à l'adresse `https://{RP ID}/.well-known/webauthn`.

Autres points à noter

Partager des clés d'accès sur des sites et des applications mobiles

Les requêtes d'origine associées permettent à vos utilisateurs de réutiliser une clé d'accès sur plusieurs sites. Pour permettre à vos utilisateurs de réutiliser une clé d'accès sur un site Web et une application mobile, utilisez les techniques suivantes :

Dans Chrome : Digital Asset Links. Pour en savoir plus, consultez Ajouter la prise en charge de Digital Asset Links.
Dans Safari: domaines associés.

Partager des mots de passe sur des sites

Les requêtes d'origine associées permettent à vos utilisateurs de réutiliser une clé d'accès sur des sites. Les solutions de partage de mots de passe sur des sites varient selon les gestionnaires de mots de passe. Pour le Gestionnaire de mots de passe de Google, utilisez Digital Asset Links . Safari dispose d'un système différent.

Rôle des gestionnaires d'identifiants et des agents utilisateur

Cela dépasse votre champ d'application en tant que développeur de site, mais notez qu'à plus long terme, l'ID de RP ne doit pas être un concept visible par l'utilisateur dans l'agent utilisateur ni dans le gestionnaire d'identifiants que vos utilisateurs utilisent. Au lieu de cela, les agents utilisateurs et les gestionnaires d'identifiants doivent indiquer aux utilisateurs où leurs identifiants ont été utilisés. Ce changement prendra du temps à être implémenté. Une solution temporaire consisterait à afficher à la fois le site Web actuel et le site d'enregistrement d'origine.