Depuis Chrome 122, l'API Déconnecter pour l'API Federated Credential Management (FedCM) est disponible. Elle permet aux tiers de confiance de déconnecter leurs utilisateurs du compte du fournisseur d'identité sans utiliser de cookies tiers. Quelques mises à jour ont également été apportées au traitement sur le même site de FedCM.
API Déconnecter
Lorsqu'un utilisateur crée un compte sur une partie de confiance (RP, le 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 des informations d'authentification et 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 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 le tiers assujetti à des restrictions, le compte utilisateur associé au fournisseur d'identité est traité comme un compte connu, ce qui permet d'utiliser des fonctionnalités telles que la réauthentification automatique et des boutons personnalisés indiquant le compte utilisé.
Parfois, les IdP proposent une API pour déconnecter le compte d'un tiers assujetti à des restrictions. Toutefois, un flux de déconnexion est authentifié et nécessite les cookies du fournisseur d'identité. Dans un monde sans cookies tiers, lorsque l'utilisateur accède au tiers assujetti à des restrictions, aucune API de navigateur ne permet à la RP de se déconnecter du fournisseur d'identité. Étant donné qu'il peut y avoir plusieurs comptes d'un même IdP associés à une RP donnée, le flux de déconnexion nécessite de savoir quel compte est déconnecté.
L'API Déconnecter permet à l'utilisateur de déconnecter le compte de l'IdP du RP dans le navigateur ainsi que sur le serveur IdP en le signalant au point de terminaison spécifié. L'utilisateur doit avoir procédé à 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 RP à l'aide du fournisseur d'identité.
Déconnecter l'IdP du RP
Si un utilisateur s'est déjà connecté au tiers assujetti à des restrictions à l'aide du fournisseur d'identité via FedCM, la relation est mémorisée par le navigateur localement sous forme de liste de comptes connectés. Le RP peut initier une déconnexion en appelant la fonction IdentityCredential.disconnect(). Cette fonction peut être appelée
à partir d'une trame RP de premier niveau. Le RP doit transmettre un configURL, le clientId qu'il utilise sous le fournisseur d'identité et un accountHint pour que le fournisseur d'identité soit déconnecté. Un indice de compte peut correspondre à une chaîne arbitraire, à condition que le point de terminaison de déconnexion puisse identifier le compte. Il peut s'agir, par exemple, d'une adresse e-mail ou d'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 depuis un iFrame sans règle d'autorisation FedCM.
- Le 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 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 du fournisseur d'identité renvoie une réponse, le RP et le fournisseur d'identité sont déconnectés du navigateur, et la promesse est résolue. Les comptes utilisateur de déconnexion sont spécifiés dans la réponse du point de terminaison de déconnexion.
Configurer le fichier de configuration de l'IdP
Pour prendre en charge l'API Déconnecter, 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 IdP.
{
"accounts_endpoint": "/accounts",
"id_assertion_endpoint": "/assertion",
...
"disconnect_endpoint: "/disconnect"
}
Déconnecter le compte sur le point de terminaison de déconnexion
En appelant IdentityCredential.disconnect(), le navigateur envoie à ce point de terminaison de déconnexion une requête POST multi-origine avec des cookies et un type de contenu application/x-www-form-urlencoded, avec les informations suivantes:
| Propriété | Description |
|---|---|
account_hint |
Indice pour le compte du fournisseur d'identité. |
client_id |
Identifiant du 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 du fournisseur d'identité doit:
- Répondez à la requête avec CORS (Cross-Origin Resource Sharing).
- Vérifiez que la requête contient un en-tête HTTP
Sec-Fetch-Dest: webidentity. - Faites correspondre l'en-tête
Originà l'origine de la RP déterminée par l'client_id. Refusez s'ils ne correspondent pas. - Recherchez le compte correspondant à
account_hint. - Déconnectez le compte utilisateur de la liste des comptes connectés au tiers assujetti à des restrictions.
- Répondez au navigateur avec le
account_idde 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 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 le RP et l'IdP sont sur le 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 RP intermédiaire et le serveur IdP intermédiaire se trouvent à l'adresse staging.idp.example. Toutefois, comme le fichier connu doit être placé à la racine de l'eTLD+1 du serveur de l'IdP, il doit se trouver dans idp.example/.well-known/web-identity et il doit s'agir 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 du fournisseur d'identité sont identiques, Chrome ignore la vérification du fichier connu. De cette façon, les développeurs pourront effectuer des tests dans un tel scénario.
Les sous-ressources peuvent désormais définir l'état de connexion au même site
Auparavant, Chrome ne permettait de définir l'état de la connexion (par exemple, à l'aide de l'en-tête Set-Login: logged-in) que lorsque la requête était de même origine avec tous les ancêtres. Cela empêchait les connexions via les requêtes fetch() same-site définies sur l'état de la connexion.
Prenons l'exemple d'un site Web qui permet aux utilisateurs de saisir leur nom d'utilisateur et leur mot de passe dans idp.example, mais dont les identifiants sont publiés dans login.idp.example avec fetch(). L'enregistrement de l'état de la connexion dans le navigateur à l'aide de l'API Login Status n'a pas été possible, car les deux domaines sont issus de plusieurs origines et du même site.
Avec ce changement, nous avons assoupli l'obligation pour l'API Login Status d'être sur le même site avec tous les ancêtres. Nous permettons à l'exemple ci-dessus 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é
En utilisant l'API Déconnecter, FedCM peut désormais dissocier la RP de l'IdP sans s'appuyer sur des cookies tiers. Pour ce faire, appelez IdentityCredential.disconnect() sur le tiers assujetti à des restrictions. Avec cette fonction, le navigateur envoie une requête au point de terminaison de déconnexion du fournisseur d'identité afin que celui-ci puisse mettre fin à la connexion sur le serveur, puis dans le navigateur.
Nous avons annoncé que la vérification /.well-known/web-identity est ignorée lorsque le tiers assujetti à des restrictions et l'IdP correspondent au même site, à des fins de test. En outre, il est maintenant possible de définir un état de connexion via un en-tête de réponse HTTP à partir de la sous-ressource IdP du même site.