NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client.

Le texte ci-dessus est celui de Chromium (les versions plus anciennes omettent le lien « See: … »). Firefox affiche « CredentialsContainer request is not allowed. » (reproduit dans Firefox 157 en mode headless, qui n’a pas d’authentificateur). Le message varie selon le navigateur ; seul `e.name` est stable.

WebAuthn navigator.credentials.get() / create() — DOMException NotAllowedError (Chromium; Firefox wording in aliases)

Ce que cela signifie

L’erreur WebAuthn générique du navigateur, qui couvre tous les cas. La spécification rend délibérément indiscernables pour la page web « l’utilisateur a annulé », « le délai d’attente a expiré », « aucun authentificateur ne possède d’identifiant correspondant » et « la requête n’était pas autorisée dans ce contexte », afin qu’un site ne puisse pas sonder quels identifiants existent sur un appareil (la section liée sur la confidentialité explique pourquoi). Votre code doit donc traiter cette erreur comme « aucun identifiant n’a été produit » et proposer une autre voie ; la cause réelle se trouve en reproduisant le problème, pas en lisant l’erreur.

Pourquoi cela se produit

• Aucun identifiant de la liste allowCredentials sur cet authentificateur

  fréquente

  La clé d’accès du compte se trouve sur un autre appareil, a été supprimée ou a été enregistrée sous un autre ID de partie de confiance (RP ID). Le navigateur attend un authentificateur correspondant jusqu’à l’expiration du délai, puis signale NotAllowedError.

• L’utilisateur a fermé la boîte de dialogue ou le délai a expiré

  fréquente

  La fermeture de la fenêtre des clés d’accès du navigateur, des échecs répétés de la vérification biométrique ou un `timeout` court lors d’un parcours lent avec une clé de sécurité : tous ces cas se terminent de la même façon.

• Appel sans geste de l’utilisateur ou depuis une page masquée

  occasionnelle

  Safari en particulier exige que `create()`/`get()` s’exécutent en réponse à un clic ; les appels effectués après un `await` sur une requête réseau lente peuvent perdre l’activation. Les onglets en arrière-plan et les iframes d’une autre origine sans les autorisations `publickey-credentials-*` échouent aussi.

• Aucun algorithme pris en charge dans pubKeyCredParams

  occasionnelle

  Si l’authentificateur ne prend en charge aucun des algorithmes COSE que vous listez, l’enregistrement échoue avec NotAllowedError plutôt qu’avec une erreur spécifique.

Comment corriger l’erreur

1. 1.

   Traiter le cas comme « aucun identifiant » et proposer des alternatives

   N’affichez pas d’erreur alarmante. Proposez une autre méthode de connexion, un autre appareil (parcours hybride/QR) ou l’enregistrement d’une nouvelle clé d’accès.

   try {
     const credential = await navigator.credentials.get({ publicKey: options });
     await finishLogin(credential);
   } catch (e) {
     if (e.name === "NotAllowedError") {
       // Cancelled, timed out, or no passkey for this account on this device: offer alternatives.
       showOtherSignInOptions();
     } else {
       throw e;
     }
   }

2. 2.

   Proposer des algorithmes courants à l’enregistrement

   Lister ES256, EdDSA et RS256 couvre pratiquement tous les authentificateurs ; votre serveur doit alors vérifier les trois.

   // Registration: offer the algorithms authenticators actually support.
   pubKeyCredParams: [
     { type: "public-key", alg: -7 },    // ES256
     { type: "public-key", alg: -8 },    // EdDSA (Ed25519)
     { type: "public-key", alg: -257 },  // RS256 (Windows Hello and older security keys)
   ],

← Parcourir toute la base de données des erreurs de signature