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
etexample.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 utilisés par une même marque (par exemple,
acme.com
etacmerewards.com
). - Applications mobiles: les applications mobiles n'ont souvent 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 appelle 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
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 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 en servir pour vous authentifier sur
ror-2
, même si son ID de RP estror-1
(et nonror-2
). - Une fois que vous avez créé une clé d'accès sur
ror-1
ouror-2
, vous pouvez vous en servir pour vous authentifier à la fois surror-1
etror-2
. Étant donné queror-2
spécifieror-1
comme ID d'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
ouror-2
, elle peut être saisie automatiquement par Chrome surror-1
etror-2
. - Les identifiants créés sur l'un de ces sites auront un ID RP de
ror-1
.
Voir le code:
- Consultez le fichier
./well-known/webauthn
configuré dans le code de base 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 compte partagée entre ces deux sites.
Étape 2: Configurez votre fichier JSON .well-known/webauthn dans 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 des origines nommées dont la valeur est un tableau d'une ou plusieurs chaînes contenant des origines Web.
Limite importante: cinq libellés maximum
Chaque élément de cette liste sera traité pour extraire le libellé de l'eTLD+1.
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: Servez 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 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'identifiantsoptions
qui sont transmis à l'appel de front-endnavigator.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.
- Définissez
- 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-endnavigator.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éfinissez
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 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.