Propiedades protegidas en conexiones sociales no personalizadas
Obsoleto: 30 de julio de 2024Fin de vida: 31 de enero de 2025Los endpoints de Management API para conexiones (GET, POST y PATCH) ya no permitirán recuperar ni establecer valores para las siguientes propiedades protegidas en el contexto del objeto options de las conexiones sociales no personalizadas:
authorizationURL
tokenURL
userInfoUrl
baseUrl
userAuthorizationURL
grant_type
authorizationURL
tokenURL
userInfoUrl
baseUrl
userAuthorizationURL
grant_type
Las conexiones sociales no personalizadas son aquellas cuya lógica de implementación está controlada por completo por el propio servicio de Auth0. Esta categoría excluye cualquier conexión creada explícitamente como conector social personalizado o disponible como integración de Marketplace que dependa de la funcionalidad de conexión social personalizada.
Eliminación indebida de sesiones tras actualizaciones de usuarios mediante la Management API
Obsoleto: 11 de febrero de 2025Fin de vida: 19 de agosto de 2025El endpoint actualizar un usuario (PATCH /api/v2/users/{id}) ya no invalidará las sesiones de los usuarios de conexiones de base de datos cuando:
Los atributos email o email_verified se establezcan en un valor sin cambios.
El atributo email_verified se establezca en el valor true.
Obsoleto: 29 de octubre de 2024Fin de vida útil: 29 de abril de 2025El servicio de Auth0 exigirá el uso de Server Name Indication (SNI) para todas las solicitudes HTTPS. SNI es una extensión del protocolo TLS que permite al cliente indicar el nombre de host al que pretende conectarse al inicio del proceso de negociación.Desde su creación, la gran mayoría de nuestros entornos de nube privada y algunos de nuestros entornos de nube pública han exigido SNI. Por ejemplo, los entornos de nube pública CA-1, JP-1 y UK-1 siempre han requerido SNI.Con este cambio, el requisito de SNI se aplicará a los entornos restantes. Para obtener información más detallada sobre los plazos específicos de cada entorno, lea el artículo Implementación del fin de vida útil del uso obligatorio de SNI para las solicitudes HTTPS.
Obsoleto: 4 de septiembre de 2024Fin de vida útil: 4 de octubre de 2024A partir del 4 de octubre de 2024, Auth0 dejará de redirigir automáticamente a HTTPS seguro las solicitudes a la API que usen HTTP sin cifrar y responderá con un error. Para evitar cualquier interrupción del servicio, actualice las URL HTTP que use o publique para que utilicen HTTPS en su lugar.
Transición de la Management API: actualización de la asignación de roles para requerir el scope de creación
Obsoleto: 7 de marzo de 2024Fin de vida: 10 de septiembre de 2024Los alcances de la Management API para el endpoint User-Roles (POST /api/v2/users/{id}/roles) requerirán el scope create:role_members. Esto refleja mejor los permisos previstos para ese scope.Anteriormente, se podían asignar roles a usuarios con el scope read:roles.
Actualiza las aplicaciones que usan autenticación entre orígenes
Obsoleto: 25 de abril de 2024Fin de vida: 10 de octubre de 2024Las aplicaciones nuevas creadas en Auth0 tendrán la autenticación entre orígenes deshabilitada de forma predeterminada. Será necesario modificar las llamadas a algunos endpoints de la Management API (Get Clients, Get Client by ID) para usar cross_origin_authentication.
Eliminar el acceso a Subscription Tickets para los administradores del Tenant
Obsoleto: 5 de junio de 2024Fin de vida: 5 de agosto de 2024El acceso para ver Subscription Tickets en el Auth0 Support Center cambiará el 5 de agosto de 2024. Para conservar el acceso para ver y gestionar todos los tickets de soporte creados por cualquier usuario del Tenant, se requiere el nuevo rol Elevated Support Access.
Deprecación de los enlaces de Restablecimiento de contraseña y Verificación de correo electrónico en los registros del Tenant
Obsoleto: 7 de diciembre de 2023Fin de vida útil: 5 de febrero de 2024Los enlaces de restablecimiento de contraseña y verificación de correo electrónico dejarán de registrarse en los registros del Tenant. Estos enlaces pueden obtenerse de la respuesta a la solicitud de restablecimiento de contraseña o de verificación de correo electrónico de la .
Reducción del tiempo máximo de expiración de las transacciones de inicio de sesión
Obsoleto: 5 de septiembre de 2023 (Public Cloud), 21 de noviembre de 2023 (Private Cloud)Fin de vida: 21 de febrero de 2024Con este cambio, aplicaremos una duración máxima de 1 hora a los flujos de inicio de sesión basados en redirección. Los flujos de inicio de sesión que tarden más de 1 hora en completarse expirarán tanto en Universal Login como en Classic Login. Tras la expiración, las acciones posteriores desde el navegador del usuario final (por ejemplo, introducir el correo electrónico/la contraseña, redirigir de nuevo a Actions/Rules, etc.) provocarán uno de los siguientes resultados:
Una redirección a la ruta de inicio de sesión predeterminada de la aplicación asociada para reiniciar el flujo como una nueva transacción de inicio de sesión, o
Una página de error si la ruta de inicio de sesión predeterminada no está configurada.
Deprecación de alcances no registrados en tokens de actualización
Obsoleto: 12 de julio de 2023Fin de vida: 17 de enero de 2024Estamos mejorando la evaluación de alcances durante el intercambio de para garantizar que no se puedan solicitar alcances no registrados. Los valores de alcances personalizados que no estén registrados para el valor aud o audience (de una API registrada en su Tenant) se consideran alcances no registrados.Con este cambio, la evaluación de alcances de la API incluirá cualquier alcance personalizado solicitado durante la autenticación del usuario o inyectado mediante extensibilidad, como Rules. Esta evaluación validará que todos los alcances estén registrados y devolverá un error si alguno no lo está.
Deprecación de los repositorios auth0-cordova, angular-auth0 y express-oauth2-bearer
Obsoleto: 27 de abril de 2023Fin de vida útil: 30 de junio de 2023 (express-oauth2-bearer), 27 de octubre de 2023 (angular-auth0 y auth0-cordova)Hemos deprecado los siguientes repositorios:
Estas bibliotecas ya no recibirán soporte. Elimine estas bibliotecas de cualquier proyecto activo antes de esas fechas.Si tiene alguna pregunta o inquietud, contáctenos en GitHub.
Fecha objetivo de migración: 11 de sept. de 2023Como parte de nuestra misión de dar soporte, a través de Actions, a todas las futuras versiones LTS de Node.js y de mantenernos alineados con la comunidad de desarrolladores de Node.js, lanzamos Node 18 mientras Node 16 aún se encuentra en LTS activo. Instamos a todos los clientes a migrar hoy mismo a Node 18 y aprovechar al máximo su ciclo LTS. Recuerde que, aunque Node 16 LTS seguirá disponible hasta septiembre, su uso puede implicar ciertos riesgos una vez finalizado el período de LTS, por lo que le recomendamos actualizar a Node 18.Node.js 18 ya está disponible de forma general (GA) en todo nuestro conjunto de opciones de extensibilidad. Esto incluye Actions, Rules, Hooks, scripts de base de datos y Social Connections personalizadas. Recomendamos encarecidamente a todos actualizar a Node 18 antes del 11 de sept. de 2023 para seguir las mejores prácticas de seguridad del código.
Compatibilidad con edge.js en las funcionalidades de extensibilidad
Obsoleto: 21 de diciembre de 2022Fin de vida: 21 de junio de 2023Después del 21 de junio de 2023, Auth0 dejará de admitir la ejecución de .NET y C# desde Node.js en las funcionalidades de extensibilidad. Anteriormente, Auth0 admitía un subconjunto del lenguaje C# para escribir código de extensibilidad para Rules, Hooks y scripts de base de datos personalizada mediante un módulo de Node.js llamado edge.js.La retirada de la compatibilidad con la ejecución de .NET y C# desde Node.js en extensibilidad es fundamental para mantener una plataforma segura y de alto rendimiento para ejecutar código no confiable. Este cambio nos permitirá seguir mejorando nuestra oferta de extensibilidad de nueva generación.
Para obtener más información, consulte Migrar desde las funcionalidades de extensibilidad con edge.js.
Compatibilidad con oracledb en las características de extensibilidad
Obsoleto: 21 de diciembre de 2022Fin de vida útil: 21 de junio de 2023Auth0 dejará de ofrecer soporte para el add-on auth0-claims-provider para SharePoint 2010/2013 después del 31 de julio de 2023.Después del 21 de junio de 2023, Auth0 dejará de admitir la conexión a bases de datos Oracle desde Node.js en las características de extensibilidad. Anteriormente, Auth0 admitía la conexión a bases de datos Oracle desde código de extensibilidad para Rules, Hooks y scripts de base de datos personalizada mediante un módulo de Node.js llamado oracledb.La retirada del soporte para conectarse a bases de datos Oracle desde Node.js en las características de extensibilidad es fundamental para mantener una plataforma segura y de alto rendimiento para ejecutar código no confiable. Este cambio nos permitirá seguir mejorando nuestras soluciones de extensibilidad de próxima generación.Para obtener más información, consulta Migrar desde las características de extensibilidad de oracledb.
Proveedor de claims de Auth0 para SharePoint 2010 / 2013
Obsoleto: 31 de enero de 2023Fin de vida útil: 31 de julio de 2023Auth0 dejará de ofrecer soporte para el complemento auth0-claims-provider para SharePoint 2010/2013 después del 31 de julio de 2023. Sin este complemento, no podrá usar el “Selector de personas de SharePoint” con conexiones de Auth0 para asignar permisos a usuarios de SharePoint 2010/2013.Debe eliminar cualquier integración con el complemento auth0-claims-provider antes del 31 de julio de 2023. Después de esa fecha, cualquier integración restante con el complemento auth0-claims-provider dejará de funcionar correctamente y podría afectar a los usuarios de sus aplicaciones.
Paginación con checkpoint en el endpoint Get Role Users
Obsoleto: 9 de noviembre de 2022Fin de vida útil: 9 de mayo de 2023Para mejorar el rendimiento, el endpoint Get Role Users de la Management API solo devolverá más de 1.000 resultados totales si se utiliza el método de paginación con checkpoint. Este método de paginación está optimizado para manejar grandes volúmenes de resultados. El método de paginación por desplazamiento estará limitado a 1.000 resultados.Para obtener detalles de implementación sobre los dos métodos de paginación, consulte la documentación de la Management API para el endpoint Get Role Users.
Obsoleto: 28 de julio de 2022 (Public Cloud), 31 de agosto de 2022 (Private Cloud)Fin de vida: 30 de enero de 2023 (Public Cloud), 18 de abril de 2023 (Private Cloud)A partir del 30 de enero de 2023 en Public Cloud y del 18 de abril de 2023 en Private Cloud, Auth0 permitirá agregar claims personalizados sin espacio de nombres a los tokens mediante Actions de Auth0 y en las respuestas del endpoint /userinfo de Authentication API. Anteriormente, Auth0 permitía claims con espacio de nombres en los tokens de acceso y los mediante código de extensibilidad (Rules / Hooks / Actions). La migración a claims personalizados permite agregar claims personalizados privados sin espacio de nombres y claims de perfil de usuario de OIDC a los ; actualmente, los ID Token admiten claims de perfil de usuario y, además, admitirán claims personalizados privados sin espacio de nombres. Estos claims también se agregarán a la respuesta /userinfo de Auth0. Para comenzar la migración, lea la Guía de migración de claims personalizados.Si su Tenant ejecuta código de extensibilidad (Rules / Hooks / Actions) que intenta establecer claims personalizados sin espacio de nombres que se han ignorado hasta esta deprecación, esos claims comenzarán a aparecer en los tokens y en la respuesta de /userinfo. Le recomendamos revisar su configuración y los registros de Auth0.Con la incorporación de claims privados sin espacio de nombres, Auth0 aplica las siguientes restricciones que podrían afectar a su Tenant:
Auth0 limitará la carga útil de los claims personalizados a un máximo de 100 KB.
Auth0 restringirá la personalización o modificación de claims estándar de o de claims que Auth0 utiliza internamente.
En el futuro, Auth0 podría restringir el uso de otros claims no incluidos en la lista anterior. En esos casos, se notificará a los clientes con un plazo razonable para migrar.
Auth0 restringirá la creación de claims personalizados privados sin espacio de nombres en tokens de acceso con una de Auth0, excluido el endpoint /userinfo.
Solo se pueden agregar a los tokens de acceso los claims de perfil de usuario de OIDC especificados.
Auth0 restringirá la creación de claims personalizados que comiencen con el carácter $.
Obsoleto: 13 de junio de 2022Fin de vida útil: 31 de enero de 2023Estamos mejorando la infraestructura subyacente que da soporte a Auth0 Private Cloud mediante la incorporación de una pila tecnológica moderna basada en Kubernetes, así como actualizaciones de la base de datos. Actualmente estamos trabajando con todos los clientes de Auth0 Private Cloud para programar la actualización de su implementación de private cloud a la nueva pila de infraestructura a lo largo de este año, y dejaremos de dar soporte a la pila anterior el 31 de enero de 2023.Además, la versión 2205 (lanzamiento de mayo de 2022) es la última versión oficial de la plataforma heredada de Private Cloud. Cualquier error o vulnerabilidad de seguridad se evaluará y se corregirá en versiones de parche según sea necesario. Antes de actualizar a la nueva pila de infraestructura, los entornos deberán actualizarse a la versión mínima compatible para que la actualización sea posible.Ponte en contacto con tu Technical Account Manager si tienes alguna pregunta.
Obsoleto: 4 de mayo de 2022 (Public Cloud), 9 de junio de 2022 (versión 2205 de Private Cloud)Fin de vida útil: 2 de mayo de 2023 (Public Cloud), 6 de enero de 2023 (Private Cloud)A partir del 4 de mayo de 2022 en Public Cloud y del 9 de junio de 2022 en Private Cloud, las siguientes extensiones de log de Auth0 quedarán obsoletas:
Auth0 Authentication API Webhooks
Auth0 Management API Webhooks
Logs to CloudWatch
Logs to Logentries
Logs to Loggly
Logs to Logstash
Logs to Papertrail
Logs to Splunk
Logs to Sumo Logic
Obsoleto: 2 de noviembre de 2022 (Public Cloud), 21 de diciembre de 2022 (Private Cloud)Fin de vida útil: 2 de mayo de 2023 (Public Cloud), 31 de mayo de 2023 (Private Cloud)A partir del 2 de noviembre de 2022 en Public Cloud y del 21 de diciembre de 2022 en Private Cloud, las siguientes extensiones de log de Auth0 quedarán obsoletas:
Logs to Segment
Logs to Mixpanel
Logs to AppInsights
Logs to Azure Blob Storage
Todas las extensiones de log enumeradas anteriormente ya están obsoletas. Puede configurar una funcionalidad equivalente mediante flujos de eventos de log o integraciones en Auth0 Marketplace. A partir del 2 de noviembre de 2022 en Public Cloud y del 21 de diciembre de 2022 en Private Cloud, Auth0 dejará de ofrecer soporte para las extensiones de log instaladas de la lista anterior. Para obtener más información, consulte Migrate from Log Extensions.
Obsoleto: 9 de diciembre de 2021 y diciembre de 2021 (versión 2112.2 de Private Cloud)Fin de vida: 9 de junio de 2022 y 9 de septiembre de 2022 (Private Cloud)A partir del 9 de junio de 2022 en Public Cloud y del 9 de septiembre de 2022 en Private Cloud, Auth0 reforzará la seguridad de las llamadas a la API añadiendo un paso de validación de los nombres de host del Tenant al proceso de identificación de Authentication API. Cuando se realice una llamada, Authentication API validará el identificador de entidad (por ejemplo, client_id) del Tenant solicitante, así como el nombre del Tenant en el dominio de la URL. El Tenant propietario del identificador debe ser el mismo que el del dominio de la URL; de lo contrario, la solicitud se rechazará.Si su aplicación o API llama a cualquiera de los endpoints enumerados, debe configurar las llamadas a la API para asegurarse de que el identificador del Tenant solicitante y el nombre de host coincidan:
/oauth/token
/co/authenticate
/userinfo
/login
/oauth/revoke
/mfa/challenge
/p/<connection-type>/<ticket> (endpoint de aprovisionamiento de conexión empresarial)
Fin de vida útil: 30 de abril de 2022El 30 de abril de 2022, Node.js v12 dejó de contar con soporte a largo plazo (LTS), lo que significa que el equipo de desarrollo de Node.js ya no incorpora retroactivamente correcciones críticas de seguridad en esta versión. Esto podría exponer su código de extensibilidad a vulnerabilidades de seguridad. Por lo tanto, Auth0 está migrando de Node 12 a Node 16.Aunque la actualización a Node 16 no introducirá ningún cambio incompatible con versiones anteriores en la biblioteca estándar de Node.js (Rules y los scripts de Action de base de datos personalizados se ven afectados; consulte la sección Cambios incompatibles con versiones anteriores: solo Rules y scripts de Action de base de datos personalizados), recomendamos a los clientes que usan Node 12 mantenerse al día con las versiones de Node que cuentan con soporte activo a largo plazo (LTS) por motivos de seguridad y cumplimiento. Los clientes que aún usan Node 8 ya no cumplen los requisitos de seguridad y deben migrar a Node 16 para eliminar los riesgos de seguridad. Eliminamos el runtime de Node 8 el 22 de febrero de 2022 para los Tenants de Public Cloud y lo eliminamos en la versión de abril de 2022 de Private Cloud. Después de estas fechas, los Tenants que sigan configurados con Node 8 corren el riesgo de sufrir una interrupción del servicio.
Longitud fija del token de acceso opaco y del código de autorización
Obsoleto: 7 de octubre de 2021 (Public Cloud), diciembre de 2021 (Private Cloud)Fin de vida: 12 de abril de 2022 (Public Cloud), 30 de junio de 2022 (Private Cloud)A partir del 12 de abril de 2022 en Public Cloud y desde diciembre de 2021 en Private Cloud, el token de acceso y los códigos de autorización se emitirán con longitudes variables para cumplir con la especificación OAuth RFC6749 y evitar que los clientes hagan suposiciones sobre los valores del código de autorización y del token de acceso. Actualmente, el tamaño del token de acceso y del código de autorización es fijo. El tamaño actual del código de autorización es menor de lo que recomiendan algunos especialistas en seguridad. Con este cambio, Auth0 proporciona un código y un token más robustos, al tiempo que mejora el rendimiento de los sistemas de Auth0.Los clientes con sistemas configurados para depender de una longitud específica del código de autorización y del token de acceso deben pasar de configuraciones de tamaño fijo a configuraciones de tamaño variable antes del 12 de abril de 2022 en Public Cloud o antes del lanzamiento de Private Cloud del 30 de junio de 2022.
Fin de vida útil del runtime de extensibilidad de Node.js v8
Obsoleto: 15 de abril de 2020Fin de vida útil: 25 de febrero de 2022 (Public Cloud), abril de 2022 (versión de Private Cloud)A partir del 13 de diciembre de 2019, Node.js v8 dejó de tener soporte a largo plazo (LTS). Esto significa que las correcciones críticas de seguridad ya no se retroportaban a esta versión. Los clientes que aún usan Node 8 ya no cumplen los requisitos de seguridad y deben migrar a Node 12 para eliminar los riesgos de seguridad. Para obtener más información sobre cómo migrar la versión de Node de su Tenant de la 8 a la 12, consulte Migrar de Node.js 8 a Node.js 12.Como Node.js v12 también dejará de tener soporte LTS en 2022, recomendamos encarecidamente a todos los clientes que usan Rules y Hooks que migren a Actions con Node 16 lo antes posible, y antes de que el soporte para Node 12 finalice formalmente por parte de la comunidad de Node.js el 30 de abril de 2022. Para obtener más información sobre los pasos de migración necesarios, consulte Migrar Rules y Hooks a Actions.
Obsoleto: 5 de mayo de 2021 (Public Cloud)Fin de vida: 3 de noviembre de 2021 (Public Cloud)El borde de red legado de Auth0 dejará de funcionar en Public Cloud. Después del 3 de noviembre de 2021, los inquilinos de Public Cloud que no hayan completado la migración al nuevo borde de red de Auth0 dejarán de recibir tráfico. Todos los nuevos se crean automáticamente en el nuevo borde de red.
Deprecación de solicitudes no paginadas de Management API v2
Obsoleto: 21 de julio de 2020 (Public Cloud)Fin de vida: 26 de enero de 2021 (Public Cloud), febrero de 2022 (versión de Private Cloud)Después del 26 de enero de 2021, las solicitudes a los siguientes endpoints de Management API v2 devolverán un máximo de 50 elementos para los Tenants de Public Cloud. Para recuperar más elementos, debe incluir los parámetros page y per_page. A partir del 21 de julio de 2020, Auth0 mostrará los registros del Tenant y un interruptor de migración para ayudarle a prepararse para este cambio.
Se verán afectados todos los Tenants de Public Cloud creados antes del 21 de julio de 2020 que realicen llamadas activas a los endpoints afectados sin pasar el parámetro per_page en consultas que puedan devolver más de 1 resultado. Los Tenants no se verán afectados si se crean después del 21 de julio de 2020, no usan los endpoints afectados, usan los endpoints afectados y pasan el parámetro per_page, o realizan consultas que siempre devuelven solo 1 resultado. Para obtener más información, lea Migrate to Management API v2 Endpoint Paginated Queries.
Deprecación del dominio personalizado de Private Cloud
Obsoleto: 17 de junio de 2021Fin de vida: 20 de diciembre de 2021Para mantener la coherencia en todas las implementaciones de Auth0 y centrarnos en mejorar la funcionalidad de dominio personalizado de Auth0, dejaremos de ofrecer la funcionalidad de dominio personalizado de Private Cloud el 20 de diciembre de 2021. Esta coherencia nos permite mejorar la funcionalidad y resolver problemas de confiabilidad con mayor rapidez, lo que mejora la eficiencia operativa y permite a los clientes aprovechar antes el valor de los dominios personalizados.
Obsoleto: 25 de mayo de 2021Fin de vida útil: 01 de diciembre de 2021El 01 de diciembre de 2021, el comportamiento de logout cambiará para redirigir siempre a los usuarios al URI proporcionado a las API de logout de Auth0, en lugar de usar el parámetro de consulta returnTo que los pasan a /login/callback durante el proceso de logout. Si Auth0 no tiene registro de una llamada previa a una de estas API, el logout se completará, pero no se producirá la redirección y se mostrará una página de error a los usuarios finales. Para obtener más información, consulta la Guía de migración de redirecciones de Logout.
Deprecación del rol Application Admin del Dashboard
Obsoleto: 01 de febrero de 2021Fin de vida útil: 30 de septiembre de 2021 (Public Cloud), septiembre de 2021 (versión mensual de Private Cloud)Auth0 está cambiando el control de acceso basado en roles del Dashboard. El rol Application Administrator, tal como está definido hoy, se está deprecando. Después del 01 de febrero de 2021, los administradores no podrán invitar a miembros con el rol obsoleto Application Administrator. Los administradores existentes de aplicaciones específicas podrán seguir usando el Dashboard con el conjunto de permisos actual hasta la fecha de fin de vida útil.Hay disponible un nuevo conjunto de roles del Dashboard para mejorar la colaboración entre los miembros del equipo y hacerla más segura, incluidos roles de visor y editor con acceso limitado. Un nuevo rol Editor - Specific Apps reemplaza al rol anterior Application Administrator en los planes de suscripción en los que se admiten roles de editor.Sus Tenants se verán afectados por esta deprecación si se cumplen los siguientes criterios:
Se crearon antes del 01 de febrero de 2021
Tienen al menos un miembro del Tenant con el rol Application Admin
No han optado por la vista previa de la funcionalidad de roles del Dashboard
Obsoleto: 19 de enero de 2021Fin de vida: 10 de mayo de 2021 (Public Cloud), versión de junio de Private Cloud (v2106)A partir del 10 de mayo de 2021 para Public Cloud y de la versión de junio de Private Cloud (v2106), el perímetro de red de Auth0 dejará de aceptar tráfico TLS 1.0 y TLS 1.1. Estos protocolos heredados no son seguros y tienen debilidades y vulnerabilidades bien conocidas en la industria. Para obtener la máxima seguridad, todos los clientes de Auth0 deben actualizarse a TLS 1.2 o una versión posterior. Los detalles exactos y los pasos necesarios variarán según la aplicación.
Deprecación: enero de 2018Fin de vida útil: enero de 2021Auth0 ha declarado obsoleto el uso de la biblioteca auth0-analytics.js, que añade integración de Facebook y Google Analytics con Lock. Escucha eventos en Lock y los envía a la biblioteca Auth0-tag-manager.js. Es posible que todavía funcione en algunos casos heredados. Esta biblioteca ya no recibe mantenimiento. Es posible que tenga que escribir código personalizado para usar auth0-tag-manage.js y gestionar solicitudes proxy a bibliotecas de analítica de terceros como Facebook, X y Google.
Deprecación de los metadatos de credenciales de dispositivo sin user_id
Obsoleto: 31 de agosto de 2020Fin de vida: 17 de diciembre de 2020Auth0 ahora requiere que proporcione el user_id al usar el endpoint GET /api/v2/device-credentials. Si su solicitud no incluye un user_id, devolverá un código de estado 400. Consulte la depnote en los registros del Tenant para ver si esta deprecación le afecta. Para obtener más información, lea Consultar errores de obsolescencia.Auth0 ha identificado los Tenants afectados por esta deprecación y se ha puesto en contacto con los administradores de esos Tenants. Si su Tenant realiza actualmente solicitudes sin un user_id, debe hacer este cambio lo antes posible.
Deprecación de la verificación de correo electrónico de Azure AD/ADFS
Obsoleto:
Public Cloud: 18 de noviembre de 2020
Private Cloud: 01 de diciembre de 2020
Fin de vida:
Public Cloud: 18 de mayo de 2021
Private Cloud: versión de junio de Private Cloud (v2106)
Anteriormente, Auth0 establecía el campo email_verified en true en las conexiones de Azure AD y ADFS. Si usó conexiones de Azure AD/ADFS antes de esta fecha de deprecación, tiene una configuración a nivel del Tenant que sobrescribe la configuración de la conexión para la verificación de correo electrónico y mantiene el comportamiento anterior.El 18 de mayo de 2021 en Public Cloud y en la versión de junio de Private Cloud (v2106), Auth0 empezará a usar la propiedad a nivel de conexión para todas las conexiones de Azure AD/ADFS. Debe asegurarse de que todas sus conexiones estén configuradas correctamente antes de esa fecha. Para obtener más información, consulte Verificación de correo electrónico para Azure AD y ADFS.
Entrada en vigor: febrero de 2020Google Chrome v80 está cambiando la forma en que gestiona las cookies. Con ese fin, Auth0 implementará los siguientes cambios en la forma en que gestiona las cookies:
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 podrán guardar en el almacenamiento de cookies del navegador
Obsoleto: 10 de noviembre de 2018Fin de vida: 30 de junio de 2019 (Public Cloud), mayo de 2021 (versión mensual de Private Cloud)En Public Cloud, User Search v2 quedó obsoleto y debía haber tomado medidas antes del 30 de junio de 2019. Se enviaron notificaciones a los clientes que necesitaban completar esta migración.En Private Cloud, los endpoints de User Search v1 y v2 dejarán de estar disponibles después de la versión mensual de mayo de Private Cloud y han sido reemplazados por el nuevo endpoint User Search v3.
Deprecación del endpoint sin contraseña desde aplicaciones confidenciales
Auth0 ha deprecado el uso del endpoint /passwordless/start desde aplicaciones confidenciales cuando Auth0 no puede autenticar que la llamada se realiza en nombre de la aplicación. Para obtener más información, consulta Migrar al endpoint sin contraseña desde aplicaciones confidenciales.Cambios en la protección contra el clickjacking para Para evitar el clickjacking, en los casos en que renderizas tu página de inicio de sesión en un iframe, Auth0 ha añadido una opción de activación para agregar encabezados que te recomendamos encarecidamente habilitar. Para obtener más detalles, consulta Cambio en la protección contra el clickjacking para Universal Login.
Deprecación: 08 de julio de 2017Fin de vida útil: TBDA partir del 08 de julio de 2017, Auth0 ha declarado obsoleto el endpoint /oauth/ro tanto para conexiones con contraseña como para conexiones . Ahora puede implementar la misma funcionalidad con el endpoint /oauth/token. Para obtener más información, consulte Migración del flujo de contraseña del propietario del recurso.
Private Cloud: versión mensual de noviembre de 2020
Management API v1 llegará al fin de su vida útil en Public Cloud el 13 de julio de 2020. Management API v1 se incluirá en Private Cloud hasta la versión mensual de noviembre de 2020, la primera versión que ya no incluirá Management API v1. Es posible que deba tomar medidas antes de esa fecha para garantizar que no se interrumpa el servicio. Se han enviado y se seguirán enviando notificaciones a los clientes que deban completar esta migración.
Obsoleto: 05 de marzo de 2020Fin de vida útil: 31 de marzo de 2020Facebook anunció que el 31 de marzo de 2020 desactivará las API heredadas de Instagram y que no ofrecerá una alternativa para implementar Login con Instagram. Para más información, consulta Deprecación de la conexión de Instagram.
Obsoleto: 01 March 2020Fin de vida útil: 01 March 2020Yahoo cambió la forma de obtener el perfil de usuario y la información incluida en él. Para obtener más información, consulta Yahoo API Changes.
Deprecación: 11 de abril de 2019Fin de vida útil: 11 de abril de 2019A partir del 11 de abril de 2019, Google declaró obsoleto Google Cloud Messaging (GCM) y lo reemplazó por Firebase Cloud Messaging (FCM). Para más información, consulta Migración de Google a Firebase Cloud Messaging.
Deprecación: 30 de abril de 2019Fin de vida: 30 de julio de 2019El 30 de abril de 2019, Facebook declaró obsoleto el uso del campo Social Context en las aplicaciones nuevas. Para obtener más información, consulta Facebook Social Context Field Deprecation.
Deprecación: 01 de agosto de 2018Fin de vida útil: Graph API v3 se lanzó el 08 de enero de 2019A partir del 01 de agosto de 2018, Facebook cambió los permisos y los campos de Facebook Graph API que se pueden solicitar. Auth0 actualizó las conexiones de Facebook para reflejar estos cambios y modificó la interfaz de la conexión para mayor claridad. Consulta Facebook Login Changelog: Recent Changes to Facebook Login para conocer todos los detalles y las fechas clave. Para obtener más información, consulta Cambios en Facebook Graph API.
Mejoramos continuamente la seguridad de nuestro servicio. Como parte de este esfuerzo, hemos declarado obsoleta la API heredada de Lock, que consta de los endpoints /usernamepassword/login y /ssodata. Estos endpoints son utilizados por Lock.js v8, v9 y v10, y por Auth0.js v6, v7 y v8, y también pueden invocarse directamente desde las aplicaciones.Desde el 6 de agosto de 2018, Auth0 ha deshabilitado permanentemente la API heredada de Lock. Esta retirada del servicio mitiga por completo la vulnerabilidad CSRF divulgada en abril de 2018. Esto también pone fin al período de gracia de retirada gradual que se anunció por primera vez el 16 de julio de 2018, lo que significa que la API heredada de Lock ya no puede volver a habilitarse.Si la migración de la API heredada de Lock aún no se ha completado, sus usuarios podrían experimentar una interrupción del servicio, errores de inicio de sesión u otros efectos adversos. Deberá completar la migración para restaurar el funcionamiento normal. Revise los errores de obsolescencia para identificar el origen de cualquier error en los registros del inquilino relacionado con deprecaciones.
Si actualmente implementa el inicio de sesión en su aplicación con Lock v8, v9 o v10, o Auth0.js v6, v7 o v8, estos cambios le afectan. Además, también le afectan si su aplicación llama directamente a los endpoints /usernamepassword/login o /ssodata a través de la API.Recomendamos que las aplicaciones que usan Universal Login actualicen las versiones de las bibliotecas que utilizan dentro de la página de inicio de sesión.Sin embargo, las aplicaciones que usan Lock o Auth0.js integrados en la propia aplicación, o que llaman directamente a los endpoints de API afectados, deben actualizarse. Las aplicaciones que sigan usando endpoints obsoletos dejarán de funcionar correctamente después de la fecha de retirada del servicio.Las bibliotecas y los SDK que no se mencionan explícitamente aquí no se ven afectados por esta migración.
Essential (anteriormente Developer): 20 de agosto de 2019
Professional (anteriormente Developer Pro): 20 de agosto de 2019
Enterprise: 04 de noviembre de 2019
Para ofrecer a nuestros clientes la solución más fiable y escalable, Auth0 ha declarado obsoleto Tenant Logs Search Engine v2 en favor de v3. Auth0 está migrando de forma proactiva a los clientes que no se ven afectados por este cambio, mientras que se está notificando a aquellos que podrían verse afectados para que opten por v3 durante el período de gracia indicado. Para obtener más información, consulta Migrar Tenant Log Search de v1 a v2.
Nuevas direcciones IP para listas de permitidos en Australia
A partir del 30 de septiembre de 2017, Auth0 actualizó sus entornos en la nube y el tráfico procedente de Australia se origina en nuevas direcciones IP. Si utiliza listas de direcciones IP permitidas, deberá agregar las nuevas direcciones a las reglas de su firewall.
Si utiliza una conexión de base de datos personalizada, una Rule y/o un proveedor de correo electrónico personalizado conectados a su entorno, y ha implementado restricciones de firewall para rangos de direcciones IP, este cambio le afecta. Deberá asegurarse de que las siguientes direcciones IP estén permitidas a través de su firewall:13.55.232.24, 13.54.254.182, 13.210.52.131, 52.62.91.160, 52.63.36.78, 52.64.84.177, 52.64.111.197, 52.64.120.184, 54.66.205.24, 54.79.46.4, 54.153.131.0
Nuevas direcciones IP para la lista de permitidos en Europa
A partir del 30 de septiembre de 2017, Auth0 actualizó sus entornos en la nube y el tráfico procedente de Europa se origina en nuevas direcciones IP. Si está permitiendo direcciones IP, deberá añadir las nuevas direcciones a las reglas de su firewall.
Si utiliza una conexión de base de datos personalizada, una Rule y/o un proveedor de correo electrónico personalizado que se conecten a su entorno, y ha implementado restricciones de firewall para rangos de direcciones IP, este cambio le afecta. Deberá asegurarse de que las siguientes direcciones IP estén permitidas en su firewall:34.253.4.94, 35.156.51.163, 35.157.221.52, 52.16.193.66, 52.16.224.164, 52.28.45.240, 52.28.56.226, 52.28.184.187, 52.28.212.16, 52.29.176.99, 52.50.106.250, 52.57.230.214, 52.211.56.181, 52.213.216.142, 52.213.38.246, 52.213.74.69
Migración del proveedor de CDN en los entornos de Europa y Australia
A partir del 12 de julio de 2017, Auth0 ha mejorado la escalabilidad y la disponibilidad de su CDN. Ahora utilizamos Amazon CloudFront. Ya hemos realizado este cambio en el entorno de EE. UU. y ahora también estamos preparados para hacerlo en Europa y Australia.
Esto le afecta si usa Lock (alojado en nuestra CDN) en Europa o Australia. Este cambio no debería causar ninguna interrupción ni modificar el comportamiento de sus aplicaciones, por lo que no tiene que hacer nada. Esta notificación es solo informativa.
Migración de Rules para el intercambio de contraseña y del token de actualización
El 31 de mayo de 2017, como parte de los esfuerzos de Auth0 por mejorar la seguridad, añadimos la capacidad de ejecutar Rules durante el intercambio de Password Grant (intercambio de contraseña) y el intercambio del token de actualización.
Usas esta funcionalidad si llamas al endpoint /oauth/token de nuestra Authentication API con grant_type = "password", grant_type = "http://auth0.com/oauth/grant-type/password-realm" o grant_type = "refresh_token".Podrías verte afectado si actualmente usas estos intercambios y tienes Rules definidas en el Dashboard. Para garantizar una transición fluida, hemos deshabilitado la ejecución de Rules en estos intercambios específicos para tu inquilino. Estas Rules pasarán a ejecutarse para todos los clientes nuevos, así como para los clientes que aún no hayan usado estos intercambios.Puedes agregar lógica a tus Rules para modificar su comportamiento en estos intercambios comprobando la propiedad context.protocol:
oauth2-password indica el intercambio de contraseña (y password-realm)
oauth2-refresh-token indica el intercambio del Token de actualización
Si quieres habilitar el nuevo comportamiento en este tenant para hacer pruebas antes de la fecha límite de activación obligatoria, inicia sesión en Dashboard y habilita el interruptor Run Rules on Password and Refresh Token Exchanges en Configuración del Tenant > Advanced.
El 1 de marzo de 2017, como parte de los esfuerzos de Auth0 para mejorar la seguridad y el cumplimiento de los estándares, dejamos de admitir la vinculación de cuentas como parte del callback de autorización (es decir, aceptar un token de acceso como parte de la llamada a authorize).
Si recibió una notificación por correo electrónico al respecto, este cambio le afecta. Mientras actualiza sus aplicaciones para usar la Management API para vincular cuentas, puede comprobar si sigue viéndose afectado consultando los registros del inquilino en busca de advertencias. Estas entradas se registrarán si envía un Token de acceso en sus llamadas a authorize.
A partir del 20 de febrero de 2017, Auth0 se expandió a nuevas regiones de EE. UU., y el tráfico originado en estas regiones tendrá nuevas direcciones IP. Si utiliza una lista de permitidos para las direcciones IP, deberá agregar las nuevas direcciones a las reglas de su firewall.
Si utiliza una conexión de base de datos personalizada, una Rule y/o un proveedor de correo electrónico personalizado que se conectan a su entorno, y ha implementado restricciones en el firewall para rangos de direcciones IP, este cambio le afecta. Deberá agregar las siguientes direcciones IP a las reglas de su firewall:138.91.154.99, 54.183.64.135, 54.67.77.38, 54.67.15.170,54.183.204.205, 54.173.21.107, 54.85.173.28, 35.167.74.121, 35.160.3.103,35.166.202.113, 52.14.40.253,52.14.38.78, 52.14.17.114, 52.71.209.77, 34.195.142.251, 52.200.94.42
Flujo vulnerable de restablecimiento de contraseña
Antes del 01 de febrero de 2017, el flujo de restablecimiento de contraseña de Auth0 permitía que un usuario introdujera su correo electrónico y una nueva contraseña. Esto desencadenaba el envío de un correo electrónico de confirmación al usuario para que confirmara que había solicitado un restablecimiento de contraseña.
El problema es que un usuario podría hacer clic inadvertidamente en el enlace de confirmación, lo que permitiría que un atacante cambiara la contraseña del usuario.Lock versión 9 y posteriores usa exclusivamente el nuevo flujo de restablecimiento de contraseña. Lock 8 y versiones anteriores no admite el nuevo flujo de restablecimiento de contraseña. Recomendamos encarecidamente actualizar a Lock 9 o a una versión posterior lo antes posible.
Aunque no use Lock, se puede acceder directamente al flujo de restablecimiento vulnerable a través de la API. (Consulte el endpoint /dbconnections/change_password para obtener más información). Auth0 le recomienda encarecidamente que cualquier aplicación que use el flujo actual pase de inmediato al nuevo flujo de restablecimiento y habilite esta migración.
Parámetro state obligatorio al redirigir desde una Rule
A partir del 6 de diciembre de 2016, cuando se realiza una redirección desde una Rule de Auth0, Auth0 genera y envía un parámetro state en la solicitud HTTP, y verifica que ese parámetro state sea válido cuando el flujo regresa al endpoint /continue. El sitio al que se redirige debe capturar el valor del parámetro state y devolverlo al regresar al endpoint /continue, agregándolo como parámetro.
Cambio en el endpoint para eliminar todos los usuarios
Antes del 13 de septiembre de 2016, el endpoint para eliminar todos los usuarios era DELETE /api/v2/users. Este es similar al endpoint para eliminar un solo usuario: DELETE /api/v2/users. Para evitar solicitudes accidentales al endpoint para eliminar todos los usuarios, la URL se cambió a DELETE /api/v2/allusers. Esto debería garantizar que solo se realicen llamadas intencionales a este endpoint.
Este cambio solo le afecta si actualmente utiliza el endpoint para eliminar todos los usuarios. En ese caso, el único cambio que debe hacer es cambiar la URL, como se explicó anteriormente.
Cambios en la personalización de las plantillas de entrega de correo electrónico
A partir del 29 de agosto de 2016, el proveedor de correo electrónico integrado de Auth0 dejó de ser compatible para su uso en entornos de producción. Los correos electrónicos enviados mediante el proveedor de Auth0 ya no se podrán personalizar. Se limitarán a la plantilla y no podrá cambiar la dirección del remitente ni el asunto.El servicio de correo electrónico integrado todavía puede usarse con fines de prueba, pero debe cambiar a un servicio de terceros compatible con Auth0 (Amazon SES, Mailchimp, SendGrid u otro proveedor basado en SMTP) antes de pasar sus aplicaciones a producción. Si ya utiliza un proveedor de correo electrónico personalizado, no es necesario hacer nada.
Se eliminaron los tokens de acceso del Proveedor de identidad del perfil de usuario y del token de ID
A partir del 8 de agosto de 2016, se modificó el formato del objeto JSON del perfil de usuario (token de ID) que devuelve la API de autenticación de Auth0 para eliminar el token de acceso del Proveedor de identidad e incluirlo en el array identities del perfil de usuario.Para obtener el token de acceso del Proveedor de identidad de un usuario, deberá realizar una solicitud HTTP GET al endpoint /api/v2/users/{user-id} con un token de API generado con el scope read:user_idp_tokens. Seguirá teniendo acceso al token de acceso del Proveedor de identidad en el argumento user de las Rules de Auth0.
Este cambio solo le afecta si usa el Token de acceso del Proveedor de identidad (identities[0].access_token en el perfil de usuario) fuera de Rules para llamar a otros servicios del Proveedor de identidad (como Facebook Graph API, Google APIs, etc.). Si su inquilino se creó después del cambio, la actualización se realizará automáticamente.
A partir del 1 de junio de 2016, al llamar al endpoint Tokeninfo, la URL de la llamada a la API (por ejemplo, https://{yourDomain}/) debe coincidir con el valor del atributo iss del ID Token que se valida. Si estos valores no coinciden, la respuesta será HTTP 400 - Bad Request.
Si llamas directamente al endpoint Tokeninfo, asegúrate de que el valor del atributo iss del ID Token que se está validando coincida con el espacio de nombres de tu inquilino de Auth0: https://{yourDomain}/. Puedes usar jwt.io para decodificar el token y confirmar el valor del atributo iss.
Cambios en la dirección del remitente de los correos electrónicos
El 27 de abril de 2016, el proveedor de correo electrónico integrado de Auth0 comenzó a enviar todos los correos electrónicos desde una dirección de remitente predefinida (no-reply@auth0user.net). Los proveedores de correo electrónico personalizados ahora son gratuitos. Para personalizar la dirección del remitente, puede cambiar a un servicio de terceros compatible con Auth0 (Amazon SES, Mailchimp, SendGrid) u otro proveedor basado en SMTP. Si ya usa un proveedor de correo electrónico personalizado, no habrá cambios.
Los endpoints PATCH y POST ya no aceptan el indicador secret_encoded
La configuración jwt_configuration.secret_encoded ya no se admite en los endpoints PATCH y POST de aplicaciones.Para cumplir aún más con la especificación OIDC, Auth0 dejará de generar o aceptar secretos de aplicación codificados en base64 para las aplicaciones nuevas.Las aplicaciones existentes con secretos codificados almacenados permanecerán intactas y sin cambios, pero las aplicaciones nuevas ya no usarán codificación base64. Como resultado, el indicador secret_encoded ya no se acepta ni es necesario.
Autenticar
Administrar usuarios
Personalizar
Auth0 AI
Plataforma