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.
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
vous connecter à plusieurs domaines spécifiques au pays (par exemple,
example.com
etexample.co.uk
) gérées 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: 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. Les requêtes d'origine associées offrent 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.
Cela permet aux utilisateurs 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
)
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 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 de la requête figure dans la liste d'autorisation de ce fichier. 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 de 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 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 authentifier avec elle surror-1
etror-2
. Étant donné queror-2
spécifieror-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
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 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 ces
deux sites.
Étape 2: Configurez votre fichier JSON .well-known/webauthn sur 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 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
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
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 tiers assujetti à des restrictions souhaité sur site-2
Dans votre codebase site-2
, définissez site-1.com
comme ID du tiers assujetti à des restrictions partout où vous en avez besoin:
- Lors de la création des identifiants :
- Définissez
site-1.com
comme ID de RP dans laoptions
de création d'identifiants 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 lorsque vous exécutez des identifiants. de validation avant de l'enregistrer dans votre base de données.
- Définissez
- Lors de l'authentification :
- Définissez
site-1.com
comme ID de tiers assujetti à des restrictions dans l'options
d'authentification transmis à l'appel de l'interfacenavigator.credentials.get
; et généralement 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
<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 Ajouter 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. Au lieu de cela, les agents utilisateur et les gestionnaires d'identifiants doivent indiquer aux utilisateurs où leurs identifiants ont été utilisés. Cette modification 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.