> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Describe cómo los cambios en el navegador, como el atributo de cookie SameSite, afectan a sus aplicaciones web que incrustan contenido de dominios de terceros.
# Cambios en el atributo de cookie SameSite
Las cookies, que se utilizan para la autenticación y el mantenimiento de sesiones, pueden protegerse configurando atributos. Auth0 utiliza cookies para lo siguiente:
* OIDC Enterprise con `form_post`
* SAML HTTP-POST Binding
* Mensaje web (también conocido como `checkSession`)
## Atributos SameSite
Puede agregar atributos de [cookies SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite) en el encabezado de respuesta HTTP `set-cookie` para restringir el comportamiento del navegador. Esto puede impedir que el navegador envíe el par `key=value` de la cookie según el tipo de interacción que haya desencadenado la solicitud HTTP.
Los valores de atributo admitidos son los siguientes:
| Atributo | Descripción |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `strict` | Envía la cookie si el usuario navega dentro de los límites del origen del sitio web |
| `lax` | Envía la cookie si el usuario navega entre dominios, pero no en contextos de terceros (iframes o envíos de formularios) |
| `none` | Envía la cookie con solicitudes que cruzan los límites del origen del sitio web. A menos que se den otras condiciones (por ejemplo, que las cookies de terceros estén bloqueadas), no envíe la cookie. |
Algunos de los atributos de cookies con los que quizá ya esté familiarizado incluyen:
| Atributo | Descripción |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `httpOnly` | Permite que una cookie se envíe solo con solicitudes HTTP; no se puede leer mediante `document.cookie` de JavaScript |
| `secure` | Permite que el navegador envíe la cookie solo a un contexto seguro; que el contexto se considere seguro o no depende del navegador, pero esto normalmente requiere el uso de HTTPS |
| `max-age / expires` | Controla si la cookie es de **sesión** (por ejemplo, se elimina cuando el navegador finaliza su sesión) o **persistente** (por ejemplo, la cookie se conserva después de la sesión del navegador) |
Cuando recibe la respuesta, el navegador analiza los encabezados y actualiza su almacén de cookies en consecuencia.
## Cambios en las cookies del navegador
A partir de febrero de 2020, Google Chrome v80 cambió la forma en que gestiona las cookies. Auth0 implementó los siguientes cambios en la forma en que gestiona las cookies:
* Las cookies sin el atributo `SameSite` establecido se configurarán como `lax`
* Las cookies con `SameSite=none` deben ser seguras; de lo contrario, no se pueden guardar en el almacén de cookies del navegador
El objetivo de estos cambios es mejorar la seguridad y ayudar a mitigar los ataques CSRF.
Estos cambios afectan a las siguientes cookies:
* `auth0` (gestiona las sesiones de usuario)
* `auth0-mf` (gestiona la información relevante para la autenticación multifactor)
* `did` (el identificador de un dispositivo/agente de usuario)
Para estas cookies, Auth0 hará lo siguiente:
* Establecerá el atributo `SameSite` en `none`, por lo que la cookie requerirá el uso de HTTPS (independientemente del entorno)
* Establecerá cookies de respaldo en caso de que un navegador heredado no admita que `SameSite` se establezca en `None`. Estas cookies de respaldo son `auth0_compat`, `auth0-mf_compat` y `did_compat`
El siguiente diagrama muestra lo que ocurre durante una interacción inicial. El usuario final solicita una página que no había visitado antes. El servidor cambia la forma en que la representa cuando el visitante regresa y establece una cookie de visto. La parte gris del encabezado `set-cookie` es la cookie real `key=value.` La parte roja corresponde a los atributos de la cookie que el navegador almacena en el almacén de cookies para decidir más adelante si debe incluir el par de cookie `key+value` en las solicitudes.
El siguiente diagrama muestra lo que ocurre si realiza la misma solicitud en la misma sesión de navegación. La solicitud va al mismo servidor y, como los atributos de la cookie no impiden que se envíe la cookie de visto, se incluye automáticamente como encabezado de cookie en la solicitud. El servidor ahora responderá de forma diferente en función de haber recibido esta cookie.
## Funciones afectadas
La siguiente tabla muestra cómo los cambios en el atributo `SameSite` pueden afectar a sus aplicaciones.
| Comportamiento de la aplicación | Afectada por el cambio |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- |
| Cookies configuradas como `sameSite=none` cuando el sitio web no es `https://` | Sí |
| Las cookies no tienen establecido un valor explícito para el atributo `sameSite` y son necesarias en un contexto de origen cruzado (como `form_post` de HTTP o la inserción de un iframe) | Sí |
| Aplicaciones nativas (todo lo que no sean cookies + basado en web) | No (M2M) |
| Ya se está estableciendo un valor explícito para el atributo de cookie `sameSite` | No |
| Subdominio diferente en el mismo eTLD+1 (la aplicación está en el mismo eTLD+1 que el dominio personalizado del inquilino de Auth0) | Potencialmente |
Si está utilizando una aplicación web con sesiones (por ejemplo, para guardar preferencias de usuario, carritos de compra, etc.) y permite que los usuarios inicien sesión usando proveedores de identidad como Google, GitHub o Auth0, entonces depende de las cookies para que esa funcionalidad sea posible. Hay cambios en el comportamiento de las cookies del navegador que pueden afectar la experiencia del usuario. Google Chrome, por ejemplo, es el primer fabricante de navegadores en implementar un cambio que podría no ser compatible con su aplicación web.
Puede notar que las especificaciones de Google Chrome y Microsoft Edge para establecer `SameSite` como no definido han cambiado de usar `none` como valor predeterminado de `SameSite` a `lax`.
Por ejemplo, supongamos que crea una nueva IU y tiene varios servicios a los que accede mediante proxy a través de una puerta de enlace de Auth0. En esta puerta de enlace, crea una sesión basada en cookies. Si realiza una solicitud de origen cruzado, puede ver esta advertencia en la consola de JavaScript:
`A cookie associated with a cross-site resource (URL) was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032`
## Acciones que debe realizar
Para prepararse para este cambio, debe:
* Revisar la lista de [navegadores incompatibles](https://www.chromium.org/updates/same-site/incompatible-clients).
* Configurar su aplicación para usar `SameSite=none` si utiliza `response_mode=form_post` al interactuar con Auth0 (tenga en cuenta que Chrome no hace excepciones, ni siquiera para `localhost`)
* Marcar su cookie como segura si su atributo `SameSite` es igual a `None.` De lo contrario, el navegador la rechazará. Si usa HTTP para sus URL de callback, estas dejarán de funcionar si utiliza esas cookies para asociar el estado de la solicitud de autorización/nonce. Por lo tanto, debe usar HTTPS o configurar `SameSite=lax`