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.
Sur cette page, vous trouverez des informations sur les scénarios de connexion les plus susceptibles de être affectées, ainsi que des références aux solutions possibles.
Si votre site Web ne gère que des flux au sein du même domaine et sous-domaines, tels que
que publisher.example et login.publisher.example, il n'utilisera pas
cookies 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, par exemple Google Sign-In ou Facebook, ou votre site doit partager des utilisateurs l'authentification auprès de plusieurs domaines ou sous-domaines, vous risquez vous devez apporter des modifications à votre site afin d'assurer une transition en douceur les cookies intersites.
Tester les parcours utilisateur liés à l'identité
Le meilleur moyen de vérifier si votre procédure de connexion est affectée par un cookie tiers modifications consiste à passer par les étapes d'inscription, de récupération de mot de passe, de connexion et flux de déconnexion avec l'indicateur de test des cookies tiers activé.
Voici une checklist d'éléments à vérifier une fois que vous avez restreint l'accès cookies:
- Inscription d'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:elle fonctionne comme prévu depuis l'interface utilisateur Web, aux CAPTCHA et à la réception de l'e-mail de récupération du mot de passe.
- Connexion:le processus de connexion fonctionne dans le même domaine et lorsque accéder à 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 processus de déconnexion.
Vous devez également vérifier que les autres fonctionnalités du site qui nécessitent la connexion de l'utilisateur restent fonctionnent sans cookies intersites, surtout s'ils impliquent un chargement sur plusieurs sites. Par exemple, si vous utilisez un CDN pour charger des images de profil utilisateur, pour vérifier que cela fonctionne toujours. Si vous avez des parcours utilisateur critiques lors d'un paiement, avec une connexion, s'assurent que ceux-ci continuent de fonctionner.
Dans les sections suivantes, vous trouverez des informations plus spécifiques sur la façon dont ces flux pourraient être affectées.
Identité fédérée
Les boutons de connexion tels que Se connecter avec Google, Facebook Login et Connectez-vous à l'aide de Twitter pour indiquer clairement que votre site Web utilise un d'identité fédérée de Google. Chaque fournisseur d'identité fédéré disposant sa propre implémentation, la meilleure solution consiste à vérifier l'état documentation ou contactez-le pour obtenir des conseils supplémentaires.
Si vous utilisez la version obsolète bibliothèque de plate-forme JavaScript Google Sign-In, pour savoir comment pour 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 sont prêts l'abandon des cookies tiers, car la bibliothèque migrera silencieusement vers à l'aide de FedCM pour assurer la compatibilité. Nous vous recommandons de tester votre site avec l'indicateur de test des cookies tiers activé et, si nécessaire, en vous appuyant sur la checklist pour la migration de FedCM.
Domaine de connexion distinct
Certains sites Web utilisent un domaine différent uniquement pour authentifier les utilisateurs qui n'utilisent pas
sont éligibles aux cookies SameSite, tels qu'un site Web utilisant example.com pour
et login.example pour le flux de connexion, ce qui peut nécessiter un accès
tiers pour s'assurer que l'utilisateur est authentifié à la fois
domaines.
Les chemins de migration possibles pour ce scénario sont les suivants:
- Mise à jour pour utiliser les cookies propriétaires ("Same-Site"):modifiez le de votre site Web de sorte que le flux de connexion soit hébergé sur le même domaine sous-domaine) comme site principal, qui n'utilisera que des cookies propriétaires. Cela peut nécessitent davantage d'efforts, selon la configuration de l'infrastructure.
- Utiliser les ensembles de sites Web associés (RWS) : activer les ensembles de sites Web associés un accès limité aux cookies intersites entre un petit groupe de domaines connexes ; RWS est une API Privacy Sandbox conçue pour répondre à ce cas d'utilisation. Toutefois, RWS ne peut prend en charge l'accès aux cookies intersites sur un nombre limité de domaines.
- Si vous authentifiez les utilisateurs sur plus de cinq domaines associés, Explorez FedCM: Federated Credentials Management (FedCM) permet les fournisseurs d'identité de s'appuyer sur Chrome pour gérer les flux liés aux identités sans nécessitant des cookies tiers. Dans votre cas, votre "domaine de connexion" pourrait agir en tant que le fournisseur d'identité FedCM afin d'authentifier les utilisateurs domaines.
Domaines multiples
Lorsqu'une entreprise gère plusieurs produits hébergés sur différents domaines ou sous-domaines, il peut vouloir partager la session utilisateur entre ces produits, ce qui peut nécessitent d'accéder à des cookies tiers entre plusieurs domaines.
Dans ce scénario, héberger tous les produits sous le même domaine est souvent peu pratique. Dans ce cas, les solutions possibles sont les suivantes:
- Utilisez les Ensembles de sites Web associés:lorsque l'accès aux cookies intersites est nécessaire. entre un petit groupe de domaines connexes.
- Utilisez FedCM (Fédération):lorsque le nombre de sont volumineux, vous pouvez utiliser un domaine de connexion distinct en tant qu'identité et authentifier les utilisateurs sur vos sites à l'aide de FedCM.
Solutions de connexion
Authentification unique (SSO) tierce
En raison de la complexité de la mise en œuvre d'une solution SSO, de nombreuses entreprises optent pour en faisant appel à un fournisseur de solutions tiers, pour partager l'état de connexion entre plusieurs origines. Exemples de fournisseurs : Okta, Ping Identity, Google Cloud IAM ou Microsoft Entra ID.
Lorsque vous faites appel à un fournisseur tiers, la meilleure approche consiste à demander conseil à le fournisseur sur l'impact des modifications apportées aux cookies tiers sur la solution et l'approche qu'il recommande pour son service.
Solutions SSO Open Source
De nombreuses entreprises qui gèrent leurs propres solutions d'authentification unique le feront en s'appuyant sur normes du secteur, telles qu'OpenID Connect, OAuth ou SAML, ou les normes ouvertes comme Keycloak, WSO2, Auth.js ou Hydra.
Nous vous recommandons de consulter la documentation de votre fournisseur les modifications apportées aux cookies peuvent affecter leur solution, ainsi que le meilleur chemin de migration pour cette solution spécifique.
Solutions internes personnalisées
Si votre solution de connexion correspond à l'un des cas d'utilisation précédents et qu'elle est intégrée en interne, Préparer l'arrêt progressif des cookies tiers expliquez en détail comment auditer votre code et vous préparer aux modifications des cookies tiers.
Agissez dès maintenant !
Si votre site Web correspond à l'un de ces cas d'utilisation, plusieurs solutions s'offrent à vous. pour gérer tout impact possible, du déplacement du flux d'authentification le domaine principal, de sorte qu'il n'utilise que des cookies propriétaires, les ensembles de sites Web associés pour autoriser le partage de cookies entre un petit nombre ou exploiter la gestion des identifiants de fédération.
Le moment est venu d'auditer votre service et de vous préparer au cookie tiers les modifications sont effectives !