Configurar el uso compartido de recursos entre distintos orígenes

Describe cómo configurar el uso compartido de recursos entre distintos orígenes (CORS) para una aplicación registrada en Auth0 mediante el Auth0 Dashboard.

Antes de comenzar

• Por motivos de seguridad, la URL de origen de su aplicación debe estar incluida entre las URL aprobadas. Si todavía no la agregó a Allowed Callback URLs de su aplicación, deberá agregarla a la lista de Allowed Origins (CORS).
• Asegúrese de que Allowed Web Origins en la vista Settings de su aplicación esté configurado con el dominio desde el que se realiza la solicitud. Las URL pueden contener comodines para subdominios, pero no pueden contener rutas relativas después de la URL del dominio. Para obtener más información, lea Marcadores de posición para subdominios.
• Si no habilita dominios personalizados, deberá crear una página de verificación que use Auth0.js como mecanismo de respaldo para la autenticación entre orígenes.

El uso compartido de recursos entre orígenes (CORS) es un mecanismo que permite que una aplicación cargue datos (recursos) desde un dominio (origen) distinto de aquel en el que está alojada. Una política de CORS es una excepción explícita a la política del mismo origen, común en las aplicaciones web.

Por ejemplo, si quisiera que su aplicación (app.mydomain.com) cargara una fuente de Google (fonts.google.com) en segundo plano mediante Ajax, tendría que configurar CORS.

​

Configurar la autenticación entre orígenes

1. Vaya a Dashboard > Applications > Applications y haga clic en el nombre de la aplicación para abrirla.
2. En Cross-Origin Authentication, active Allow Cross-Origin Authentication.
3. Busque Allowed Origins (CORS) e introduzca la URL de origen de su aplicación. Para obtener más información sobre los orígenes, consulte Origin on Mozilla MDN Web Docs.
4. Haga clic en Save Changes.

Si no necesita usar CORS en su aplicación, asegúrese de que Allow Cross-Origin Authentication esté desactivado.

​

Crear una página de verificación entre orígenes

Hay casos en los que las cookies de terceros no estarán disponibles. Algunas versiones de navegadores no admiten cookies de terceros y, aun cuando las admiten, es posible que estén deshabilitadas en la configuración del usuario.

En los navegadores compatibles, puede usar el método crossOriginVerification del SDK de Auth0.js en una página específica de su aplicación para gestionar los casos en los que las cookies de terceros estén deshabilitadas.

En los navegadores no compatibles, como Chrome, Opera y Safari, la autenticación entre orígenes no funcionará cuando las cookies de terceros estén deshabilitadas, a menos que habilite dominios personalizados.

En Safari, esta configuración aparece como “Prevent cross-site tracking” y usa Intelligent Tracking Prevention. Lamentablemente, esto también impide que las cookies de terceros resulten útiles en escenarios de autenticación. Este es un ejemplo de cómo afecta a la renovación de tokens.

1. Cree una página en su aplicación que instancie WebAuth de Auth0.js. Llame a crossOriginVerification de inmediato. Puede asignarle el nombre que prefiera.

Cuando las cookies de terceros no están disponibles, Auth0.js renderiza un iframe para invocar un flujo de verificación de autenticación entre orígenes distinto. 2. Vaya a Dashboard > Applications > Applications y seleccione la aplicación que quiere ver. 3. En Cross-Origin Authentication, agregue la URL de la página de callback que creó en el campo Cross-Origin Verification Fallback URL.

En entornos de producción, verifique que la URL de la página no apunte a localhost. La página debe estar en el mismo dominio en el que se aloja el formulario de inicio de sesión integrado y debe usar el esquema https.

4. Haga clic en Save Changes.

Para obtener más detalles, consulte el ejemplo de autenticación entre orígenes en GitHub.

​

Códigos y descripciones de error

Las descripciones de error están pensadas para que sean legibles para las personas. Pueden cambiar en cualquier momento y no deben ser procesadas por ningún código.

Cuando se usa Auth0.js v9 (y Lock) para el inicio de sesión integrado, llama al endpoint /co/authenticate, que puede devolver los siguientes errores:

Estado	Código	Descripción
400	invalid_request	Cuerpo de la solicitud no válido. Se requieren todos y únicamente client_id, credential_type, username, otp y realm.
400	unsupported_credential_type	Parámetro de tipo de credencial desconocido.
400	invalid_request	Realm desconocido: non-existent-connection.
401	unauthorized_client	No se permite el inicio de sesión entre orígenes.
401	password_leaked	Este intento de inicio de sesión se ha bloqueado porque la contraseña que estás usando se expuso anteriormente en una filtración de datos (no en esta aplicación).
403	access_denied	Correo electrónico o contraseña incorrectos.
403	access_denied	Error de autenticación
403	blocked_user	Usuario bloqueado
429	too_many_attempts	Tu cuenta se ha bloqueado tras varios intentos consecutivos de inicio de sesión. Te hemos enviado una notificación a través de tu método de contacto preferido con instrucciones para desbloquearla.
429	too_many_attempts	Hemos detectado un comportamiento de inicio de sesión sospechoso y se bloquearán más intentos. Ponte en contacto con el administrador.

Además, también puedes recibir un error 403 genérico sin una propiedad error o error_description. El cuerpo de la respuesta solo incluiría algo similar a lo siguiente:

Origin https://test.app is not allowed.

​

Compatibilidad para pruebas en navegadores

Los siguientes navegadores pueden usar autenticación entre orígenes cuando las cookies de terceros están deshabilitadas:

• Microsoft Internet Explorer

Atributos de la cookie SameSite

Anteriormente, las opciones del atributo de cookie samesite eran true, false, strict o lax. Si no configuraba el atributo manualmente, Auth0 usaba el valor predeterminado false.

A partir de febrero de 2020, Google Chrome v80 cambió la forma en que maneja las cookies, y Auth0 implementó los siguientes cambios en consecuencia:

• Las cookies sin el atributo samesite configurado se establecerán en 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 de falsificación de solicitudes entre sitios (CSRF).

​

Más información

• Inicio de sesión integrado
• Autenticación entre orígenes
• Configuración de la aplicación
• Cambios en el atributo de cookie SameSite