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

Maud Nalpas

Problème résolu par les requêtes d'origine associées

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

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

Bien que les ID de RP empêchent les clés d'accès d'être utilisées comme identifiant unique pour l'authentification partout, ils créent des problèmes pour :

• 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 associés à une marque: les utilisateurs ne peuvent pas utiliser les mêmes identifiants sur différents domaines associés à une même marque (par exemple, acme.com et acmerewards.com).
• Applications mobiles: souvent, les applications mobiles n'ont pas de domaine propre, ce qui complique la gestion des identifiants.

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

Les utilisateurs peuvent ainsi réutiliser la même clé d'accès sur plusieurs sites que vous gérez.

Pour utiliser les requêtes d'origine associées, vous devez diffuser un fichier JSON spécial à une URL https://{RP ID}/.well-known/webauthn spécifique. Si example.com souhaite autoriser les origines supplémentaires à l'utiliser comme ID RP, il doit diffuser le fichier suivant à 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 de clés d'accès (navigator.credentials.create) ou l'authentification (navigator.credentials.get) qui utilise example.com comme ID de RP, le navigateur remarque 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ées, il recherche d'abord un fichier webauthn dans https://{RP ID}/.well-known/webauthn. Si le fichier existe, le navigateur vérifie si l'origine de la requête figure dans la liste d'autorisation de ce fichier. Si c'est le cas, la création d'une clé d'accès ou les étapes d'authentification sont lancées. Si le navigateur n'est pas compatible avec les requêtes d'origine associées, une exception SecurityError est générée.

Prise en charge des navigateurs

• Chrome: compatible à partir de Chrome 128.
• Safari : compatible à partir de la version bêta 3 de macOS 15 et de la version bêta 3 d'iOS 18 pour mobile.
• Firefox : En attente de position.

Configurer les requêtes d'origine associées

La démonstration suivante utilise l'exemple de 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, il utilise des requêtes d'origine associées pour permettre à ror-2.glitch.me d'utiliser ror-1.glitch.me comme ID de RP.

Démo

https://ror-2.glitch.me implémente les requêtes d'origine associées pour utiliser ror-1.glitch.me comme ID de RP. ror-1 et ror-2 utilisent donc 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 à l'aide de 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 en servir pour vous authentifier à la fois sur ror-1 et ror-2. Étant donné que ror-2 spécifie ror-1 comme ID de RP, envoyer une requête de création ou d'authentification d'une clé d'accès à partir de l'un de ces sites revient à envoyer la requête sur ror-1. L'ID de RP est le seul élément qui associe une requête à une origine.
• Une fois que vous avez créé une clé d'accès sur ror-1 ou ror-2, elle peut être saisie automatiquement par Chrome sur ror-1 et ror-2.
• Les identifiants créés sur l'un de ces sites auront un ID de RP de ror-1.

Voir le code:

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

Étape 1 : Implémentez 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 site-1

Commencez par configurer 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 de plusieurs chaînes contenant des origines Web.

Limite importante : cinq libellés maximum

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

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

Diffusez ensuite 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 approprié ('application/json').

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

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

• Lors de la création des identifiants :
  • Définissez site-1.com comme ID de RP dans la création d'identifiants options qui sont transmis à l'appel de front-end navigator.credentials.create et généralement générés côté serveur.
  • Définissez site-1.com comme ID de RP attendu, car vous exécutez des vérifications d'identifiants avant de les enregistrer dans votre base de données.
• Lors de l'authentification :
  • Définissez site-1.com comme ID de RP dans l'options d'authentification qui est transmis à l'appel de front-end navigator.credentials.get et généralement généré côté serveur.
  • Définissez site-1.com comme ID RP attendu à valider sur le serveur, car vous exécutez des validations d'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 (Associations d'assets numériques). 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 les 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 des mots de passe entre les 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 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 utilisateur et les gestionnaires d'identifiants doivent indiquer aux utilisateurs où leurs identifiants ont été utilisés. L'implémentation de cette modification prendra du temps. Une solution temporaire consiste à afficher à la fois le site Web actuel et le site d'enregistrement d'origine.