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

Eiji Kitamura

À partir de Chrome 122, l'API Disconnect 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 à l'IDP de suivre les RP auxquels l'utilisateur s'est connecté et d'optimiser son expérience. Par exemple, pour améliorer l'expérience lorsque l'utilisateur revient ultérieurement sur la RP, le compte utilisateur avec l'IdP est traité comme un compte de retour, ce qui permet d'utiliser des fonctionnalités telles que la réauthentification automatique et les boutons personnalisés affichant le compte utilisé.

Parfois, les IdP proposent une API pour dissocier le compte d'une RP. Toutefois, un flux de déconnexion est authentifié et nécessite les cookies de l'IDP. Dans un monde sans cookies tiers, lorsque l'utilisateur accède à la RP, il n'existe aucune API de navigateur permettant à la RP de se déconnecter de l'IDP. É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 en cours de déconnexion.

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 avoir effectué la fédération d'identité à l'aide de l'API FedCM (Federated Credential Management). Une fois l'utilisateur déconnecté, il est traité comme un nouvel utilisateur la prochaine fois qu'il tente de se connecter à la RP à 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. Le RP doit transmettre un configURL, le clientId qu'il utilise sous l'IdP et un accountHint pour que l'IdP 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 RP à l'aide de l'IdP 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 Content Security Policy (CSP).
  • Une demande de déconnexion est en attente.
  • L'utilisateur a désactivé FedCM dans les paramètres du navigateur.

Lorsque le point de terminaison de déconnexion de l'IDP renvoie une réponse, le RP et l'IDP 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 inter-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 IdP.
client_id Identifiant client de l'RP. 
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

Une fois la requête reçue, le serveur de l'IDP doit:

  1. Répondez à la requête avec le partage de ressources entre origines (CORS).
  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 à l'origine du RP déterminée par client_id. Refusez-les si elles ne correspondent pas.
  4. Recherchez le compte correspondant à account_hint.
  5. Déconnectez le compte utilisateur de la liste des comptes connectés du RP.
  6. Répondez au navigateur avec l'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 dissocie tous les comptes associés au 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 d'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 bien connu doit être placé à la racine de l'eTLD+1 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. Les développeurs pourront ainsi effectuer des tests dans ce 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.

Par exemple, imaginons un site Web qui permet aux utilisateurs de saisir leur nom d'utilisateur et leur mot de passe sur idp.example, mais que les identifiants 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 ce changement, nous avons assoupli l'exigence selon laquelle l'API Login Status doit être du même site avec tous les ancêtres. L'exemple ci-dessus permet ainsi 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 le 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.

Nous avons annoncé que la vérification /.well-known/web-identity est ignorée lorsque le RP et l'IDP sont sur le même site, à des fins de test. Il est également possible de définir un état de connexion via un en-tête de réponse HTTP à partir de la sous-ressource de l'IDP sur le même site.