Présentation des optimisations, des requêtes d'origine associées et de la sérialisation JSON pour WebAuthn dans Chrome

Chrome 128 et 129 introduit de nouvelles fonctionnalités intéressantes pour WebAuthn : pour créer des systèmes d'authentification basés sur des clés d'accès.

• Indices: ils donnent aux tiers de confiance un meilleur contrôle sur WebAuthn UI dans le navigateur. Ils sont particulièrement utiles pour les utilisateurs professionnels qui souhaitent pour utiliser des clés de sécurité.
• Requêtes d'origines associées: avec une origine associée requêtes, les tiers assujettis à des restrictions peuvent rendre les clés d'accès valides sur plusieurs domaines. Si vous possédez plusieurs sites, vous pouvez désormais autoriser vos utilisateurs à réutiliser leur clé d'accès sur vos sites, en éliminant les frictions de connexion.
• Sérialisation JSON: les API de sérialisation JSON vous permettent de simplifier le code de l'interface d'un tiers assujetti à des restrictions grâce à des options d'encodage et de décodage, les identifiants transmis vers et depuis l'API WebAuthn.

Astuces

Avec hints, les tiers de confiance peuvent désormais spécifier les préférences d'UI pour créer un clé d’accès ou s’authentifier avec une clé d’accès.

Auparavant, lorsqu'un tiers assujetti à des restrictions voulait restreindre l'authentification créer une clé d'accès ou pour s'authentifier, il pourrait utiliser authenticatorSelection.authenticatorAttachment pour spécifier "platform" ou "cross-platform" Ils limitent respectivement l'authentificateur à une plate-forme authentificateur ou en itinérance authentificateur. Avec hints, cette spécification peut être plus flexible.

Le tiers assujetti à des restrictions peut utiliser un hints facultatif dans le PublicKeyCredentialCreationOptions ou PublicKeyCredentialRequestOptions pour spécifier "security-key", "client-device" et "hybrid" dans un ordre de préférence dans un tableau.

Voici un exemple de requête de création d'identifiants qui préfère Authentificateurs "cross-platform" avec l'indice "security-key". Cela indique Chrome pour afficher une interface utilisateur axée sur la clé de sécurité pour les utilisateurs de la version Enterprise.

const credential = await navigator.credentials.create({
  publicKey: {
    challenge: *****,
    hints: ['security-key'],
    authenticatorSelection: {
      authenticatorAttachment: 'cross-platform'
    }
  }
});

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

</ph>

Lorsqu'un tiers assujetti à des restrictions souhaite donner la priorité à un scénario de validation multi-appareil, il peut envoyer une requête d'authentification qui préfère les authentificateurs "cross-platform" avec "hybrid" comme indice.

const credential = await navigator.credentials.create({
  publicKey: {
    challenge: *****,
    residentKey: true,
    hints: ['hybrid']
    authenticatorSelection: {
      authenticatorAttachment: 'cross-platform'
    }
  }
});

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

</ph>

Requêtes d'origine associées

Avec origine associée Demandes, les tiers assujettis à des restrictions peuvent rendre les clés d'accès utilisables à partir de plusieurs domaines. Créer une connexion centralisée et l'utilisation des protocoles de fédération restent la solution recommandée pour sur la plupart des sites. Mais si vous possédez plusieurs domaines et que la fédération n'est pas possible, peut être une solution.

Toutes les requêtes WebAuthn doivent spécifier un ID de tiers de confiance (RP ID) et toutes les clés d'accès sont associés à un seul ID de tiers assujetti à des restrictions. Traditionnellement, une origine ne pouvait spécifier que un ID de tiers assujetti à des restrictions basé sur son domaine, donc www.example.co.uk pourrait spécifier ID de tiers assujetti à des restrictions example.co.uk, mais pas example.com. Avec origine associée Requêtes, un ID de RP revendiqué peut être validé en récupérant un fichier JSON bien connu situé à l'adresse /.well-known/webauthn du domaine cible. Donc example.co.uk (et example.in, example.de, etc.) pourraient tous utiliser l'ID de tiers assujetti à des restrictions de example.com si example.com les spécifie au format suivant:

URL : https://example.com/.well-known/webauthn

{
  "origins": [
    "https://example.co.uk",
    "https://example.de",
    "https://example.sg",
    "https://example.net",
    "https://exampledelivery.com",
    "https://exampledelivery.co.uk",
    "https://exampledelivery.de",
    "https://exampledelivery.sg",
    "https://myexamplerewards.com",
    "https://examplecars.com"
  ]
}

Pour savoir comment configurer les requêtes d'origine associées, consultez Autoriser la réutilisation des clés d'accès dans vos sites dont l'origine est associée Requêtes.

Sérialisation JSON

Les objets de requête et de réponse WebAuthn comportent plusieurs champs contenant des données Données binaires d'un ArrayBuffer, telles que l'ID d'identification, l'ID utilisateur ou la question d'authentification. Si un site Web souhaite utiliser JSON pour échanger ces données avec son serveur, le binaire les données doivent d'abord être encodées, par exemple en Base64URL. Cela ajoute des données pour les développeurs qui souhaitent commencer à utiliser des clés d'accès sur leurs sites Web.

WebAuthn propose désormais des API pour analyser PublicKeyCredentialCreationOptions et PublicKeyCredentialRequestOptions les objets de requête WebAuthn directement à partir de JSON et sérialiser les PublicKeyCredential directement dans JSON. Tous les champs de valeur ArrayBuffer contenant un binaire brut les données sont automatiquement converties à partir de leurs valeurs encodées en Base64URL. Ces API sont disponibles à partir de Chrome 129.

Avant de créer une clé d'accès, récupérez un fichier JSON encodé l'objet PublicKeyCredentialCreationOptions du serveur et le décoder à l'aide de PublicKeyCredential.parseCreationOptionsFromJSON()

export async function registerCredential() {

  // Fetch encoded `PublicKeyCredentialCreationOptions`
  // and JSON decode it.
  const options = await fetch('/auth/registerRequest').json();

  // Decode `PublicKeyCredentialCreationOptions` JSON object
  const decodedOptions = PublicKeyCredential.parseCreationOptionsFromJSON(options);  

  // Invoke the WebAuthn create() function.
  const cred = await navigator.credentials.create({
    publicKey: decodedOptions,
  });
  ...

Après avoir créé une clé d'accès, encodez l'identifiant obtenu à l'aide de toJSON() afin de pour pouvoir l'envoyer au serveur.

  ...
  const cred = await navigator.credentials.create({
    publicKey: options,
  });

  // Encode the credential to JSON and stringify
  const credential = JSON.stringify(cred.toJSON());

  // Send the encoded credential to the server
  await fetch('/auth/registerResponse', credential);
  ...

Avant de vous authentifier avec une clé d'accès, récupérez un fichier JSON encodé PublicKeyRequestCreationOptions à partir du serveur et le décoder à l'aide de PublicKeyCredential.parseRequestOptionsFromJSON()

export async function authenticate() {

  // Fetch encoded `PublicKeyCredentialRequestOptions`
  // and JSON decode it.
  const options = await fetch('/auth/signinRequest').json();

  // Decode `PublicKeyCredentialRequestOptions` JSON object
  const decodedOptions = PublicKeyCredential.parseRequestOptionsFromJSON(options);

  // Invoke the WebAuthn get() function.
  const cred = await navigator.credentials.get({
    publicKey: options
  });
  ...

Après vous être authentifié avec une clé d'accès, encodez l'identifiant obtenu à l'aide de toJSON() afin qu'elle puisse être envoyée au serveur.

  ...
  const cred = await navigator.credentials.get({
    publicKey: options
  });

  // Encode the credential to JSON and stringify
  const credential = JSON.stringify(cred.toJSON());

  // Send the encoded credential to the server
  await fetch(`/auth/signinResponse`, credential);
  ...

En savoir plus

Pour en savoir plus sur WebAuthn et les clés d'accès, consultez les ressources suivantes:

• Clés d'accès | Chrome pour les développeurs
• Présentation des clés d'accès côté serveur implémentation
• passkeys.dev