Chrome propone una nueva experiencia para que el usuario elija con las cookies de terceros. Debes preparar tu sitio para los usuarios que elijan navegar sin cookies de terceros.
En esta página, encontrarás información sobre las situaciones de identidad que tienen más probabilidades de verse afectadas, así como referencias a posibles soluciones.
Si tu sitio web solo maneja flujos dentro del mismo dominio y subdominios, como publisher.example y login.publisher.example, no usará cookies entre sitios, y no se espera que tu flujo de acceso se vea afectado por los cambios en las cookies de terceros.
Sin embargo, si tu sitio usa un dominio independiente para el acceso, como el Acceso con Google o el Acceso con Facebook, o si necesita compartir la autenticación de usuarios en varios dominios o subdominios, es posible que debas realizar cambios en él para garantizar una transición sin problemas de las cookies entre sitios.
Recorrido comunes de los usuarios
Históricamente, muchos flujos de trabajo de identidad dependían de cookies de terceros. En la tabla, se enumeran algunos recorridos comunes de los usuarios y posibles soluciones para cada uno de ellos que no dependen de las cookies de terceros. En las siguientes secciones, se explicará el razonamiento detrás de estas recomendaciones.
APIs alternativas recomendadas para casos de uso comunes
| Recorrido del usuario | APIs recomendadas |
|---|---|
| Acceso con redes sociales |
Para proveedores de identidad: Implementa FedCM Para partes de confianza: Comunícate con tu proveedor de identidad |
| Salida del canal principal | Para proveedores de identidad: Implementa FedCM |
|
Para proveedores de identidad o soluciones personalizadas: Conjuntos de sitios web relacionados |
|
| Administración de perfiles de usuario |
API de Storage Access Conjuntos de sitios web relacionados CHIPS FedCM |
|
API de Storage Access Conjuntos de sitios web relacionados CHIPS FedCM |
|
| Autenticación |
API de Storage Access FedCM API de Web Authentication scienceVentanas emergentes particionadas |
| Por lo general, estas situaciones no tienen dependencias de cookies de terceros y no se espera que se vean afectadas. |
Prueba tus recorridos del usuario relacionados con la identidad
La mejor manera de probar si tu flujo de acceso se ve afectado por los cambios en las cookies de terceros es realizar los flujos de registro, recuperación de contraseña, acceso y salida con la marca de prueba de cookies de terceros habilitada.
Esta es una lista de tareas que debes verificar una vez que hayas restringido las cookies de terceros:
- Registro de usuarios: La creación de una cuenta nueva funciona según lo esperado. Si usas proveedores de identidad de terceros, verifica que el registro de cuentas nuevas funcione para cada integración.
- Recuperación de contraseñas: La recuperación de contraseñas funciona según lo esperado, desde la IU web, los CAPTCHAs y la recepción del correo electrónico de recuperación de contraseñas.
- Acceso: El flujo de trabajo de acceso funciona dentro del mismo dominio y cuando se navega a otros dominios. Recuerda probar cada integración de acceso.
- Salida: El proceso de salida funciona según lo esperado, y el usuario permanece fuera de la cuenta después del flujo de salida.
También debes probar que otras funciones del sitio que requieren el acceso del usuario sigan funcionando sin cookies entre sitios, en especial si implican la carga de recursos entre sitios. Por ejemplo, si usas una CDN para cargar imágenes de perfiles de usuario, asegúrate de que esta siga funcionando. Si tienes recorridos críticos del usuario, como la confirmación de la compra, con acceso restringido, asegúrate de que sigan funcionando.
Soluciones de acceso
En esta sección, encontrarás información más específica sobre cómo podrían verse afectados esos flujos.
Inicio de sesión único (SSO) de terceros
El inicio de sesión único (SSO) de terceros permite que un usuario se autentique con un solo conjunto de credenciales en una plataforma y, luego, acceda a varias aplicaciones y sitios web sin tener que volver a ingresar su información de acceso. Debido a la complejidad de implementar una solución de SSO, muchas empresas optan por usar un proveedor de soluciones de terceros para compartir el estado de acceso entre varios orígenes. Algunos ejemplos de proveedores son Okta, Ping Identity, Google Cloud IAM o Microsoft Entra ID.
Si tu solución depende de un proveedor externo, es posible que se deban realizar algunos cambios menores, como una actualización de la biblioteca. El mejor enfoque es buscar orientación del proveedor sobre cómo las dependencias de cookies de terceros afectan la solución y qué enfoque recomienda para su servicio. Algunos proveedores migrarán de forma silenciosa de las cookies de terceros, en cuyo caso las partes de confianza no necesitarán actualizarse.
Varios dominios
Algunos sitios web usan un dominio diferente solo para autenticar a los usuarios que no califican para las cookies del mismo sitio, como un sitio web que usa example.com para el sitio principal y login.example para el flujo de acceso, lo que podría requerir el acceso a cookies de terceros para garantizar que el usuario se autentique en ambos dominios.
Algunas empresas pueden tener varios productos alojados en diferentes dominios o subdominios. Es posible que esas soluciones deseen compartir la sesión del usuario en esos productos, una situación que puede requerir el acceso a cookies de terceros entre varios dominios.
Las posibles rutas de migración para esta situación son las siguientes:
- Actualiza para usar cookies propias ("del mismo sitio"): Cambia la infraestructura del sitio web para que el flujo de acceso se aloje en el mismo dominio (o subdominio) que el sitio principal, que solo usará cookies propias. Esto puede requerir un mayor esfuerzo, según cómo esté configurada la infraestructura.
- Usa Conjuntos de sitios web relacionados (RWS) y la API de acceso a almacenamiento (SAA): RWS permite el acceso limitado a cookies entre sitios entre un pequeño grupo de dominios relacionados. Con RWS, no se necesita una solicitud del usuario cuando se solicita acceso al almacenamiento con la API de Storage Access. Esto permite el SSO en las RP que están en el mismo RWS que el IdP. Sin embargo, RWS solo admite el acceso a cookies entre sitios en una cantidad limitada de dominios.
- Usa la API de Web Authentication: La API de Web Authentication permite que las partes de confianza (RP) registren un conjunto limitado de orígenes relacionados a través de los cuales se pueden crear y usar credenciales.
- Si autenticas usuarios en más de 5 dominios asociados, explora Federated Credential Management (FedCM): FedCM permite que los proveedores de identidad se basen en Chrome para controlar los flujos relacionados con la identidad sin necesidad de cookies de terceros. En tu caso, tu "dominio de acceso" podría actuar como el proveedor de identidad de FedCM y usarse para autenticar a los usuarios en tus otros dominios.
Autenticación de incorporaciones
Supongamos que un iframe 3-party-app.example está incorporado en top-level.example. En 3-party-app.example, el usuario puede acceder con las credenciales de 3-party-app.example o con otro proveedor externo.
El usuario hace clic en "Acceder" y se autentica en la ventana emergente de 3-party-app.example. La ventana emergente de 3-party-app.example establece una cookie propia. Sin embargo, el iframe 3-party-app.example incorporado en top-level.example está particionado y no puede acceder a la cookie establecida en el contexto propio de 3-party-app.example.
El mismo problema ocurriría cuando se redirecciona a un usuario de top-level.example a 3-party-app.example y viceversa. La cookie se escribe en el contexto propio del sitio 3-party-app.example, pero está particionada y no se puede acceder a ella desde el iframe 3-party-app.example.
En los casos en que el usuario visitó el origen incorporado en un contexto de nivel superior, la API de Storage Access es una buena solución.
Para migrar de las soluciones que dependen de las cookies de terceros, recomendamos que los proveedores de identidad adopten la API de FedCM y que se llame a FedCM desde las incorporaciones en lugar de las ventanas emergentes.
Otra solución propuesta para este flujo, Popins particionados, está en proceso de implementación.
Acceso con redes sociales
Los botones de acceso como Acceder con Google, Acceso con Facebook y Acceder con Twitter son una señal definitiva de que tu sitio web usa un proveedor de identidad federada. Cada proveedor de identidad federada tendrá su propia implementación.
Si usas la biblioteca de la plataforma de JavaScript de Acceso con Google obsoleta, puedes obtener información para migrar a la biblioteca más reciente de Google Identity Services para realizar la autenticación y autorización.
La mayoría de los sitios que usan la biblioteca más reciente de Google Identity Services quitaron la dependencia de las cookies de terceros, ya que la biblioteca migrará de forma silenciosa a usar FedCM para garantizar la compatibilidad. Te recomendamos que pruebes tu sitio con la marca de prueba de la baja gradual de las cookies de terceros habilitada y, si es necesario, que uses la lista de tareas de migración de FedCM para prepararte.
Permite acceder a los datos del usuario desde incorporaciones y modificarlos
El contenido incorporado se usa a menudo para los recorridos del usuario, como acceder o administrar el perfil del usuario o los datos de las suscripciones.
Por ejemplo, un usuario podría acceder a website.example, que incorpora un widget subscriptions.example. Este widget permite a los usuarios administrar sus datos, como suscribirse a contenido premium o actualizar la información de facturación. Para modificar los datos del usuario, es posible que el widget incorporado deba acceder a sus propias cookies mientras está incorporado en website.example. En el caso de que estos datos deban aislarse en website.example, CHIPS puede ayudar a garantizar que la incorporación pueda acceder a la información que necesita. Con CHIPS, el widget subscriptions.example incorporado en website.example no tendrá acceso a los datos de suscripción del usuario en otros sitios web.
Considera otro caso: un video de streaming.example está incorporado en website.example y el usuario tiene una suscripción premium a streaming.example, que el widget debe conocer para inhabilitar los anuncios. Si es necesario acceder a la misma cookie en varios sitios, considera usar la API de Storage Access si el usuario ya visitó streaming.example como nivel superior y Conjuntos de sitios web relacionados si el conjunto de website.example posee la streaming.example.
A partir de Chrome 131, FedCM se integra en la API de Storage Access. Con esta integración, cuando el usuario acepta la solicitud de FedCM, el navegador le otorgará al IdP acceso de incorporación al almacenamiento no particionado.
Para obtener más información sobre qué API elegir para controlar un recorrido del usuario en particular con contenido incorporado, consulta la Guía de incorporaciones.
Salida del canal principal
La salida del canal frontal es un mecanismo que permite que un usuario salga de todas las apps relacionadas cuando sale de un servicio. El cierre de sesión del canal frontal de OIDC requiere que la AC incorpore varios iframes de la parte de confianza (RP) que dependen de las cookies de la RP.
Si tu solución depende de un proveedor de identidad, es posible que se necesiten cambios menores (como una actualización de la biblioteca). Para obtener más orientación, comunícate con tu proveedor de identidad.
Para abordar este caso de uso, FedCM experimentó con la función logoutRPs. Esto permitió que la AC saliera de cualquier RP para la que el usuario haya aprobado previamente la comunicación entre la AC y la IdP. Esta función ya no está disponible, pero te recomendamos que mires la propuesta inicial y nos envíes tus comentarios si te interesa o necesitas esta función.
Otros recorridos del usuario
Los recorridos de los usuarios que no dependen de las cookies de terceros no deberían verse afectados por los cambios en la forma en que Chrome maneja las cookies de terceros. Las soluciones existentes, como el acceso, la salida o la recuperación de cuentas en el contexto de terceros, la AUA, deberían funcionar según lo previsto. Ya se describieron los posibles puntos de falla. Para obtener más información sobre una API en particular, consulta la página de estado de la API. Informa cualquier falla que haya sufrido a goo.gle/report-3pc-broken. También puedes enviar un formulario de comentarios o informar un problema en GitHub en el repositorio de asistencia para desarrolladores de Privacy Sandbox.
Cómo auditar tu sitio
Si tu sitio web implementa uno de los recorridos del usuario que se describen en esta guía, debes asegurarte de que tus sitios estén preparados: audita tu sitio en busca de uso de cookies de terceros, prueba si hay errores y realiza la transición a las soluciones recomendadas.