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

Les cookies tiers peuvent être bloqués par des restrictions du navigateur, des paramètres utilisateur, des indicateurs de développeur ou des règles d'entreprise.

Vous devez faire en sorte que votre site ou service offre une expérience optimale à tous vos utilisateurs, que les cookies tiers soient disponibles ou non.

Sur cette page, vous trouverez 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 mêmes sous-domaines, tels que publisher.example et login.publisher.example, il n'utilisera pas de cookies multisites. Votre flux de connexion ne devrait donc pas être affecté par les modifications apportées aux cookies tiers.

Toutefois, si votre site utilise un domaine distinct pour la connexion, comme Google Sign-in ou Facebook Login, ou si votre site doit partager l'authentification des utilisateurs sur plusieurs domaines ou sous-domaines, il est possible que vous deviez apporter des modifications à votre site pour assurer une transition fluide vers l'abandon des cookies tiers.

Parcours utilisateurs courants

Historiquement, de nombreux workflows d'identité s'appuyaient sur des cookies tiers. Le tableau ci-dessous liste quelques parcours utilisateur courants et les solutions potentielles pour chacun d'eux qui ne dépendent pas des cookies tiers. Les sections suivantes expliquent la logique de ces recommandations.

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

du tableau en sont encore à leurs premières phases de développement. Vos commentaires sont précieux et nous aideront à améliorer l'expérience des utilisateurs à l'avenir. Partagez votre avis sur ces API : Popins partitionnés.

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

Pour savoir si votre parcours de connexion est affecté par les modifications apportées aux cookies tiers, le mieux est de parcourir vos flux d'inscription, 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 restreint les cookies tiers :

• Inscription 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 du mot de passe : la récupération du mot de passe fonctionne comme prévu, de l'UI 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 au sein du 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 flux de déconnexion.

Vous devez également vérifier que les autres fonctionnalités du site qui nécessitent la connexion de l'utilisateur restent fonctionnelles sans cookies tiers, en particulier si elles impliquent le chargement de ressources multisites. Par exemple, si vous utilisez un CDN pour charger les images de profil des utilisateurs, assurez-vous que cela fonctionne toujours. Si vous avez des parcours utilisateur critiques, comme le paiement, qui 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 la façon dont ces flux peuvent être affectés.

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 choisissent d'utiliser un fournisseur de solutions tiers pour partager l'état de connexion entre plusieurs origines. Par exemple, Okta, Ping Identity, Google Cloud IAM ou Microsoft Entra ID.

Si votre solution repose sur un fournisseur tiers, il est possible que de petites modifications soient nécessaires, comme une mise à niveau de la bibliothèque. La meilleure approche consiste à demander au fournisseur comment les dépendances des cookies tiers affectent la solution et quelle approche il recommande pour son service. Certains fournisseurs migreront silencieusement depuis les cookies tiers. Dans ce cas, les parties de confiance n'ont pas besoin d'effectuer de mise à jour.

Domaines multiples

Certains sites Web utilisent un domaine différent uniquement pour authentifier les utilisateurs qui ne sont pas éligibles aux cookies same-site. Par exemple, un site Web peut utiliser example.com pour le site principal et login.example pour le flux de connexion. Dans ce cas, il peut être nécessaire 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 souhaiter partager la session utilisateur entre ces produits, un scénario qui peut nécessiter l'accès à des cookies tiers entre plusieurs domaines.

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

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

Authentification à partir d'éléments intégrés

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 à 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, puis de nouveau vers top-level.example. 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.

Dans les cas où l'utilisateur a visité l'origine intégrée dans un contexte de premier niveau, l'API Storage Access est une bonne solution.

Pour migrer depuis les solutions qui s'appuient sur des cookies tiers, nous recommandons aux fournisseurs d'identité d'adopter l'API FedCM et d'appeler FedCM à partir d'intégrations plutôt que de pop-ups.

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

Connexion à un réseau social

Les boutons de connexion tels que Se connecter avec Google, Connexion Facebook et Se connecter avec Twitter indiquent clairement que votre site Web utilise un fournisseur d'identité fédérée. Chaque fournisseur d'identité fédérée aura 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 utilisant la nouvelle bibliothèque Google Identity Services ne dépendent plus des cookies tiers, car la bibliothèque migrera silencieusement vers FedCM pour assurer la compatibilité. Nous vous recommandons de tester votre site avec l'indicateur de test de la suppression progressive des cookies tiers activé et, si nécessaire, d'utiliser la checklist de migration FedCM pour vous préparer.

Accéder aux données utilisateur et les modifier à partir d'intégrations

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

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 modifiant 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é sur 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 exemple : une vidéo de streaming.example est intégrée à website.example, et l'utilisateur dispose d'un abonnement premium streaming.example, dont le widget a besoin 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à visité streaming.example en tant que domaine de premier niveau, et les ensembles de sites Web associés si l'ensemble de website.example possède streaming.example.

À partir de Chrome 131, FedCM est intégré à l'API Storage Access. Grâce à 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 spécifique avec du contenu intégré, consultez le guide sur les intégrations.

Autres parcours utilisateur

Les parcours utilisateur qui ne reposent pas sur des 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 un 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 des API.

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 : auditez l'utilisation de cookies tiers sur votre site, testez les éventuels problèmes et passez aux solutions recommandées.