Cómo controlar el bloqueo de cookies de terceros en exploradores

Muchos exploradores bloquean cookies de terceros, cookies en solicitudes a dominios distintos del dominio que se muestra en la barra de direcciones del explorador. Estas cookies también se conocen como cookies entre dominios. Esto interrumpe el flujo implícito y requiere nuevos patrones de autenticación para que los usuarios inicien sesión correctamente. En la Plataforma de identidad de Microsoft, usamos el flujo de código de autorización con clave de prueba para intercambio de código (PKCE) y tokens de actualización para mantener iniciada la sesión de los usuarios cuando las cookies de terceros están bloqueadas. Este flujo de código de autorización con la clave de prueba para el enfoque de Intercambio de código se recomienda en vez del flujo implícito.

¿Qué es Intelligent Tracking Protection (ITP) y Privacy Sandbox?

Apple Safari cuenta con una característica de protección de la privacidad predeterminada denominada Intelligent Tracking Protection o ITP. Chrome tiene una iniciativa de privacidad del explorador denominada Privacy Sandbox. Estas iniciativas abarcan muchos esfuerzos de privacidad del explorador diferentes por parte de los exploradores y tienen diferentes escalas de tiempo. Ambos esfuerzos bloquean las cookies de "terceros" en solicitudes que cruzan dominios, con Safari y Brave bloquean cookies de terceros de forma predeterminada. Chrome anunció recientemente que empezarán a bloquear cookies de terceros de forma predeterminada. Privacy Sandbox incluye cambios en el almacenamiento con particiones, así como el bloqueo de cookies de terceros.

Una forma común de seguimiento de usuarios es mediante la carga de un iframe en un sitio de un tercero en segundo plano y el uso de cookies para correlacionar al usuario a través de Internet. Desafortunadamente, este patrón también es la forma estándar de implementar el flujo implícito en las aplicaciones de página única (SPA). Un explorador que bloquea las cookies de terceros para proteger la privacidad del usuario también puede bloquear la funcionalidad de una SPA. El uso del flujo implícito en las SPA ya no se recomienda debido al bloqueo de cookies de terceros y a los riesgos de seguridad asociados a él.

La solución que se describe en este artículo funciona en todos estos exploradores o en cualquier lugar donde las cookies de terceros estén bloqueadas.

Descripción de la solución

Para seguir autenticando usuarios en SPA, los desarrolladores de aplicaciones deben usar el flujo de código de autorización. En el flujo de código de autenticación, el proveedor de identidades emite un código, y la SPA canjea el código por un token de acceso y un token de actualización. Cuando la aplicación requiere tokens nuevos, puede usar el flujo de tokens de actualización para obtener nuevos tokens. La Biblioteca de autenticación de Microsoft (MSAL) para JavaScript v2.0 y versiones posteriores implementa el flujo de código de autorización para las SPA y, con actualizaciones secundarias, es un reemplazo inmediato de MSAL.js 1.x. Consulte la guía de migración para mover un SPA de implícito al flujo de código de autenticación.

Para la Plataforma de identidad de Microsoft, las SPA y los clientes nativos siguen una guía de protocolo similar:

• Uso de un desafío de código PKCE
  • PKCE es necesario para las SPA en la Plataforma de identidad de Microsoft. PKCE se recomienda para los clientes nativos y confidenciales.
• Ausencia de un secreto de cliente

Las SPA tienen dos restricciones más:

• El URI de redirección debe estar marcado con el tipo spa para habilitar CORS en los puntos de conexión de inicio de sesión.
• Los tokens de actualización emitidos a través del flujo de código de autorización para los URI de redirección spa tienen una vigencia de 24 horas en lugar de una vigencia de 90 días.

Consecuencias en el rendimiento y la experiencia de usuario

Algunas aplicaciones que usan el flujo implícito intentan iniciar sesión sin redireccionar al abrir un iframe de inicio de sesión mediante prompt=none. En la mayoría de los exploradores, esta solicitud responde con tokens para el usuario que ha iniciado sesión actualmente (suponiendo que se concede el consentimiento). Este patrón significaba que las aplicaciones no necesitaban una redirección de página completa para que el usuario pudiera iniciar la sesión, lo que mejoraba el rendimiento y la experiencia del usuario: el usuario visita la página web y ya tiene la sesión iniciada. Dado que prompt=none en un iframe ya no es una opción cuando se bloquean cookies de terceros, las aplicaciones deben ajustar sus patrones de inicio de sesión para que se emita un código de autorización.

Sin cookies de terceros, hay dos maneras de realizar el inicio de sesión:

• Redirecciones de página completa
  • En la primera carga de la SPA, redirija al usuario a la página de inicio de sesión si no existe ya ninguna sesión (o si la sesión ha expirado). El explorador del usuario visita la página de inicio de sesión, presenta las cookies que contienen la sesión del usuario y, a continuación, se redirige a la aplicación con el código y los tokens en un fragmento.
  • La redirección da lugar a que la SPA se cargue dos veces. Siga los procedimientos recomendados para almacenar las SPA en caché, de modo que la aplicación no se descargue completa dos veces.
  • Considere la posibilidad de tener en la aplicación una secuencia previa a la carga, que compruebe si hay una sesión iniciada y redirija a la página de inicio de sesión antes de que la aplicación se desempaquete completamente y ejecute la carga de JavaScript.
• Elementos emergentes
  • Si la experiencia del usuario (UX) de una redirección de página completa no funciona para la aplicación, considere la posibilidad de usar un elemento emergente para controlar la autenticación.
  • Cuando el elemento emergente termine de redireccionar a la aplicación después de la autenticación, el código del controlador de redirección almacenará el código de autenticación y los tokens en el almacenamiento local para que la aplicación los use. MSAL.js admite elementos emergentes para autenticación, al igual que la mayoría de las bibliotecas.
  • Los exploradores están disminuyendo la compatibilidad con los elementos emergentes, por lo que es posible que no sean la opción más confiable. Puede que la interacción del usuario con la SPA antes de crear el elemento emergente sea necesaria para satisfacer los requisitos del explorador.

Apple describe un método emergente como una corrección de compatibilidad temporal para otorgar a la ventana original acceso a las cookies de terceros. Aunque Apple puede quitar esta trasmisión de permisos en el futuro, no afectará a la guía que aquí se da.

En este caso, el elemento emergente se usa como navegación propia a la página de inicio de sesión para que se encuentre una sesión y se pueda proporcionar un código de autenticación. Esto debería seguir funcionando en el futuro.

Los desarrolladores pueden seguir usando prompt=none con la expectativa de que ven una tasa más alta de errores de interacion_required cuando se bloquean las cookies de terceros. La recomendación es tener siempre una reserva de método interactivo, si se producen errores durante la adquisición silenciosa de tokens.

Uso de iframes

Un patrón común en las aplicaciones web es usar un iframe para insertar una aplicación dentro de otra: el marco de nivel superior controla la autenticación del usuario y la aplicación hospedada en el iframe puede confiar en que el usuario ha iniciado sesión, capturando tokens de forma silenciosa mediante el flujo implícito. Sin embargo, hay un par de advertencias en relación con esta suposición, independientemente de si las cookies de terceros están habilitadas o bloqueadas en el explorador.

La adquisición de tokens silenciosa ya no funciona cuando se han bloqueado las cookies de terceros: la aplicación incrustada en el iframe debe cambiar al uso de elementos emergentes para tener acceso a la sesión del usuario, ya que no puede navegar a la página de inicio de sesión dentro de un marco insertado.

Puede conseguir un inicio de sesión único entre las aplicaciones iframed y padre con acceso a la API de script del mismo origen y de origen cruzado pasando una pista de usuario (cuenta) de la aplicación padre a la aplicación iframed. Para obtener más información, vea Uso de MSAL.js en aplicaciones con iframed en el repositorio MSAL.js en GitHub.

Consecuencias de seguridad de los tokens de actualización en el explorador

Los ataques de scripts de sitios (XSS) o los paquetes JS en peligro pueden robar el token de actualización y usarlo de forma remota hasta que expire o se revoque. Los desarrolladores de aplicaciones son responsables de reducir el riesgo de su aplicación en el scripting entre sitios. Para minimizar el riesgo de los tokens de actualización robados, los SPA son tokens emitidos válidos solo durante 24 horas. Después de las 24 horas, la aplicación debe adquirir un nuevo código de autorización a través de una visita de marco de nivel superior a la página de inicio de sesión.

Este patrón de token de actualización de vigencia limitada se eligió como equilibrio entre la seguridad y la experiencia de usuario degradada. Sin tokens de actualización ni cookies de terceros, el flujo de código de autorización (tal y como se recomienda en el borrador de procedimientos recomendados actuales de seguridad de OAuth) se vuelve más oneroso cuando se requieren tokens nuevos o adicionales. Se necesita una redirección de página completa o un elemento emergente para cada token único, cada vez que un token expira (en general, cada hora en el caso de los tokens de la Plataforma de identidad de Microsoft).

Mitigaciones específicas del tipo de usuario

No todos los usuarios y aplicaciones se ven afectados uniformemente por cookies de terceros. Hay algunos escenarios en los que debido a la arquitectura o la administración de dispositivos, las llamadas silenciosas a los tokens se pueden realizar sin cookies de terceros.

En escenarios de dispositivos empresariales administrados, ciertas combinaciones de exploradores y plataformas admiten acceso condicional de dispositivo. La aplicación de la identidad del dispositivo minimiza la necesidad de cookies de terceros, ya que el estado de autenticación puede provenir del dispositivo en lugar del explorador.

Para escenarios de aplicaciones de Azure AD B2C, los clientes pueden configurar un dominio de inicio de sesión personalizado para que coincida con el dominio de la aplicación. Los exploradores no bloquearían las cookies de terceros en este escenario, ya que las cookies permanecen en el mismo dominio (como login.contoso.com a app.contoso.com).

Limitaciones en el cierre de sesión del canal frontal sin cookies de terceros

Al cerrar sesión de un usuario desde una SPA, MSAL.js recomienda usar el método emergente o redireccionamiento de cierre de sesión. Aunque esto borra la sesión de autenticación en el servidor y en el almacenamiento del explorador, existe el riesgo de que sin acceso a cookies de terceros, no todas las aplicaciones federadas verán un cierre de sesión al mismo tiempo. Se trata de una limitación conocida de la especificación OpenID Front-Channel Logout 1.0. Lo que significa para los usuarios es que los tokens de acceso existentes para otras aplicaciones para el mismo usuario seguirán siendo válidos hasta su hora de expiración. Un usuario podría cerrar la sesión de la aplicación A en la pestaña A, pero la aplicación B en la pestaña B seguirá apareciendo como iniciada para el tiempo válido restante del token de acceso. Cuando expira el token de la aplicación B y se realiza una llamada al servidor para obtener un nuevo token, la aplicación B recibe una respuesta del servidor que la sesión ha expirado y pide al usuario que se autentique.

La página de cierre de sesión de Microsoft y procedimientos recomendados de privacidad de Internet recomienda que los usuarios cierren todas las ventanas del explorador después de cerrar la sesión de una aplicación.

Pasos siguientes

Para obtener más información sobre el flujo de código de autorización MSAL.js, consulte:

• Flujo de código de autorización.
• Inicio rápido de MSAL.js 2.0.