Mises à jour de l'API Federated Credential Management

L'API Federated Credential Management est livrée dans Chrome 108, mais elle devrait continuer à évoluer. Aucune modification importante n'est prévue.

À qui s'adressent ces mises à jour ?

Ces mises à jour sont destinées à vous si:

  • Vous êtes un IdP qui utilise l'API Federated Credential Management.
  • Vous êtes un IdP ou un RP et vous souhaitez étendre l'API pour qu'elle corresponde à votre cas d'utilisation. Par exemple, vous avez observé ou participé aux discussions sur le dépôt FedID CG et vous souhaitez comprendre les modifications apportées à l'API.
  • Vous êtes fournisseur de navigateurs et vous souhaitez vous renseigner sur l'état de l'implémentation de l'API.

Si vous ne connaissez pas cette API ou si vous ne l'avez pas encore testée, consultez la présentation de l'API Federated Credential Management.

Journal des modifications

Pour vous tenir informé des modifications apportées à l'API FedCM, consultez notre blog ou la newsletter.

Chrome 131 (octobre 2024)

Chrome 125 (avril 2024)

Chrome 123 (février 2024)

  • Ajout de la prise en charge de l'API Domain Hint. L'API Domain Hint permet aux RP de spécifier une propriété domainHint sur un appel d'API FedCM afin de n'afficher que les comptes correspondants pour l'utilisateur.

Chrome 122 (janvier 2024)

  • Ajout de la prise en charge de l'API Disconnect. L'API Disconnect permet aux RP de dissocier leurs utilisateurs du compte de l'IDP sans avoir à utiliser des cookies tiers.
  • La vérification de /.well-known/web-identity est désormais ignorée lorsque l'RP et l'IdP sont du même site.
  • Les sous-ressources peuvent désormais définir un état de connexion sur le même site.

Chrome 121 (décembre 2023)

  • Condition allégée pour déclencher la réauthentification automatique FedCM :
    • La fonctionnalité de réauthentification automatique dans FedCM ne se déclenche que lorsque l'utilisateur revient. Cela signifie que l'utilisateur doit se connecter à l'RP à l'aide de FedCM une fois dans chaque instance de navigateur avant que la réautorisation automatique puisse être déclenchée. Cette condition a été initialement introduite pour atténuer le risque que des outils de suivi se fassent passer pour un fournisseur d'identité (IdP) et trompent le navigateur pour qu'il réauthentifie automatiquement un utilisateur à son insu ou sans son autorisation. Toutefois, cette conception ne peut pas garantir l'avantage en termes de confidentialité si le traceur a accès aux cookies tiers dans le contexte RP. FedCM ne fournit qu'un sous-ensemble des fonctionnalités possibles via les cookies tiers. Par conséquent, si le traceur a déjà accès aux cookies tiers dans le contexte RP, l'accès à FedCM ne présente aucun risque de confidentialité supplémentaire.
      Étant donné que les cookies tiers peuvent être utilisés de manière légitime et que l'assouplissement de la condition améliorerait l'expérience utilisateur, ce comportement change à partir de Chrome 121. Nous avons décidé d'assouplir la restriction de la condition pour traiter un utilisateur comme un utilisateur de retour: si des cookies tiers sont disponibles pour l'IdP dans le contexte de l'RP, Chrome fera confiance à la revendication de l'IdP concernant l'état du compte de l'utilisateur spécifié via la liste approved_clients et déclenchera une réauthentification automatique, le cas échéant. Les cookies tiers peuvent être disponibles via les paramètres utilisateur, les règles d'entreprise, les heuristiques (Safari, Firefox, Chrome) et d'autres API de plate-forme Web (telles que l'API Storage Access). Notez que lorsque l'IDP perd l'accès aux cookies tiers à l'avenir, si un utilisateur n'a jamais explicitement accordé d'autorisation dans l'interface utilisateur FedCM (par exemple, en cliquant sur le bouton Continuer en tant que), il sera toujours traité comme un nouvel utilisateur.
      Aucune action n'est requise de la part du développeur. Notez que le flux de réauthentification automatique peut être déclenché plus souvent avec ce changement si l'IDP a accès aux cookies tiers et affirme que l'utilisateur a déjà créé un compte sur le RP.

Chrome 120 (novembre 2023)

  • Prise en charge des trois fonctionnalités suivantes dans Chrome 120 :
    • API Login Status: l'API Login Status est un mécanisme par lequel un site Web, en particulier un IdP, informe le navigateur de l'état de connexion de son utilisateur. Avec cette API, le navigateur peut réduire les requêtes inutiles à l'IDP et atténuer les attaques par cassage de chiffrement. L'API Login Status est obligatoire pour FedCM. Avec ce changement, l'indicateur chrome://flags/#fedcm-without-third-party-cookies n'est plus nécessaire pour activer FedCM lorsque le cookie tiers est bloqué.
    • API d'erreur: l'API d'erreur avertit l'utilisateur en affichant une UI de navigateur avec les informations d'erreur fournies par l'IDP.
    • API Auto-Selected Flag: l'API Auto-Selected Flag indique si une autorisation explicite de l'utilisateur a été obtenue en appuyant sur le bouton Continuer en tant que avec l'IDP et le RP, chaque fois qu'une réauthentification automatique ou une médiation explicite s'est produite. Le partage ne se produit que lorsque l'utilisateur autorise la communication entre l'IDP et le RP.

Chrome 117 (septembre 2023)

Chrome 116 (août 2023)

  • Ajout de compatibilité avec les trois fonctionnalités suivantes dans Chrome 116 :
    • API Login Hint: spécifiez le compte utilisateur préféré à utiliser pour la connexion.
    • API User Info: récupérez les informations de l'utilisateur qui revient afin que le fournisseur d'identité (IdP) puisse afficher un bouton de connexion personnalisé dans une iframe.
    • API RP Context: utilisez un titre autre que "Se connecter" dans la boîte de dialogue FedCM.
  • La phase d'évaluation de l'API IdP Sign-In Status est disponible. Pour en savoir plus, consultez Mises à jour de FedCM: API d'état de connexion de l'IDP, indice de connexion et plus.

Chrome 115 (juin 2023)

  • Prise en charge de la réauthentification automatique, qui permet aux utilisateurs de se réauthentifier automatiquement lorsqu'ils reviennent après leur authentification initiale à l'aide de FedCM. Cela améliore l'expérience utilisateur et permet une réauthentification plus simple auprès de l'RP après l'authentification initiale. En savoir plus sur la réauthentification automatique FedCM

Chrome 110 (février 2023)

  • Pour le point de terminaison d'assertion d'identité, les IdP doivent vérifier l'en-tête Origin (au lieu de l'en-tête Referer) pour voir si la valeur correspond à l'origine de l'ID client.
  • La prise en charge des iframes inter-origines pour FedCM est désormais disponible. L'intégrateur doit spécifier le identity-credentials-get Permissions-Policy pour autoriser l'API FedCM dans l'iframe inter-origine intégrée. Vous pouvez consulter un exemple d'iFrame cross-origin.
  • Ajout d'un nouvel indicateur Chrome chrome://flags/#fedcm-without-third-party-cookies. Avec cet indicateur, vous pouvez tester la fonctionnalité FedCM dans Chrome en bloquant les cookies tiers. Pour en savoir plus, consultez la documentation FedCM.

Chrome 108 (octobre 2022)

  • Le "fichier manifeste de niveau supérieur" s'appelle désormais "fichier connu" dans le document. Aucune modification d'implémentation n'est requise.
  • Le "fichier manifeste de l'IDP" est désormais appelé "fichier de configuration" dans le document. Aucune modification d'implémentation n'est requise.
  • Le id_token_endpoint du "fichier de configuration" est renommé id_assertion_endpoint.
  • Les requêtes envoyées à l'IDP incluent désormais un en-tête Sec-Fetch-Dest: webidentity au lieu d'un en-tête Sec-FedCM-CSRF: ?1.

Chrome 105 (août 2022)

  • Ajout d'informations de sécurité importantes au document. Le fournisseur d'identité (IdP) doit vérifier si l'en-tête Referer correspond à l'origine que le RP a enregistrée à l'avance sur le point de terminaison du jeton d'ID.
  • Le fichier manifeste de premier niveau est renommé de /.well-known/fedcm.json en /.well-known/web-identity, et l'URL spécifiée dans provider_urls doit inclure le nom du fichier.
  • Les méthodes login(), logout() et revoke() sur les instances FederatedCredential ne sont plus disponibles.
  • L'API Federated Credential Management utilise désormais un nouveau type IdentityCredential au lieu de FederatedCredential. Cela peut être utilisé pour la détection de fonctionnalités, mais il s'agit d'un changement largement invisible.
  • Déplacez la fonctionnalité de connexion d'une combinaison de navigator.credentials.get() et FederatedCredential.prototype.login() vers navigator.credentials.get().
  • Le point de terminaison de révocation du fichier manifeste n'est plus en vigueur.
  • Utilisez un champ identity au lieu d'un champ federated pour les appels navigator.credentials.get().
  • url est désormais configURL et doit être l'URL complète du fichier manifeste JSON au lieu du chemin d'accès d'un appel navigator.credentials.get().
  • nonce est désormais un paramètre facultatif pour navigator.credentials.get().
  • hint n'est plus disponible comme option pour navigator.credentials.get().
const credential = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/anything.json',
      clientId: '********',
      nonce: '******'
    }]
  }
});
const { token } = credential;

Chrome 104 (juin 2022)

Chrome 103 (mai 2022)

  • Compatible avec les environnements de bureau.
  • Prise en charge des paramètres par RP sur ordinateur.
  • Le point de terminaison des métadonnées client est désormais facultatif. Dans ce point de terminaison, l'URL des règles de confidentialité est également facultative.
  • Ajout d'une mise en garde concernant l'utilisation de connect-src CSP dans le document.

Ressources