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.

Il est spécifié dans l'ID de la partie de confiance (RP ID), 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 :

• Sites avec plusieurs domaines : les utilisateurs ne peuvent pas utiliser la même clé d'accès pour se connecter à 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 même 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 les iFrames, mais elles sont parfois peu pratiques. Les demandes d'origine associées offrent une solution.

Solution

Les requêtes d'origine associée permettent à un site Web de spécifier les origines autorisées à utiliser son ID de tiers de confiance.

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ée, 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 appellera à la création (navigator.credentials.create) ou à l'authentification (navigator.credentials.get) d'une clé d'accès à l'aide de example.com comme ID de RP, le navigateur remarquera un ID de RP qui ne correspond pas à l'origine de la demande. Si le navigateur est compatible avec les requêtes d'origine associée, 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 de la requête figure dans 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'accepte pas les requêtes d'origine associée, il génère une erreur SecurityError.

Prise en charge des navigateurs

Configurer les demandes d'origine associée

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 les deux sites, il utilise des requêtes d'origine associée pour autoriser ror-2.glitch.me à utiliser ror-1.glitch.me comme RP ID.

Démo

https://ror-2.glitch.me implémente les requêtes d'origine associée 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 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 sur les deux appareils.ror-1ror-2 Étant donné que ror-2 spécifie ror-1 comme ID de RP, une demande de création ou d'authentification par clé d'accès effectuée à partir de l'un de ces sites est identique à une demande effectuée sur ror-1. L'ID du 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 saisir automatiquement sur ror-1 et ror-2.
• Un identifiant RP de ror-1 sera attribué à tout identifiant créé sur l'un de ces sites.

Voir le code :

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

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

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 entre ces deux sites.

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

Tout d'abord, configurez site-1.com pour 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 sur le 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 content-type correct ('application/json') ;

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

Dans votre codebase site-2, définissez site-1.com comme ID de partie de confiance partout où cela est nécessaire :

• Lors de la création des identifiants :
  • Définissez site-1.com comme ID de RP dans les options de création d'identifiants qui sont transmis à l'appel frontend navigator.credentials.create et généralement générés côté serveur.
  • Définissez site-1.com comme ID de partie de confiance attendu, car vous effectuez des vérifications des identifiants avant de les enregistrer dans votre base de données.
• Une fois l'authentification effectuée :
  • Définissez site-1.com comme ID de partie de confiance dans les options d'authentification qui sont transmis à l'appel frontend navigator.credentials.get et généralement générés côté serveur.
  • Définissez site-1.com comme ID de partie de confiance attendu à vérifier sur le serveur, car vous exécutez des vérifications des identifiants avant d'authentifier l'utilisateur.

Dépannage

Autres points à noter

Partager des clés d'accès entre 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 entre des sites

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

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

Cela dépasse votre rôle de développeur de site, mais notez qu'à long terme, l'ID RP ne devrait pas être un concept visible par l'utilisateur dans l'agent utilisateur ou le gestionnaire d'identifiants que vos utilisateurs utilisent. Au lieu de cela, les agents utilisateur et les gestionnaires d'identifiants doivent indiquer aux utilisateurs où leurs identifiants ont été utilisés. La mise en œuvre de cette modification prendra du temps. Une solution temporaire consiste à afficher à la fois le site Web actuel et le site d'enregistrement d'origine.