Chrome propone una nueva experiencia para la elección de los usuarios con 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 los escenarios de acceso con más probabilidades verse afectadas, así como referencias a posibles soluciones.
Si su sitio web solo maneja flujos dentro del mismo dominio y subdominios,
como publisher.example y login.publisher.example, no usará datos entre sitios
cookies 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 con Acceso con Google o Acceso con Facebook, o bien tu sitio debe compartir contenido autenticación en varios dominios o subdominios, existe la posibilidad de que necesitamos realizar cambios en tu sitio para garantizar una transición sin inconvenientes desde cookies entre sitios.
Prueba los recorridos del usuario relacionados con la identidad
La mejor manera de probar si tu flujo de acceso se ve afectado por una cookie de terceros cambios es realizar el registro, la recuperación de la contraseña, el acceso flujos de cierre de sesión con la marca de prueba de cookies de terceros habilitada
Esta es una lista de verificación de lo que debes verificar una vez que hayas restringido la restricción de uso de terceros cookies:
- Registro de usuarios: La creación de una cuenta nueva funciona según lo previsto. Si se utiliza proveedores de identidad externos, comprueba que funcione el registro de cuentas nuevas para cada integración.
- Recuperación de contraseñas: La recuperación de contraseñas funciona como se espera desde la IU web. a los CAPTCHA o al correo electrónico de recuperación de contraseña.
- Acceso: El flujo de trabajo de acceso funciona dentro del mismo dominio y cuando navegando a otros dominios. Recuerda probar cada integración de acceso.
- Cierre de sesión: El proceso de salida funciona según lo esperado y el usuario permanece luego de que se cierre la cuenta.
También debes probar que otras funciones del sitio que requieren el acceso del usuario permanezcan funcionan sin cookies entre sitios, en especial si implican la carga recursos entre sitios. Por ejemplo, si usas una CDN para cargar imágenes de perfil asegurarse de que esto siga funcionando. Si tienes recorridos del usuario críticos, como y hacer compras, y un acceso restringido, asegúrate de que sigan funcionando.
En las siguientes secciones, encontrarás información más específica sobre cómo esos flujos podrían verse afectados.
Identidad federada
Botones de acceso, como Acceder con Google, Acceso con Facebook y Acceder con Twitter es una señal definitiva de que tu sitio web utiliza un de identidad federada. Como cada proveedor de identidad federada tendrá su propia implementación, la mejor solución es verificar documentación o comunícate con ellos para obtener más orientación.
Si usas la versión obsoleta En la biblioteca de la plataforma JavaScript de Acceso con Google, puedes encontrar información sobre cómo migrar a la biblioteca más reciente de Google Identity Services para la autenticación y autorización.
La mayoría de los sitios que usan la biblioteca más reciente de Google Identity Services están listos para baja de las cookies de terceros, ya que la biblioteca migrará silenciosamente a usando FedCM para garantizar la compatibilidad. Te recomendamos que pruebes tu sitio con la marca de prueba de cookies de terceros habilitada y, si es necesario, con la lista de tareas de migración de FedCM para prepararte.
Dominio de acceso independiente
Algunos sitios web usan un dominio diferente solo para autenticar a los usuarios que no lo hacen
calificar para cookies del mismo sitio, como un sitio web que usa example.com para la
sitio y login.example para el flujo de acceso, que podrían requerir ingresar
cookies de terceros para garantizar que el usuario se autentique en
dominios.
Las posibles rutas de migración para esta situación son las siguientes:
- Actualización para usar cookies propias ("mismo sitio"): Cambio de la infraestructura de sitio web para que el flujo de acceso esté alojado en el mismo dominio (o en una subdominio) como el sitio principal, que solo usará cookies propias. Esto puede requerir un mayor esfuerzo, según cómo esté configurada la infraestructura.
- Utiliza Conjuntos de sitios web relacionados (RWS): Habilitar Conjuntos de sitios web relacionados acceso limitado de cookies entre sitios entre un pequeño grupo de dominios relacionados. RWS es una API de Privacy Sandbox creada para admitir este caso de uso. Sin embargo, solo RWS admite el acceso de cookies entre sitios en una cantidad limitada de dominios.
- Si autenticas usuarios en más de 5 dominios asociados, explora FedCM: La administración de credenciales federadas (FedCM) permite que los proveedores de identidad dependan de Chrome para manejar los flujos relacionados con la identidad sin que requieran cookies de terceros. En tu caso, tu "dominio de acceso" podría actuar como el proveedor de identidad de FedCM y se usará para autenticar usuarios en tu otra dominios.
Varios dominios
Cuando una empresa tiene varios productos alojados en distintos dominios o subdominios, es posible que quiera compartir la sesión del usuario en esos productos, lo que puede requieren el acceso a cookies de terceros entre varios dominios.
En este caso, alojar todos los productos en el mismo dominio poco práctico. Las posibles soluciones en este caso son las siguientes:
- Usar Conjuntos de sitios web relacionados: Cuando se necesita acceso a cookies entre sitios en un grupo pequeño de dominios relacionados.
- Usar Federation Credential Management (FedCM): Cuando la cantidad de es grande, puedes usar un dominio de acceso independiente para que actúe y autentica a los usuarios en tus sitios con FedCM.
Soluciones de acceso
Inicio de sesión único (SSO) de terceros
Debido a la complejidad de implementar una solución de SSO, muchas empresas aceptan usando un proveedor de soluciones de terceros, para compartir el estado de acceso entre varias orígenes. Algunos ejemplos de proveedores son Okta, Ping Identity, Google Cloud IAM o Microsoft Entra ID.
Cuando se recurre a un proveedor externo, el mejor enfoque es buscar orientación al proveedor sobre cómo los cambios en las cookies de terceros afectarán a la solución qué enfoque recomiendan para su servicio.
Soluciones de SSO de código abierto
Muchas empresas que mantienen sus propias soluciones de SSO lo hacen con herramientas estándares de la industria, como OpenID Connect, OAuth o SAML, o estándares de proyectos de origen, como Keycloak, WSO2, Auth.js o Hydra.
Recomendamos que consultes la documentación para que tu proveedor comprenda los cambios en las cookies podrían afectar su solución, y la mejor ruta de migración para esa solución específica.
Soluciones internas personalizadas
Si tu solución de acceso se incluye en uno de los casos de uso anteriores y se crea interno, el artículo Prepárate para la eliminación gradual de las cookies de terceros explica en más detalle detallan cómo auditar su código y prepararse para los cambios relacionados con las cookies de terceros.
Actúa ya.
Si tu sitio web corresponde a alguno de los casos de uso, hay varias soluciones disponibles para abordar cualquier impacto posible, desde mover el flujo de autenticación el dominio principal para que solo use cookies propias, con Conjuntos de sitios web relacionados para permitir compartir cookies entre un pequeño número de dominios, o bien aprovechar Federation Credential Management.
El momento para auditar su servicio y prepararse para la cookie de terceros cambios ahora es.