Chrome propose une nouvelle expérience de choix pour les utilisateurs avec les cookies tiers. Vous devez préparer votre site pour les utilisateurs qui choisissent de naviguer sans cookies tiers.
Vous trouverez sur cette page des informations sur les scénarios d'identité les plus susceptibles d'être concernés, ainsi que des références aux 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 apportées aux cookies tiers.
Toutefois, si votre site utilise un domaine distinct pour la connexion, comme avec Google Sign-In ou Facebook Login, 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 répertorie certains parcours utilisateur courants et les solutions potentielles pour chacun d'eux qui ne dépendent pas des cookies tiers. Les sections suivantes expliquent les raisons de ces recommandations.
Autres API recommandées pour les cas d'utilisation courants
| Parcours utilisateur | API recommandées |
|---|---|
| Connexion aux réseaux sociaux |
Pour les fournisseurs d'identité : implémentez FedCM Pour les parties de confiance : contactez votre fournisseur d'identité |
| Déconnexion de Front Channel | Pour les fournisseurs d'identité : implémentez FedCM |
|
Pour les fournisseurs d'identité ou les solutions personnalisées : Ensembles de sites Web associés |
|
| Gestion du profil utilisateur |
API Storage Access Services de sites Web associés CHIPS FedCM |
|
API Storage Access Services de sites Web associés CHIPS FedCM |
|
| Authentification |
API Storage Access FedCM API Web Authentication sciencePop-ups partitionnés |
| Ces scénarios n'ont généralement pas de dépendances de cookies tiers et ne devraient pas être affectés. |
Tester vos parcours utilisateur liés à l'identité
Le meilleur moyen de vérifier si votre flux de connexion est affecté par les modifications apportées aux cookies tiers consiste à suivre les flux 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 de 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
Cette section contient des informations plus spécifiques sur l'impact potentiel de ces changements sur ces flux.
Authentification unique (SSO) tierce
L'authentification unique (SSO, Single Sign-On) 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 d'authentification unique, de nombreuses entreprises optent pour 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. Le meilleur moyen est de demander au fournisseur comment les dépendances de cookies tiers affectent la solution et quelle approche il recommande pour son service. Certains fournisseurs abandonnent les cookies tiers de manière silencieuse, auquel cas les parties de confiance n'ont 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, par exemple 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 :
- Mise à jour pour utiliser les cookies propriétaires ("Same-site"):modifiez l'infrastructure du site Web pour 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 plus d'efforts, selon la configuration de l'infrastructure.
- Utilisez les 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 tiers assujettis à des restrictions qui se trouvent dans le même RWS que le fournisseur d'identité. Toutefois, RWS n'est compatible qu'avec un nombre limité de domaines pour l'accès aux cookies intersites.
- 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 les utilisateurs sur 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 aux identités sans avoir recours à des cookies tiers. Dans votre cas, votre "domaine de connexion" peut servir de fournisseur d'identité FedCM et être utilisé pour authentifier les utilisateurs sur 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é à top-level.example est partitionné 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 3-party-app.example 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.
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 de l'appeler depuis les éléments intégrés plutôt que les 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, Facebook Login et Se connecter avec Twitter sont un signe certain que votre site Web utilise un fournisseur d'identité fédéré. Chaque fournisseur d'identité fédéré 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 migre de manière transparente 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 CM fédéré 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 le parcours utilisateur, comme consulter ou gérer les données du profil utilisateur ou des abonnements.
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 s'abonner à du contenu premium ou mettre à 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 devraient être isolées dans website.example, les CHIPS peuvent contribuer à garantir que l'élément intégré peut accéder aux informations dont il a besoin. Avec CHIPS, le widget subscriptions.example intégré à website.example n'a 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 un 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 l'accès à l'espace de stockage non partitionné.
Pour savoir quelle API choisir pour gérer un parcours utilisateur particulier avec du contenu intégré, consultez le guide sur l'intégration.
Déconnexion du canal principal
La déconnexion par canal avant est un mécanisme qui permet à un utilisateur de se déconnecter de toutes les applications associées lorsqu'il se déconnecte d'un service. La déconnexion par canal avant d'OIDC nécessite que l'IDP intègre plusieurs iFrames de partie de confiance (RP) qui reposent sur les cookies de la RP.
Si votre solution repose sur un fournisseur d'identité, des modifications mineures (telles qu'une mise à niveau de la bibliothèque) peuvent être nécessaires. Pour en savoir plus, contactez votre fournisseur d'identité.
Pour répondre à ce cas d'utilisation, FedCM a testé la fonctionnalité logoutRPs. Cela permet à l'IdP de déconnecter tout RP pour lequel l'utilisateur a précédemment approuvé la communication RP-IdP. Cette fonctionnalité n'est plus disponible, mais nous vous invitons à consulter la proposition initiale et à nous faire part de vos commentaires si vous êtes intéressé ou si vous avez besoin de cette fonctionnalité.
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 les gère. 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 toute défaillance rencontrée à 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 qu'il est prêt : vérifiez l'utilisation des cookies tiers sur votre site, testez les erreurs et passez aux solutions recommandées.