L'API Federated Credential Management est disponible

L'API Federated Credential Management (FedCM) est disponible dans Chrome 108 (actuellement en version bêta). Lorsqu'elle sera disponible dans la version stable de Chrome à la fin du mois de novembre 2022, l'API FedCM fonctionnera dans Chrome sans nécessiter d'indicateur ni de jeton d'évaluation.

FedCM est une API Privacy Sandbox qui fournit une abstraction spécifique à un cas d'utilisation pour les flux d'identité fédérée sur le Web. FedCM propose des boîtes de dialogue gérées par un navigateur, qui permettent aux utilisateurs de choisir les comptes des fournisseurs d'identité pour se connecter aux sites Web.

Consultez les dernières modifications de l'API sur la page des mises à jour cumulées.

Nous prévoyons d'introduire un certain nombre de nouvelles fonctionnalités en fonction des commentaires que nous avons reçus des fournisseurs d'identité (IdP), des tiers de confiance (RP) et des fournisseurs de navigateurs. Nous espérons que les fournisseurs d'identité adopteront FedCM. Toutefois, veuillez noter que FedCM est encore une API en cours de développement et que des modifications susceptibles d'affecter la rétrocompatibilité sont prévues jusqu'au 4e trimestre 2023.

Pour réduire les difficultés liées au déploiement de modifications avec incompatibilité ascendante, nous recommandons actuellement deux recommandations pour les fournisseurs d'identité:

  • Abonnez-vous à notre newsletter pour recevoir des informations à mesure que l'API évolue.
  • Nous encourageons vivement les fournisseurs d'identité à distribuer l'API FedCM via des SDK JavaScript pendant que l'API arrive à maturité, et à dissuader les RP d'utiliser les SDK d'auto-hébergement. Cela permettra aux fournisseurs d'identité d'apporter des modifications à mesure que l'API évolue, sans avoir à demander à toutes leurs parties de confiance de procéder au redéploiement.

Contexte

Au cours de la dernière décennie, la fédération d'identité a joué un rôle central dans le renforcement de l'authentification sur le Web, en termes de fiabilité, de facilité d'utilisation (par exemple, authentification unique sans mot de passe) et de sécurité (par exemple, une meilleure résistance aux attaques par hameçonnage et credential stuffing) par rapport aux noms d'utilisateur et aux mots de passe par site.

Malheureusement, les mécanismes sur lesquels s'appuie la fédération d'identité (iFrame, redirections et cookies) sont activement détournés pour suivre les utilisateurs sur le Web. Comme le user-agent ne peut pas faire la différence entre la fédération d'identité et le suivi, les mesures d'atténuation des différents types d'abus rendent le déploiement de la fédération d'identité plus difficile.

FedCM est un parcours en plusieurs étapes visant à améliorer l'identité sur le Web. La première étape consiste à réduire l'impact de l'abandon progressif des cookies tiers sur l'identité fédérée (voir la section Étapes suivantes ci-dessous).

Un utilisateur se connecte à un tiers assujetti à des restrictions à l'aide de FedCM

Chrome teste FedCM depuis Chrome 101.

L'équipe Google Identity Services a participé à la phase d'évaluation et a démontré que le passage à un processus de connexion plus privé et sécurisé qui ne s'appuie pas sur des cookies tiers peut se faire de manière transparente grâce à des mises à jour rétrocompatibles de sa bibliothèque existante. Ils ont permis à FedCM de faire appel à 20 tiers de confiance différents et à plus de 300 000 utilisateurs s'y sont connectés pendant les phases d'évaluation. Découvrez comment l'entreprise prévoit de ne plus dépendre des cookies tiers.

Nous sommes ravis de trouver de nombreux points d'entente avec Mozilla, qui a participé activement à des discussions sur la conception et a commencé le prototypage de FedCM dans Firefox. Apple a indiqué s'il est généralement compatible avec la spécification et commence à participer aux discussions au sein de la CG FedID.

Étapes suivantes

Nous travaillons actuellement à l'élaboration d'un certain nombre de modifications apportées à FedCM.

Nous savons que certaines choses doivent encore être faites, y compris les problèmes que nous avons entendus par les fournisseurs d'identité, les tiers assujettis à des restrictions et les fournisseurs de navigateurs. Nous pensons savoir comment résoudre ces problèmes:

  • Compatibilité avec les iFrame multi-origines: les fournisseurs d'identité peuvent appeler FedCM à partir d'un iFrame multi-origine.
  • Bouton personnalisé: les fournisseurs d'identité peuvent afficher l'identité d'un utilisateur connu sur le bouton de connexion à partir d'un iFrame multi-origine.
  • Metrics endpoint (Point de terminaison des métriques) : fournit des métriques de performances aux fournisseurs d'identité.

De plus, nous étudions activement certains problèmes non résolus, y compris des propositions spécifiques que nous évaluons ou prototypons:

Enfin, nous pensons que certaines choses doivent encore être faites, d'après les commentaires de Mozilla, d'Apple et des examinateurs TAG. Nous nous efforçons de trouver la meilleure solution aux questions ouvertes suivantes:

  • Améliorer la compréhension des utilisateurs et la mise en correspondance de l'intention: comme Mozilla l'a indiqué, nous aimerions continuer à explorer différentes formulations et surfaces de l'expérience utilisateur, ainsi que différents critères de déclenchement.
  • Attributs d'identité et divulgation sélective: comme l'ont indiqué les examinateurs de notre TAG, nous souhaitons fournir un mécanisme permettant de partager de manière sélective plus ou moins d'attributs d'identité (tels que des adresses e-mail, des tranches d'âge, des numéros de téléphone, etc.).
  • Améliorer les propriétés de confidentialité: comme Mozilla l'a suggéré ici, nous aimerions continuer à explorer des mécanismes permettant d'offrir de meilleures garanties de confidentialité, telles que l'aveuglement de l'IdP et les identifiants orientés.
  • Relation avec WebAuthn: comme suggéré par Apple, nous sommes ravis de constater les progrès réalisés au niveau des clés d'accès, et de travailler à fournir une expérience cohérente entre FedCM, les mots de passe, WebAuthn et WebOTP.
  • État de la connexion: comme Apple l'a suggéré dans l'API Login Status de la Privacy CG, nous partons du principe que l'état de connexion de l'utilisateur est une information utile qui peut aider les navigateurs à prendre des décisions éclairées. Nous sommes impatients de voir les opportunités qui en découlent.
  • Entreprises et éducation: comme indiqué dans le CG FedID, il existe encore de nombreux cas d'utilisation qui ne sont pas bien adaptés à FedCM et sur lesquels nous aimerions travailler, tels que la déconnexion de canal frontal (la possibilité pour un fournisseur d'identité d'envoyer un signal aux tiers assujettis à des restrictions de se déconnecter) et la compatibilité avec SAML.
  • Relation avec les mDL, les VC et d'autres plates-formes: poursuivez vos efforts pour comprendre comment ils s'intègrent à FedCM, par exemple avec l'API Mobile Document Request.

Ressources