Informations FedCM: Dissocier l'API et deux mises à jour

Eiji Kitamura

À partir de Chrome 122, l'API Déconnecter pour l'API Federated Credential Management (FedCM) est disponible. L'API Disconnect permet aux parties de confiance de dissocier leurs utilisateurs du compte du fournisseur d'identité sans avoir recours aux cookies tiers. De plus, nous avons apporté quelques modifications à la gestion du même site de FedCM.

Dissocier l'API

Lorsqu'un utilisateur crée un compte sur une partie de confiance (RP, site qui utilise le fournisseur d'identité pour l'authentification) via la fédération d'identité, le fournisseur d'identité (IdP, service qui fournit l'authentification et les informations de compte à d'autres parties) enregistre généralement la connexion sur son serveur. La connexion stockée permet au fournisseur d'identité de suivre les tiers assujettis à des restrictions auxquels l'utilisateur s'est connecté et d'optimiser son expérience. Par exemple, pour une meilleure expérience lorsque l'utilisateur revient ultérieurement sur le RP, le compte utilisateur avec le fournisseur d'identité est traité comme un compte connu, ce qui permet des fonctionnalités telles que la réauthentification automatique et des boutons personnalisés affichant le compte utilisé.

Parfois, les IdP proposent une API pour dissocier le compte d'une RP. Cependant, un flux de déconnexion est authentifié et nécessite les cookies IdP. Dans un monde sans cookies tiers, lorsque l'utilisateur consulte la RP, il n'y a pas d'API de navigateur permettant à la RP de se déconnecter du fournisseur d'identité. Étant donné qu'il peut exister plusieurs comptes d'IDP du même IdP associés à un RP donné, le flux de déconnexion nécessite de savoir quel compte est déconnecté.

L'API Disconnect permet à l'utilisateur de dissocier le compte du fournisseur d'identité de l'RP dans le navigateur et sur le serveur du fournisseur d'identité en le signalant au point de terminaison spécifié. L'utilisateur doit être passé par la fédération d'identité à l'aide de l'API Federated Credential Management (FedCM). Une fois l'utilisateur déconnecté, il est considéré comme un nouvel utilisateur la prochaine fois qu'il tente de se connecter au tiers assujetti à des restrictions à l'aide du fournisseur d'identité.

Déconnecter l'IDP du RP

Si un utilisateur s'est déjà connecté au RP à l'aide de l'IdP via FedCM, la relation est mémorisée localement par le navigateur sous la forme de la liste des comptes connectés. Le RP peut déclencher une déconnexion en appelant la fonction IdentityCredential.disconnect(). Cette fonction peut être appelée à partir d'un frame RP de niveau supérieur. La RP doit transmettre un configURL, le clientId qu'il utilise sous le fournisseur d'identité et un accountHint pour que celui-ci soit déconnecté. Un indice de compte peut être une chaîne arbitraire tant que le point de terminaison de déconnexion peut identifier le compte, par exemple une adresse e-mail ou un ID utilisateur qui ne correspond pas nécessairement à l'ID de compte fourni par le point de terminaison de la liste de comptes:

// Disconnect an IdP account "account456" from the RP "https://idp.com/". This is invoked on the RP domain.
IdentityCredential.disconnect({
  configURL: "https://idp.com/config.json",
  clientId: "rp123",
  accountHint: "account456"
});

IdentityCredential.disconnect() renvoie un Promise. Cette promesse peut générer une exception pour les raisons suivantes :

  • L'utilisateur ne s'est pas connecté au tiers assujetti à des restrictions à l'aide du fournisseur d'identité via FedCM.
  • L'API est appelée à partir d'un iFrame sans stratégie d'autorisation FedCM.
  • La valeur configURL n'est pas valide ou le point de terminaison de déconnexion est manquant.
  • Échec de la vérification de la CSP (Content Security Policy).
  • Une demande de résiliation est en attente.
  • L'utilisateur a désactivé FedCM dans les paramètres du navigateur.

Lorsque le point de terminaison de déconnexion du fournisseur d'identité renvoie une réponse, la RP et le fournisseur d'identité sont déconnectés dans le navigateur, et la promesse est résolue. Les comptes utilisateur en cours de dissociation sont spécifiés dans la réponse du point de terminaison de dissociation.

Configurer le fichier de configuration de l'IdP

Pour être compatible avec l'API Disconnect, l'IdP doit prendre en charge un point de terminaison de déconnexion et fournir la propriété disconnect_endpoint et son chemin d'accès dans son fichier de configuration de l'IdP.

{
  "accounts_endpoint": "/accounts",
  "id_assertion_endpoint": "/assertion",
  ...
  "disconnect_endpoint: "/disconnect"
}

Dissocier le compte sur le point de terminaison de dissociation

En appelant IdentityCredential.disconnect(), le navigateur envoie une requête POST multi-origine avec des cookies et un type de contenu application/x-www-form-urlencoded à ce point de terminaison de déconnexion avec les informations suivantes:

Propriété Description
account_hint Indice pour le compte de l'IdP.
client_id Identifiant client du tiers assujetti à des restrictions. 
POST /disconnect HTTP/1.1
Host: idp.example
Origin: rp.example
Content-Type: application/x-www-form-urlencoded
Cookie: 0x123
Sec-Fetch-Dest: webidentity

account_hint=account456&client_id=rp123

À la réception de la requête, le serveur IdP doit:

  1. Répondre à la requête avec CORS (Cross-Origin Resource Sharing).
  2. Vérifiez que la requête contient un en-tête HTTP Sec-Fetch-Dest: webidentity.
  3. Faites correspondre l'en-tête Origin avec l'origine de la RP déterminée par le client_id. Si ce n'est pas le cas, refusez-les.
  4. Recherchez le compte correspondant à l'account_hint.
  5. Déconnectez le compte utilisateur de la liste des comptes connectés du tiers assujetti à des restrictions.
  6. Répondre au navigateur avec le account_id de l'utilisateur identifié au format JSON.

Voici un exemple de charge utile JSON de réponse :

{
  "account_id": "account456"
}

Si le fournisseur d'identité souhaite que le navigateur déconnecte tous les comptes associés à la RP, transmettez une chaîne qui ne correspond à aucun ID de compte, par exemple "*".

La vérification de /.well-known/web-identity est désormais ignorée lorsque l'RP et l'IdP sont du même site.

Lors du développement d'un système FedCM, les domaines de serveur RP de test ou de préproduction peuvent être les sous-domaines du serveur IdP de production. Par exemple, le serveur d'IdP de production se trouve sur idp.example, et le serveur de RP de préproduction et le serveur d'IdP de préproduction se trouvent sur staging.idp.example. Toutefois, comme le fichier well-known doit être placé à la racine du domaine de premier niveau étendu (eTLD+) du serveur de l'IDP, il doit se trouver à idp.example/.well-known/web-identity et il s'agit du serveur de production. Étant donné qu'il n'est pas nécessairement possible pour les développeurs de placer des fichiers dans l'environnement de production pendant le développement, cela les empêche de tester FedCM.

À partir de Chrome 122, si le domaine du RP et le domaine de l'IdP sont identiques, Chrome ignore la vérification du fichier connu. De cette façon, les développeurs pourront tester dans un tel scénario.

Les sous-ressources peuvent désormais définir l'état de connexion sur le même site

Auparavant, Chrome n'autorisait que le paramétrage de l'état de connexion (par exemple, à l'aide de l'en-tête Set-Login: logged-in) lorsque la requête est de la même origine avec tous les ancêtres. Cela empêchait les connexions via les requêtes fetch() de même site qui définissent l'état de connexion.

Prenons l'exemple d'un site Web qui permet aux utilisateurs de saisir leur nom d'utilisateur et leur mot de passe sur idp.example, mais qui sont publiés sur login.idp.example avec fetch(). L'enregistrement de l'état de connexion dans le navigateur à l'aide de l'API Login Status n'était pas possible, car les deux domaines sont inter-origines et du même site.

Avec cette modification, nous avons assoupli l'exigence selon laquelle l'API Login Status doit être le même site que tous les ancêtres. L'exemple ci-dessus permet également de définir l'état de connexion de login.idp.example à l'aide d'un en-tête HTTP (Set-Login: logged-in).

Résumé

Grâce à l'API Disconnect, FedCM peut désormais dissocier le RP de l'IDP sans s'appuyer sur des cookies tiers. Pour ce faire, appelez IdentityCredential.disconnect() sur la RP. Avec cette fonction, le navigateur envoie une requête au point de terminaison de déconnexion de l'IDP afin que l'IDP puisse mettre fin à la connexion sur le serveur, puis sur le navigateur.

À des fins de test, nous avons annoncé que la vérification /.well-known/web-identity était ignorée lorsque le tiers assujetti à des restrictions et le fournisseur d'identité étaient le même site. De plus, il est désormais possible de définir un état de connexion via un en-tête de réponse HTTP à partir de la sous-ressource d'IdP sur le même site.