Verifica el impacto de los cambios en las cookies de terceros en tus flujos de trabajo de acceso

Las cookies de terceros pueden bloquearse debido a restricciones del navegador, parámetros de configuración del usuario, marcas del desarrollador o políticas empresariales.

Tu sitio o servicio debe proporcionar una excelente experiencia a todos tus usuarios, ya sea que las cookies de terceros estén disponibles o no.

En esta página, encontrarás información sobre las situaciones de identidad que probablemente se vean afectadas, así como referencias a posibles soluciones.

Si tu sitio web solo controla flujos dentro del mismo dominio y subdominios, como publisher.example y login.publisher.example, no usará cookies de sitios cruzados, y no se espera que los cambios en las cookies de terceros afecten tu flujo de acceso.

Sin embargo, si tu sitio usa un dominio independiente para el acceso, como con Acceso con Google o Acceso con Facebook, o si tu sitio necesita compartir la autenticación del usuario en varios dominios o subdominios, es posible que debas realizar cambios en tu sitio para garantizar una transición sin problemas de las cookies de sitios cruzados.

Recorrido comunes de los usuarios

Históricamente, muchos flujos de trabajo de identidad se basaron en cookies de terceros. En la tabla, se enumeran algunos recorridos del usuario comunes 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

en la tabla se encuentran en las primeras etapas de desarrollo. Tus comentarios son valiosos y ayudarán a definir su futuro. Comparte tu opinión sobre estas APIs: Partitioned Popins.

Prueba los 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 completar 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 completar una vez que hayas restringido las cookies de terceros:

• Registro de usuarios: La creación de una cuenta nueva funciona según lo previsto. Si usas proveedores de identidad externos, 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 hasta los CAPTCHA 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 todas las integraciones de acceso.
• Salir: El proceso para salir funciona según lo previsto, y el usuario permanece fuera de su cuenta después del flujo de salida.

También debes probar que otras funciones del sitio que requieren que el usuario acceda 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 perfil de usuario, asegúrate de que siga funcionando. Si tienes recorridos críticos del usuario, como el proceso de confirmación de compra, que requieren acceso, asegúrate de que sigan funcionando.

Soluciones de acceso

En esta sección, encontrarás información más específica sobre cómo se podrían ver 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 múltiples 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 externo 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 necesiten 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 que confían no necesitarán actualizarse.

Varios dominios

Algunos sitios web usan un dominio diferente solo para autenticar a los usuarios que no cumplen con los requisitos 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 estas 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 rutas de migración posibles para esta situación son las siguientes:

• Actualización 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 Storage Access (SAA): Los RWS permiten el acceso limitado a cookies de sitios cruzados entre un grupo pequeño de dominios relacionados. Con RWS, no se necesita ninguna instrucción del usuario cuando se solicita acceso al almacenamiento con la API de Storage Access. Esto permite el SSO en los RP que se encuentran en el mismo RWS que el IdP. Sin embargo, RWS solo admite el acceso a cookies de sitios cruzados en una cantidad limitada de dominios.
• Usa la API de Web Authentication: La API de Web Authentication permite que los usuarios de confianza (RP) registren un conjunto limitado de orígenes relacionados en los que se pueden crear y usar credenciales.
• Si autenticas usuarios en más de 5 dominios asociados, explora Federated Credentials Management (FedCM): FedCM permite que los proveedores de identidad confíen 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 proveedor de identidad de FedCM y usarse para autenticar a los usuarios en tus otros dominios.

Autenticación desde elementos incorporados

Supongamos que se incorporó un iframe de 3-party-app.example 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 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 en 3-party-app.example.

El mismo problema ocurriría cuando un usuario es redireccionado de top-level.example a 3-party-app.example y viceversa. La cookie se escribe en el contexto de origen del sitio 3-party-app.example, pero se particiona y no se puede acceder a ella dentro del 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 cookies de terceros, recomendamos que los proveedores de identidad adopten la API de FedCM y que se llame a FedCM desde elementos incorporados en lugar de ventanas emergentes.

Otra solución propuesta para este flujo, Partitioned Popins, se encuentra en proceso de implementación.

Acceso con redes sociales

Los botones de acceso, como Acceder con Google, Acceder con Facebook y Acceder con Twitter, son un signo definitivo de que tu sitio web usa un proveedor de identidad federada. Cada proveedor de identidad federada tendrá su propia implementación.

Si usas la obsoleta biblioteca de la plataforma de JavaScript de Google Sign-In, puedes encontrar información para migrar a la biblioteca más reciente de Google Identity Services para la autenticación y la autorización.

La mayoría de los sitios que usan la biblioteca más reciente de Google Identity Services ya no dependen de las cookies de terceros, ya que la biblioteca migrará de forma silenciosa para usar FedCM por motivos de compatibilidad. Te recomendamos que pruebes tu sitio con la marca de prueba de la eliminación gradual de las cookies de terceros habilitada y, si es necesario, uses la lista de tareas para la migración a FedCM para prepararte.

Accede a los datos del usuario y modifícalos desde elementos incorporados

El contenido integrado se suele usar para los recorridos del usuario, como el acceso o la administración de los datos del perfil o las suscripciones del usuario.

Por ejemplo, un usuario podría acceder a website.example, que incorpora un widget de 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 necesite acceder a sus propias cookies mientras está incorporado en website.example. En la situación en la que estos datos deben aislarse enwebsite.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 se debe acceder a la misma cookie en varios sitios, considera usar la API de Storage Access si el usuario visitó streaming.example como nivel superior y los Conjuntos de sitios web relacionados si el conjunto de website.example es propietario de streaming.example.

A partir de Chrome 131, FedCM se integra con la API de Storage Access. Con esta integración, cuando el usuario acepta el mensaje de FedCM, el navegador otorgará acceso integrado al IdP al almacenamiento sin particiones.

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 Embeds.

Otros recorridos del usuario

Los recorridos del usuario 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, el cierre de sesión o la recuperación de la cuenta en el contexto de terceros, la 2FA, deberían funcionar según lo previsto. Ya se describieron los posibles puntos de interrupción. Para obtener más información sobre una API en particular, consulta la página de estado de la API.

Audita 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 para detectar el uso de cookies de terceros, realiza pruebas para detectar fallas y realiza la transición a las soluciones recomendadas.