FedCM et confidentialité du navigateur : parcours de compte

Federated Credential Management, ou FedCM, fournit un parcours médié par le navigateur pour qu’un fournisseur d’identité aide un site dépendant à ouvrir une session. Selon le compte et l’autorisation antérieure, le navigateur peut demander à l’utilisateur de choisir ou d’approuver un compte; un utilisateur récurrent éligible peut être réauthentifié automatiquement sans le même sélecteur. L’application doit distinguer première approbation et retour, sans supposer que chaque parcours affiche un sélecteur de comptes. Le site n’a pas besoin de traiter le fournisseur intégré comme un magasin de cookies tiers sans limite.

FedCM est une API d’identité, pas un bouton de connexion universel ni un moyen de reconnaître un navigateur inconnu. La disponibilité dépend du compte, du choix utilisateur, des réglages et de la politique du fournisseur. Définissez le parcours et son recours avant l’intégration, pour une relation autorisée par les services et l’utilisateur.

Reliez chaque parcours public à l’algorithme actuel de connexion RP de la spécification FedCM du W3C : la requête signin et l’identifiant retourné y sont définis; la création initiale est décrite par demander l’autorisation d’inscription; la réauthentification automatique d’un compte de retour est la branche du même algorithme pour un compte éligible. Le lecteur peut vérifier la limite en notant si le test a utilisé signin, si une surface d’autorisation est apparue, si IdentityCredential.isAutoSelected valait true et si le serveur a accepté audience et la durée. Aucune observation ne suffit à autoriser un compte, et l’absence d’invite ne prouve ni une personne ni un appareil inconnus.

Ce que change la médiation du navigateur

Un parcours fédéré classique redirige vers le fournisseur ou intègre son contenu. Le fournisseur intégré pouvait autrefois dépendre de cookies tiers pour retenir une session. FedCM place la sélection du compte et une partie de l’échange dans une surface contrôlée par le navigateur et approuvée par l’utilisateur.

Le navigateur ne décide pas de l’autorisation applicative. Le serveur du site dépendant vérifie issuer, audience, durée, liaison de requête et signature, puis applique ses règles de compte. Une invite acceptée ne prouve pas le droit d’accès et son absence ne décrit ni personne ni appareil.

Le sélecteur de compte est une limite visible. Expliquez quel fournisseur intervient, quelle relation sera créée et ce que signifie un refus. Ne cachez pas le refus derrière des redirections répétées et ne rendez pas le contenu public dépendant d’une identité.

FedCM ne rend pas toutes les requêtes privées. Le site traite le résultat et sa session, tandis que le fournisseur exploite son service de compte. Examinez URL, corps, journaux, analyses, support, redirections et suppression. La surface de choix ne remplace pas la minimisation.

API, inscription et affichage évoluent selon les versions. Notez les versions testées et le contrat du fournisseur. Ne dites pas que tous les navigateurs montrent les mêmes champs; nommez le parcours réellement vérifié et sa solution de repli.

Définir le contrat du site dépendant

Commencez par le parcours utilisateur : emplacement du contrôle, comptes offerts, texte de divulgation et état à conserver après annulation ou nouvel essai. L’assertion doit accomplir une tâche visible et limitée, comme créer ou lier une session.

La liaison doit être explicite. Si une session locale existe, dites si le nouveau compte se connecte, se lie ou remplace l’ancien. Demandez une action avant de fusionner et préservez le travail en cas de conflit.

Le serveur vérifie issuer, audience, nonce ou liaison, expiration et signature. Limitez les échanges échoués et traitez la relecture de façon déterministe. Conservez seulement l’étape d’échec sous forme masquée, pas le jeton entier.

La session a une durée définie. Faites tourner ou révoquez l’état lors d’un changement de compte et fournissez un vrai bouton de sortie. Le sélecteur du navigateur ne remplace ni logout, ni récupération, ni contrôle de permission.

Plusieurs fournisseurs peuvent être proposés. Présentez leurs différences en termes compréhensibles et indiquez s’ils créent des comptes séparés ou liables. Un fournisseur indisponible ne doit pas bloquer une solution locale déjà autorisée; ne rouvrez pas sans fin une invite refusée.

Consentement, divulgation et contrôle

La première invite répond à trois questions : qui demande, quel compte sera utilisé et quelle action suivra. Placez l’explication près du bouton. Nom et avatar servent uniquement le but annoncé et l’utilisateur peut corriger un compte inattendu.

Le consentement ne couvre pas toutes les opérations futures. Demandez-le à nouveau si finalité, lien ou données changent. Gardez l’enregistrement minimal, permettez de révoquer la session ou de délier le compte, et distinguez choix mémorisé par le navigateur et preuve de consentement du produit.

Un refus est normal. Gardez les fonctions publiques utilisables et affichez une connexion locale ou une récupération si elles existent. N’accusez pas le navigateur et ne forcez pas une identité pour lire un contenu public.

Le choix de compte peut révéler un contexte sensible. N’écrivez pas identifiants, jetons ou profil détaillé dans URL, captures, étiquettes analytiques ou exceptions. Utilisez des comptes synthétiques et supprimez les fixtures temporaires.

Expliquez la sortie. Se déconnecter du site peut laisser le fournisseur connecté, tandis que délier la relation est une autre action. Distinguez-les et renvoyez aux contrôles du fournisseur lorsque nécessaire.

Cookies tiers et limites du stockage

FedCM réduit la dépendance aux cookies tiers sans créer une exception générale de stockage. Le fournisseur ne doit pas présumer qu’un cookie d’iframe est lisible après approbation. Le site garde sa session et le fournisseur documente sa route de première partie.

Le partitionnement peut faire paraître le fournisseur nouveau sous un autre site supérieur. C’est un contexte, pas une identité. Le guide du partitionnement présente l’état vide et le handoff contrôlé par l’utilisateur.

N’utilisez pas le résultat FedCM comme fingerprint. L’absence d’invite peut venir du navigateur, du compte, du réglage, de la permission, de la politique ou de la version. Décidez selon la fonction visible, non selon des propriétés ou des durées.

Les signaux réseau doivent être étudiés séparément. Fournisseur et site voient le contexte nécessaire à leurs requêtes. Le guide sur l’identité réseau explique pourquoi une connexion n’est pas une identité réseau stable.

La suppression couvre les deux côtés. Le site efface session et lien selon sa politique; le fournisseur propose son propre retrait. Séparez les traces d’audit obligatoires des données supprimables et ne gardez pas une assertion complète par simple usage de FedCM.

Construire un recours résilient

Un parcours solide combine voie médiée, voie de première partie du fournisseur et récupération approuvée. Le recours n’est pas un contournement de politique : il aide l’utilisateur quand l’API manque, quand il refuse ou quand le compte demande une aide.

La voie de première partie utilise un handoff court et autorisé par serveur. Aucune credential dans l’URL; liez la référence au site, à l’action et à l’expiration, puis invalidez-la après usage. Après annulation, gardez le brouillon et revenez à une page connue.

La récupération a un responsable et des limites. Proposez recherche, credential locale ou vérification seulement si le produit les autorise. Ne demandez pas l’historique de navigation ni la désactivation de la confidentialité. Dites si la session est créée et si le travail est conservé.

Classez l’échec avant de réessayer : API absente, compte indisponible, refus, assertion invalide, handoff expiré et délai réseau ont des responsables distincts. Notez étape, révision, famille et version du navigateur, catégorie du fournisseur et résultat visible.

Chaque branche possède un état accessible. Un lecteur doit savoir que le choix est disponible, annulé ou qu’une récupération est nécessaire. Placez le focus sur le titre ou l’erreur utile et expliquez tout contrôle désactivé avec son alternative.

Matrice d’acceptation du parcours de compte et du recours

Prenez comme sources du protocole l’algorithme de connexion du site dépendant du W3C et la référence MDN de l’API FedCM. Exécutez chaque ligne avec des comptes synthétiques et acceptez-la seulement si le résultat observable respecte le contrat de l’application.

Condition observable de départ	Action principale	Recours visible pour l’utilisateur	Preuve d’acceptation
FedCM est indisponible ou le fournisseur ne peut proposer de compte	N’ouvrez pas de sélecteur	Proposez la voie de première partie du fournisseur ou la récupération approuvée	Aucune credential n’est envoyée; la page de recours est annoncée; aucune session du site n’existe avant validation serveur
L’utilisateur refuse le sélecteur	Terminez la tentative FedCM	Gardez le contenu public et affichez la connexion locale ou la récupération	L’événement indique declined; le travail en cours est conservé; aucune session n’est créée
L’utilisateur annule, le handoff expire ou le serveur dépasse le délai	Arrêtez l’échange et invalidez la référence	Revenez à la page connue avec une nouvelle tentative limitée	La page indique que la connexion n’est pas terminée, le brouillon est conservé et la tentative ne réutilise pas la référence expirée
L’assertion échoue sur issuer, audience, nonce, signature ou expiration	Refusez la réponse côté serveur	Affichez le recours approuvé	Le serveur renvoie un résultat d’échec, conserve seulement l’étape désidentifiée et l’interface ne dit jamais que la connexion a réussi
Le compte renvoyé entre en conflit avec le compte local connecté	Ne liez ni ne remplacez automatiquement les comptes	Demandez de choisir explicitement l’association, le changement ou la récupération	Le travail et la session restent inchangés jusqu’à confirmation; la session finale correspond à un seul compte

Parcours d’acceptation de bout en bout

Utilisez l’algorithme W3C et la référence API MDN ci-dessus comme sources des étapes du navigateur, et la configuration documentée du fournisseur comme source d’éligibilité. Dans un parcours normal, l’utilisateur choisit Se connecter, le site appelle FedCM depuis un profil de test vierge et le fournisseur configuré propose un compte synthétique. Le navigateur affiche le sélecteur; après accord, le site envoie l’assertion au serveur. Celui-ci vérifie issuer, audience, nonce, signature et expiration, crée exactement une session du site, puis rend la tâche enregistrée avec un message accessible. Le paquet de preuve contient étape, catégorie du fournisseur, résultat de validation, résultat de session et message visible, jamais l’assertion.

Utilisez des essais négatifs contrôlés pour identifier le responsable :

Résultat observé	Comment le distinguer	Résultat d’acceptation requis
API indisponible	navigator.credentials ou la méthode FedCM manque ou est bloquée avant toute demande au fournisseur	Aucun sélecteur ni échange de credential; affichez la voie de première partie approuvée et notez api_unavailable
Refus de l’utilisateur	Le sélecteur était affiché et l’utilisateur synthétique a annulé ou refusé	Notez declined; gardez la tâche; ne créez aucune session; proposez connexion locale ou récupération
Configuration du fournisseur	L’API est appelable, mais le fournisseur n’est pas éligible ou ne peut proposer le compte de test configuré	Notez provider_not_configured ou provider_account_unavailable; n’envoyez aucune assertion pour créer une session; affichez la voie fournisseur ou la récupération
Validation serveur de l’assertion	Le résultat du sélecteur atteint le serveur, mais issuer, audience, nonce, signature ou expiration échoue	Renvoyez un échec, notez seulement l’étape désidentifiée, ne créez aucune session et affichez la récupération

Le test réussit seulement si l’étiquette de branche, le comportement réseau, l’état de session serveur, le travail conservé et le message visible concordent. Cette distinction sépare capacité du navigateur, choix de l’utilisateur, configuration du fournisseur et décision de confiance du serveur, sans transformer un résultat en signal d’identité.

Tester avec des comptes synthétiques

Utilisez des comptes de fournisseur et de site créés pour le test. Vérifiez séparément profil vierge et profil récurrent. N’ajoutez ni adresses personnelles, ni assertions de production, ni codes réels; définissez les responsables de suppression des deux côtés.

Parcourez ouverture, sélecteur, approbation, refus, annulation, retour, réauthentification automatique autorisée, sortie et récupération. Vérifiez le résultat visible et la session créée par le serveur, pas seulement un callback JavaScript. Le test de retour contrôle séparément l’autorisation antérieure, la présence ou l’absence du sélecteur et la session serveur. Le résultat doit être annoncé de manière accessible.

Ajoutez deux comptes, un compte déjà lié à un autre utilisateur local, une session fournisseur expirée et un compte non proposé. Le site ne doit ni remplacer le travail ni fusionner silencieusement des enregistrements.

Comparez les navigateurs avec la même révision, configuration et données. Notez disponibilité, invite, action, résultat serveur et recours. Une différence de version met à jour la matrice de support, pas une loi universelle.

Testez fermeture du sélecteur, rechargement pendant le callback, perte réseau, expiration du handoff et redémarrage. Évitez les sessions doubles, gardez l’entrée non sensible et limitez le nouvel essai. Un échange échoué n’est jamais un accès réussi.

En automatisation, un seul propriétaire gère le profil par session. Le guide Selenium couvre isolation, versions et fermeture. Les assertions FedCM restent au niveau de l’application, pas dans une liste de fingerprint.

Revue de version et exploitation

Rejouez le parcours quand navigateur, fournisseur, code, liaison, consentement ou stockage changent. Gardez des fixtures courtes pour première approbation, refus et recours, compte récurrent, conflit et récupération.

Les notes de version nomment le parcours touché et l’action utilisateur. Un changement d’invite n’est pas une conclusion sur toutes les plateformes. Si un recours temporaire existe, donnez la plage concernée et la manière de continuer.

Les tableaux de bord rapportent des événements fonctionnels : approbation, refus, échange, motif de recours, récupération et révision. Limitez rétention et accès; les agrégats ne doivent pas reconstituer une identité intersite.

En incident, préservez le travail. Après une validation échouée, gardez le formulaire permis, expliquez l’état et proposez la récupération. Ne commencez pas par copier cookies ou profils; capturez une preuve minimale et retirez la fixture ensuite.

Vérifiez régulièrement sortie, retrait du lien et suppression. La sortie termine la session du site, le retrait actualise la relation et un handoff expiré ne fonctionne plus. Testez profil vierge et récurrent.

Le support doit employer les mêmes termes que l’interface : compte fournisseur, session du site, compte local lié et référence de récupération. Demandez seulement l’identifiant synthétique ou masqué qui situe l’étape.

Accessibilité et localisation font partie du contrat. Traduisez nom, objectif, refus et récupération sans changer le sens. Testez noms longs, RTL quand pris en charge, zoom, mouvement réduit et clavier.

L’intégration doit être réversible. Si une version change la disponibilité, désactivez la voie principale pour un public borné et gardez le recours approuvé. Notez changement, parcours et action utilisateur.

Sources publiques

Le document FedCM du W3C indiqué ici est un premier brouillon public de travail, et la page MDN de l'API qualifie sa compatibilité de limitée et expérimentale. Utilisez ces pages comme références du protocole et de la compatibilité, puis vérifiez le fournisseur, la version du navigateur et le contrat serveur réellement pris en charge par l'application.

• MDN : Federated Credential Management API
• Spécification W3C FedCM : connexion du site dépendant
• Chrome for Developers : Federated Credential Management