Vérifier l'impact des modifications apportées aux cookies tiers sur vos workflows de connexion

bookmark_border Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Chrome propose une nouvelle expérience de choix de l'utilisateur avec les cookies tiers. Vous devez préparer votre site pour les utilisateurs qui choisissent de naviguer sans cookies tiers.

Cette page contient des informations sur les scénarios d'identité les plus susceptibles d'être affectés, ainsi que des références à des solutions possibles.

Si votre site Web ne gère que les flux au sein du même domaine et des sous-domaines, tels que publisher.example et login.publisher.example, il n'utilisera pas de cookies intersites et votre flux de connexion ne devrait pas être affecté par les modifications des cookies tiers.

Toutefois, si votre site utilise un domaine distinct pour la connexion, comme avec Connexion Google ou Connexion Facebook, ou si votre site doit partager l'authentification des utilisateurs sur plusieurs domaines ou sous-domaines, vous devrez peut-être apporter des modifications à votre site pour assurer une transition en douceur vers les cookies intersites.

Parcours utilisateurs courants

Par le passé, de nombreux workflows d'identité reposaient sur des cookies tiers. Le tableau ci-dessous liste certains parcours utilisateur courants et les solutions potentielles pour chacun d'eux qui ne dépendent pas des cookies tiers. Les sections suivantes expliquent le raisonnement derrière ces recommandations.

API alternatives recommandées pour les cas d'utilisation courants

du tableau sont encore en phase de développement. Vos commentaires sont précieux et contribueront à façonner son avenir. Donnez-nous votre avis sur ces API: Pop-ups partitionnés.

Tester vos parcours utilisateur liés à l'identité

Le meilleur moyen de tester si votre procédure de connexion est affectée par les modifications apportées aux cookies tiers consiste à suivre vos procédures d'enregistrement, de récupération de mot de passe, de connexion et de déconnexion avec l'indicateur de test des cookies tiers activé.

Voici une checklist des éléments à vérifier une fois que vous avez limité les cookies tiers:

• Enregistrement des utilisateurs:la création d'un compte fonctionne comme prévu. Si vous utilisez des fournisseurs d'identité tiers, vérifiez que l'enregistrement de nouveaux comptes fonctionne pour chaque intégration.
• Récupération de mot de passe:la récupération de mot de passe fonctionne comme prévu, de l'interface utilisateur Web aux CAPTCHA, en passant par la réception de l'e-mail de récupération du mot de passe.
• Connexion:le workflow de connexion fonctionne dans le même domaine et lorsque vous accédez à d'autres domaines. N'oubliez pas de tester chaque intégration de connexion.
• Déconnexion:le processus de déconnexion fonctionne comme prévu, et l'utilisateur reste déconnecté après le parcours de déconnexion.

Vous devez également vérifier que les autres fonctionnalités du site qui nécessitent la connexion des utilisateurs restent opérationnelles sans cookies intersites, en particulier si elles impliquent le chargement de ressources intersites. Par exemple, si vous utilisez un CDN pour charger des images de profil utilisateur, assurez-vous que cela fonctionne toujours. Si des parcours utilisateur critiques, comme le règlement, sont soumis à une connexion, assurez-vous qu'ils continuent de fonctionner.

Solutions de connexion

Dans cette section, vous trouverez des informations plus spécifiques sur l'impact potentiel de ces flux.

Authentification unique (SSO) tierce

L'authentification unique (SSO) tierce permet à un utilisateur de s'authentifier avec un seul ensemble d'identifiants sur une plate-forme, puis d'accéder à plusieurs applications et sites Web sans avoir à saisir à nouveau ses informations de connexion. En raison de la complexité de l'implémentation d'une solution SSO, de nombreuses entreprises optent pour l'utilisation d'un fournisseur de solutions tiers afin de partager l'état de connexion entre plusieurs origines. Exemples de fournisseurs : Okta, Ping Identity, Google Cloud IAM ou Microsoft Entra ID.

Si votre solution repose sur un fournisseur tiers, il est possible que des modifications mineures, telles qu'une mise à niveau de la bibliothèque, soient nécessaires. La meilleure approche consiste à demander au fournisseur comment les dépendances de cookies tiers affectent la solution et quelle approche il recommande pour son service. Certains fournisseurs abandonneront les cookies tiers de manière silencieuse, auquel cas les parties de confiance n'auront pas besoin de mettre à jour leur code.

Domaines multiples

Certains sites Web n'utilisent un domaine différent que pour authentifier les utilisateurs qui ne sont pas éligibles aux cookies du même site, comme un site Web qui utilise example.com pour le site principal et login.example pour le flux de connexion, ce qui peut nécessiter d'accéder aux cookies tiers pour s'assurer que l'utilisateur est authentifié sur les deux domaines.

Certaines entreprises peuvent héberger plusieurs produits sur différents domaines ou sous-domaines. Ces solutions peuvent vouloir partager la session utilisateur entre ces produits, ce qui peut nécessiter d'accéder aux cookies tiers entre plusieurs domaines.

Voici les chemins de migration possibles pour ce scénario:

• Passer aux cookies propriétaires ("same-site"):modifiez l'infrastructure du site Web afin que le flux de connexion soit hébergé sur le même domaine (ou sous-domaine) que le site principal, qui n'utilisera que des cookies propriétaires. Cela peut nécessiter des efforts plus importants, en fonction de la configuration de l'infrastructure.
• Utilisez des ensembles de sites Web associés et l'API Storage Access (SAA):les ensembles de sites Web associés permettent un accès limité aux cookies intersites entre un petit groupe de domaines associés. Avec RWS, aucune invite utilisateur n'est requise lorsque vous demandez l'accès au stockage avec l'API Storage Access. Cela permet l'authentification unique pour les RP qui se trouvent dans le même RWS que le fournisseur d'identité. Toutefois, RWS n'est compatible qu'avec l'accès aux cookies intersites sur un nombre limité de domaines.
• Utiliser l'API Web Authentication:l'API Web Authentication permet aux parties de confiance (RP) d'enregistrer un ensemble limité d'origines associées sur lesquelles des identifiants peuvent être créés et utilisés.
• Si vous authentifiez des utilisateurs sur plus de cinq domaines associés, explorez la gestion des identifiants fédérés (FedCM). FedCM permet aux fournisseurs d'identité de s'appuyer sur Chrome pour gérer les flux liés à l'identité sans avoir besoin de cookies tiers. Dans votre cas, votre "domaine de connexion" peut servir de fournisseur d'identité FedCM et être utilisé pour authentifier les utilisateurs dans vos autres domaines.

Authentification à partir d'intégrations

Supposons qu'un iFrame 3-party-app.example soit intégré à top-level.example. Sur 3-party-app.example, l'utilisateur peut se connecter avec des identifiants 3-party-app.example ou avec un autre fournisseur tiers.

L'utilisateur clique sur "Se connecter" et s'authentifie dans le pop-up 3-party-app.example. Le pop-up 3-party-app.example définit un cookie propriétaire. Toutefois, l'iframe 3-party-app.example intégrée sur top-level.example est partitionnée et ne peut pas accéder au cookie défini dans le contexte propriétaire sur 3-party-app.example.

Le même problème se produirait lorsqu'un utilisateur est redirigé de top-level.example vers 3-party-app.example et inversement. Le cookie est écrit dans le contexte propriétaire du site 3-party-app.example, mais il est partitionné et n'est pas accessible dans l'iframe 3-party-app.example.

Lorsque l'utilisateur a accédé à l'origine intégrée dans un contexte de premier niveau, l'API Storage Access est une bonne solution.

Pour abandonner les solutions qui reposent sur les cookies tiers, nous recommandons aux fournisseurs d'identité d'adopter l'API FedCM et que FedCM soit appelé à partir des éléments intégrés plutôt que des pop-ups.

Une autre solution proposée pour ce flux,les pop-ups partitionnés, est en cours d'implémentation.

Connexion via les réseaux sociaux

Les boutons de connexion tels que Se connecter avec Google, Se connecter avec Facebook et Se connecter avec Twitter sont un signe certain que votre site Web utilise un fournisseur d'identité fédérée. Chaque fournisseur d'identité fédérée dispose de sa propre implémentation.

Si vous utilisez la bibliothèque de plate-forme JavaScript Google Sign-In obsolète, vous trouverez des informations sur la façon de migrer vers la nouvelle bibliothèque Google Identity Services pour l'authentification et l'autorisation.

La plupart des sites qui utilisent la nouvelle bibliothèque Google Identity Services ont supprimé leur dépendance aux cookies tiers, car la bibliothèque migrera de manière silencieuse vers l'utilisation de FedCM pour assurer la compatibilité. Nous vous recommandons de tester votre site avec l'indicateur de test de l'abandon des cookies tiers activé et, si nécessaire, d'utiliser la checklist de migration vers le FedCM pour vous préparer.

Accéder aux données utilisateur et les modifier à partir d'éléments intégrés

Le contenu intégré est souvent utilisé pour les parcours utilisateur, par exemple pour accéder ou gérer les données de profil ou d'abonnement de l'utilisateur.

Par exemple, un utilisateur peut se connecter à website.example, qui intègre un widget subscriptions.example. Ce widget permet aux utilisateurs de gérer leurs données, par exemple en s'abonnant à des contenus premium ou en mettant à jour leurs informations de facturation. Pour modifier les données utilisateur, le widget intégré peut avoir besoin d'accéder à ses propres cookies lorsqu'il est intégré à website.example. Dans le cas où ces données doivent être isolées dans website.example, CHIPS peut aider à s'assurer que l'intégration peut accéder aux informations dont elle a besoin. Avec CHIPS, le widget subscriptions.example intégré à website.example n'aura pas accès aux données d'abonnement de l'utilisateur sur d'autres sites Web.

Prenons un autre cas: une vidéo de streaming.example est intégrée à website.example et l'utilisateur dispose d'un abonnement streaming.example premium, dont le widget doit tenir compte pour désactiver les annonces. Si le même cookie doit être accessible sur plusieurs sites, envisagez d'utiliser l'API Storage Access si l'utilisateur a déjà accédé à streaming.example en tant que niveau supérieur, et les ensembles de sites Web associés si l'ensemble de website.example est propriétaire de streaming.example.

À partir de Chrome 131, FedCM est intégré à l'API Storage Access. Avec cette intégration, lorsque l'utilisateur accepte l'invite FedCM, le navigateur accorde à l'IDP un accès intégré au stockage non partitionné.

Pour savoir quelle API choisir pour gérer un parcours utilisateur particulier avec du contenu intégré, consultez le guide des intégrations.

Autres parcours utilisateur

Les parcours utilisateur qui ne reposent pas sur les cookies tiers ne devraient pas être affectés par les modifications apportées à la façon dont Chrome gère les cookies tiers. Les solutions existantes, telles que la connexion, la déconnexion ou la récupération de compte dans le contexte first party, l'authentification à deux facteurs, devraient fonctionner comme prévu. Les points de rupture potentiels ont déjà été décrits. Pour en savoir plus sur une API spécifique, consultez la page d'état de l'API. Signalez les problèmes rencontrés sur goo.gle/report-3pc-broken. Vous pouvez également envoyer un formulaire de commentaires ou signaler un problème sur GitHub dans le dépôt d'assistance pour les développeurs de la Privacy Sandbox.

Auditer votre site

Si votre site Web implémente l'un des parcours utilisateur décrits dans ce guide, vous devez vous assurer que vos sites sont prêts: vérifiez l'utilisation des cookies tiers sur votre site, testez les erreurs et passez aux solutions recommandées.