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
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 dans
domaines distincts 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. 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 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
. - Un identifiant créé sur l'un de ces sites aura l'ID de tiers assujetti à des restrictions
ror-1
.
![Chrome utilise la saisie automatique sur les deux sites.](https://web.dev/static/articles/webauthn-related-origin-requests/image/chrome-autofill.jpg?hl=fr)
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 Lesoptions
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.
- Définir
- 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'interfacenavigator.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éfinissez
Dépannage
<ph type="x-smartling-placeholder">![Pop-up d'erreur dans Chrome.](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-not-found.jpg?hl=fr)
![Pop-up d'erreur dans Chrome.](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-incorrect.jpg?hl=fr)
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.