Credential Management API : concevoir une connexion fiable
Comprenez la médiation du navigateur, le choix de l’utilisateur, les solutions de repli et la validation serveur indispensables.
Vous voulez la documentation structurée pour Identité ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
La Credential Management API offre à un site une demande, un stockage et une lecture d’identifiants médiés par le navigateur. Elle ne transforme pas le navigateur en fournisseur d’identité et ne crée pas une session seule. Une connexion fiable relie l’intention de l’utilisateur, la médiation, la validation du serveur et un repli clair.
Le document W3C Credential Management Level 1 est un Working Draft, et non une recommandation finale du W3C. Il décrit le conteneur et la médiation, sans constituer une garantie définitive de compatibilité entre navigateurs. La référence MDN de Credential Management API décrit les interfaces et leur compatibilité. Ces sources distinguent une capacité, une opération consentie et une session authentifiée.
Définir Le Contrat De Connexion
Avant navigator.credentials, décrivez la tâche visible : reprendre un travail, créer un compte ou confirmer une action sensible. Cette réponse détermine l’identifiant proposé, le consentement requis et les données à conserver en cas d’annulation.
Considérez le conteneur comme une limite du navigateur, pas comme une base de comptes. Le navigateur peut remettre un objet si la demande est permise ; la politique de compte, la session, l’autorisation et la récupération restent celles de l’application.
Nommez séparément les états : repos, intention enregistrée, demande médiée, annulation, identifiant reçu, validation en attente, session créée et récupération disponible. L’interface n’annonce ainsi pas une connexion avant la réponse serveur.
Un choix explicite protège la confidentialité et l’accessibilité. Affichez un contrôle étiqueté, expliquez la relation de compte visée et avertissez qu’une invite du navigateur peut apparaître. Ne lancez pas l’opération au simple chargement.
La liaison de comptes exige un contrat précis. Un identifiant ne doit pas remplacer ou fusionner une session sans confirmation. Demandez s’il faut se connecter, lier ou changer de compte et conservez le travail en cours.
Comprendre La Médiation Du Navigateur
L’API sépare type d’identifiant et médiation. Les types disponibles et leur comportement dépendent du navigateur, du fournisseur, de la politique et du contexte.
La médiation indique le degré d’interaction. Une voie silencieuse ou conditionnelle peut servir un retour ; une voie requise rend l’action explicite. Aucun résultat ne prouve l’absence de compte ou d’identifiant.
L’appel peut échouer avant le fournisseur : contexte non sûr, interface absente ou politique restrictive. Une branche de compatibilité peut montrer une autre méthode, mais ne fabrique pas d’identifiant.
L’invite fait partie du parcours. Expliquez l’action, préservez le focus et permettez l’annulation. Un refus est un choix normal ; revenez aux options sans rouvrir automatiquement l’invite.
Un objet d’identifiant peut contenir des éléments sensibles. Ne le placez pas dans une URL, une étiquette analytique, une capture, une erreur ou un ticket. Envoyez seulement les champs nécessaires et journalisez une étape résumée.
Le guide de confidentialité WebAuthn rappelle qu’une capacité n’est pas la preuve d’un identifiant ni d’une identité. Appliquez la même limite ici.
Garder La Validation Côté Serveur
Le serveur est l’autorité de la session. Il valide l’échange selon le type et le fournisseur, le lie à l’action et à la partie de confiance et rejette les valeurs expirées ou rejouées. Le rappel JavaScript ne suffit pas.
Liez chaque demande à un état applicatif bref. Au retour, contrôlez le type, l’audience si nécessaire et l’action attendue. Ne vérifiez un nonce ou une signature que si le protocole de l’intégration l’exige. Les chemins mot de passe et navigateur partagent la même politique de session.
La création de session et l’enregistrement d’un identifiant sont différents. Le résultat peut connecter, enregistrer, lier ou seulement rendre un profil vérifié. Expliquez le résultat et fournissez une déconnexion qui termine la session de la partie de confiance. Cette action ne ferme pas à elle seule la session du fournisseur et ne supprime pas un identifiant enregistré par le navigateur.
Les erreurs doivent aider sans révéler l’existence d’un compte. Utilisez un message cohérent pour un identifiant invalide, expiré ou inconnu et gardez seulement l’étape résumée utile au diagnostic.
La récupération relève de l’application. Proposez réinitialisation, vérification de support ou voie de première partie si elles sont autorisées. Ne demandez ni historique de navigation ni profil complet ; une référence de récupération doit expirer et être invalidée.
Le guide de partition du stockage explique les différences dans un contexte intégré. Traitez-les comme un résultat de contexte et proposez un handoff de première partie clair.
Concevoir Repli Et Retour Accessible
Un flux solide offre une option médiée et une alternative compréhensible : mot de passe, page du fournisseur, lien courriel ou récupération approuvée. Le repli ne contourne pas une politique ; il sert aux cas indisponibles, refusés ou expirés.
Conservez le travail entre les branches. Après fermeture de l’invite, revenez à l’écran connu avec les champs non sensibles. Après un délai, expliquez l’incertitude et créez un nouvel état. Ne montrez jamais un succès avant la validation.
Le statut accessible fait partie de la correction. Annoncez l’invite, l’annulation et l’action suivante, déplacez le focus vers le message et expliquez les contrôles désactivés. Testez zoom, contraste, lecteur d’écran et noms longs.
La localisation doit garder le sens de sécurité. Traduisez fournisseur, but, annulation, expiration et récupération sans changer l’état de session. Conservez les noms officiels de l’API et traduisez les consignes autour.
Utilisez une petite table d’acceptation. Avec des comptes synthétiques, testez approbation, refus, annulation, API absente, fournisseur indisponible, état expiré, réponse invalide, conflit, déconnexion et récupération. Notez message, session, travail conservé et étape résumée.
Ne faites pas de découverte de comptes avec l’API. Une absence, un blocage et un refus peuvent produire aucun résultat mais n’ont pas le même sens. Gardez le contenu public quand la connexion est facultative et expliquez le repli quand elle est requise.
Vérifier Confidentialité Et Limites Produit
Minimisez les données. Collectez seulement les champs nécessaires, limitez la conservation et restreignez l’accès support. Un événement peut contenir étape, version, famille de navigateur, catégorie de fournisseur et résultat, sans l’objet lui-même.
N’utilisez pas la disponibilité comme empreinte. Politique, profil, fournisseur et mises à jour la changent. Elle ne prouve ni identité, ni appareil, ni lieu, ni compte et ne doit pas devenir une étiquette durable.
Contrôlez les limites d’origine et de contexte. Appelez l’API depuis l’origine prévue et utilisez une référence autorisée par serveur pour un transfert. N’exposez jamais l’identifiant dans une chaîne de requête.
Testez les changements comme des contrats visibles. Après une mise à jour du navigateur, du fournisseur, du code de compte, du consentement ou du stockage, rejouez le parcours synthétique et comparez invite, choix, validation, session, repli et suppression.
Séparez l’état du navigateur et celui du compte dans les jeux de test. Un profil propre couvre le premier usage et un profil de retour les choix stockés. Étiquetez puis supprimez les jeux selon leur objectif.
Attribuez un responsable à chaque transition. Interface, navigateur, fournisseur et serveur ont chacun leur rôle. En cas d’ambiguïté, indiquez l’étape et le responsable au lieu de relancer sans limite.
Traitez l’interruption comme normale. L’utilisateur peut fermer l’invite, perdre le réseau, recharger ou revenir après expiration. Chaque branche donne un message et une action bornée ; le nouvel essai crée un état neuf.
Expliquez le contrat au support. Distinguez identifiant du navigateur, compte fournisseur, session de la partie de confiance et référence de récupération. Demandez le plus petit identifiant masqué, jamais un mot de passe ou un profil complet.
Les mêmes limites servent à comparer les navigateurs. Gardez version, fournisseur, compte synthétique et action constants et notez seulement la branche visible et le résultat serveur. Une différence est une observation de compatibilité, pas un jugement sur la personne.
Le message présenté à l’utilisateur doit rester précis. Indiquez la branche concernée, la plage de navigateurs et le repli, ainsi que la validité des sessions. Ne promettez ni invite systématique ni identifiant toujours proposé : fournisseur, politique, profil et choix interviennent.
La responsabilité du cycle doit être visible. L’interface enregistre l’intention et conserve la tâche, le navigateur médie l’invite, le fournisseur gère son compte et le serveur valide et révoque la session. Le transfert porte une étape et une expiration brèves, jamais l’identifiant complet.
La revue de confidentialité couvre aussi l’échec. Une invite annulée, une API absente et une réponse invalide peuvent mener au même écran avec des actions différentes. Gardez le message utile et la télémétrie minimale, puis vérifiez la suppression de l’état temporaire après chaque cas négatif.
BotBrowser permet de transporter un profil de navigateur répétable entre systèmes hôtes compatibles pour revoir son propre parcours de connexion. Il ne peut pas contrôler directement la médiation de Credential Management API, n’approuve pas un identifiant fournisseur et ne remplace pas la validation serveur ni la politique de session de la partie de confiance.
Sources Publiques
Le document W3C Credential Management Level 1 est un Working Draft, et non une recommandation finale du W3C. Il décrit le conteneur et la médiation sans garantir une compatibilité définitive entre navigateurs. La référence MDN résume l’API et la compatibilité. La documentation BotBrowser des profils multiplateformes ne soutient que la revue répétable ; la disponibilité réelle doit être testée avec le contrat du navigateur, du fournisseur et du serveur.
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.