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

La solution aux requêtes d'origine associées

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

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

Alors que les ID de RP empêchent l’utilisation de clés d’accès comme identifiant unique pour s'authentifiant 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 vous connecter à plusieurs domaines spécifiques au 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 dans domaines distincts utilisés par une même marque (par exemple, acme.com et acmerewards.com).
• Applications mobiles: souvent, les applications mobiles n'ont pas de domaine propre. la gestion des identifiants.

Il existe des solutions de contournement basées sur la fédération d'identité, d'autres basées sur iFrame, mais ils sont gênants dans certains cas. Offre pour les demandes d'origine associées une solution.

Solution

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

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

Pour utiliser des 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 que les origines supplémentaires puissent l'utiliser comme ID de tiers assujetti à des restrictions, il doit diffuser l'élément fichier à l'emplacement 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 vous demandera de créer des clés d'accès (navigator.credentials.create) ou l'authentification (navigator.credentials.get) utilisant 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 l'origine associée "Requêtes", il recherche d'abord Fichier webauthn à l'emplacement 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 liste d'autorisation . Si c'est le cas, il passe à la création ou à l'authentification de la clé d'accès. Si le navigateur n'accepte pas les requêtes d'origine associées, il génère une erreur SecurityError.

Prise en charge des navigateurs

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

Configurer des 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, le service utilise des requêtes d'origine associées afin d'autoriser ror-2.glitch.me à 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 authentifier avec elle sur ror-1 et ror-2. Étant donné que ror-2 spécifie ror-1 comme ID de RP, effectuer une demande de création de clé d'accès ou d'authentification à partir de l'un de ces sites revient à effectuer 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.
• Un identifiant créé sur l'un de ces sites aura l'ID de tiers assujetti à des restrictions ror-1.

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

Voir le code:

• Consultez le fichier ./well-known/webauthn configuré dans le codebase ror-1.
• Consultez les occurrences RP_ID_ROR dans le codebase 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émentent une base de données de comptes partagée entre eux. deux sites.

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

Commencez par configurer site-1.com de sorte qu'il autorise site-2.com à l'utiliser comme ID du tiers assujetti à des restrictions. 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 de un. ou plusieurs chaînes contenant des origines Web.

Restriction importante: 5 libellés au maximum

Chaque élément de cette liste sera traité pour extraire l'eTLD + un libellé. Par exemple, l'eTLD + 1 libellés de example.co.uk et example.de sont tous deux example Mais l'eTLD + 1 libellé 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à content-type correct ('application/json') ;

Étape 4: Spécifiez l'ID de tiers assujetti à des restrictions souhaité sur site-2

Dans votre codebase site-2, définissez site-1.com comme ID de tiers assujetti à des restrictions partout où vous en avez besoin:

• Lors de la création des identifiants: <ph type="x-smartling-placeholder">
  </ph>
  • Définir site-1.com comme ID de RP lors de la création des identifiants Les options transmis à navigator.credentials.create frontend, généralement généré côté serveur.
  • Définissez site-1.com comme ID de RP attendu lorsque vous exécutez des identifiants. de validation avant de l'enregistrer dans votre base de données.
• Lors de l'authentification: <ph type="x-smartling-placeholder">
  </ph>
  • Définissez site-1.com comme ID de tiers assujetti à des restrictions dans l'options d'authentification transmis à l'appel de l'interface navigator.credentials.get ; et généralement côté serveur.
  • Définissez site-1.com comme ID de tiers assujetti à des restrictions attendu à valider sur le à un serveur Google, car vous vérifiez les identifiants avant d'authentifier l'utilisateur.

Dépannage

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

Autres points à prendre en compte

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 dans plusieurs de votre site Web. Pour permettre à vos utilisateurs de réutiliser une clé d'accès sur un site Web et une application mobile, procédez comme suit : utilisez les techniques suivantes:

• Dans Chrome: ressource numérique Liens. Pour en savoir plus, consultez la page Ajoutez la prise en charge de Digital Asset Links.
• Dans Safari: Domaines associés :

Partager des mots de passe sur plusieurs 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 autre système.

Rôle des gestionnaires d'identifiants et des user-agents

Cela dépasse votre champ d'action en tant que développeur de site, mais notez que plus l'ID du tiers assujetti à des restrictions ne doit pas être visible par l'utilisateur dans l'user-agent ou le gestionnaire d'identifiants utilisé par vos utilisateurs. À la place, les user-agents et les identifiants Les responsables doivent indiquer aux utilisateurs où leurs identifiants ont été utilisés. Ce changement leur mise en œuvre prendra du temps. Une solution temporaire consisterait à afficher à la fois le site Web actuel et le site d'inscription d'origine.