> ## 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.

> Lista de actualizaciones de Auth0 que ya se han habilitado para todos los clientes.

# Migraciones anteriores

Estas son las migraciones que ya se han habilitado para todos los clientes. Si tiene alguna pregunta, cree un ticket en nuestro [Support Center](https://support.auth0.com/center/s/).

<div id="protected-properties-in-non-custom-social-connections">
  ## Propiedades protegidas en conexiones sociales no personalizadas
</div>

**Obsoleto**: 30 de julio de 2024

**Fin de vida**: 31 de enero de 2025

Los 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.

<div id="unwarranted-session-removal-after-management-api-user-updates">
  ## Eliminación indebida de sesiones tras actualizaciones de usuarios mediante la Management API
</div>

**Obsoleto**: 11 de febrero de 2025

**Fin de vida**: 19 de agosto de 2025

El endpoint <Tooltip tip="Management API: Un producto que permite a los clientes realizar tareas administrativas." cta="Ver glosario" href="/es/docs/glossary?term=Management+API">Management API</Tooltip> [actualizar un usuario](https://auth0.com/docs/api/management/v2/users/patch-users-by-id) (`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`.

<div id="mandatory-use-of-sni-for-https-requests">
  ## Uso obligatorio de SNI para las solicitudes HTTPS
</div>

**Obsoleto**: 29 de octubre de 2024

**Fin de vida útil**: 29 de abril de 2025

El servicio de Auth0 exigirá el uso de [Server Name Indication](https://en.wikipedia.org/wiki/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](https://support.auth0.com/center/s/article/End-of-Life-Rollout-for-Mandatory-Use-of-SNI-for-HTTPS-Requests).

<div id="always-use-https-for-communication-with-auth0">
  ## Utilice siempre HTTPS para comunicarse con Auth0
</div>

**Obsoleto**: 4 de septiembre de 2024

**Fin de vida útil**: 4 de octubre de 2024

A 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.

<div id="management-api-transition-updating-roles-assignment-to-require-create-scope">
  ## Transición de la Management API: actualización de la asignación de roles para requerir el scope de creación
</div>

**Obsoleto**: 7 de marzo de 2024

**Fin de vida**: 10 de septiembre de 2024

Los 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`.

<div id="update-applications-that-use-cross-origin-authentication">
  ## Actualiza las aplicaciones que usan autenticación entre orígenes
</div>

**Obsoleto**: 25 de abril de 2024

**Fin de vida**: 10 de octubre de 2024

Las 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](https://auth0.com/docs/api/management/v2/clients/get-clients), [Get Client by ID](https://auth0.com/docs/api/management/v2/clients/get-clients-by-id)) para usar `cross_origin_authentication`.

<div id="remove-subscription-tickets-access-for-tenant-admins">
  ## Eliminar el acceso a Subscription Tickets para los administradores del Tenant
</div>

**Obsoleto**: 5 de junio de 2024

**Fin de vida**: 5 de agosto de 2024

El acceso para ver [Subscription Tickets](/es/docs/troubleshoot/customer-support/open-and-manage-support-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.

<div id="password-reset-and-email-verification-links-in-tenant-logs-deprecation">
  ## Deprecación de los enlaces de Restablecimiento de contraseña y Verificación de correo electrónico en los registros del Tenant
</div>

**Obsoleto**: 7 de diciembre de 2023

**Fin de vida útil**: 5 de febrero de 2024

Los 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 <Tooltip tip="Management API: Un producto que permite a los clientes realizar tareas administrativas." cta="Ver glosario" href="/es/docs/glossary?term=Management+API">Management API</Tooltip>.

<div id="reducing-maximum-expiration-time-for-login-transactions">
  ## Reducción del tiempo máximo de expiración de las transacciones de inicio de sesión
</div>

**Obsoleto**: 5 de septiembre de 2023 (Public Cloud), 21 de noviembre de 2023 (Private Cloud)

**Fin de vida**: 21 de febrero de 2024

Con 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.

<div id="unregistered-scopes-in-refresh-tokens-deprecation">
  ## Deprecación de alcances no registrados en tokens de actualización
</div>

**Obsoleto**: 12 de julio de 2023

**Fin de vida**: 17 de enero de 2024

Estamos mejorando la evaluación de alcances durante el intercambio de <Tooltip tip="Token de actualización: token que se usa para obtener un nuevo Token de acceso sin obligar a los usuarios a volver a iniciar sesión." cta="Ver glosario" href="/es/docs/glossary?term=refresh+token">token de actualización</Tooltip> 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](/es/docs/customize/rules). Esta evaluación validará que todos los alcances estén registrados y devolverá un error si alguno no lo está.

<div id="auth0-cordova-angular-auth0-and-express-oauth2-bearer-repo-deprecations">
  ## Deprecación de los repositorios auth0-cordova, angular-auth0 y express-oauth2-bearer
</div>

**Obsoleto**: 27 de abril de 2023

**Fin 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:

* [express-oauth2-bearer](https://github.com/auth0/express-oauth2-bearer) | [guía de migración](https://github.com/auth0/express-oauth2-bearer/blob/master/MIGRATION_GUIDE.md)
* [angular-auth0](https://github.com/auth0/angular-auth0) | [guía de migración](https://github.com/auth0/angular-auth0/blob/master/MIGRATION_GUIDE.md)
* [auth0-cordova](https://github.com/auth0/auth0-cordova) | [guía de migración](https://github.com/auth0/auth0-cordova/blob/master/MIGRATION_GUIDE.md)

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.

<div id="actions-migration-from-nodejs-16-to-nodejs-18">
  ## Migración de Actions de Node.js 16 a Node.js 18
</div>

**Fecha objetivo de migración**: 11 de sept. de 2023

Como 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.

<div id="support-for-edgejs-in-extensibility-features">
  ## Compatibilidad con edge.js en las funcionalidades de extensibilidad
</div>

**Obsoleto:** 21 de diciembre de 2022

**Fin de vida:** 21 de junio de 2023

Despué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](/es/docs/troubleshoot/product-lifecycle/past-migrations/migrate-from-edge-js-extensibility-features).

<div id="support-for-oracledb-in-extensibility-features">
  ## Compatibilidad con oracledb en las características de extensibilidad
</div>

**Obsoleto:** 21 de diciembre de 2022

**Fin de vida útil:** 21 de junio de 2023

Auth0 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](https://www.npmjs.com/package/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](/es/docs/troubleshoot/product-lifecycle/past-migrations/migrate-from-oracledb-extensibility-features).

<div id="auth0-claims-provider-for-sharepoint-2010-2013">
  ## Proveedor de claims de Auth0 para SharePoint 2010 / 2013
</div>

**Obsoleto:** 31 de enero de 2023

**Fin de vida útil:** 31 de julio de 2023

Auth0 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.

<div id="checkpoint-pagination-on-get-role-users-endpoint">
  ## Paginación con checkpoint en el endpoint Get Role Users
</div>

**Obsoleto:** 9 de noviembre de 2022

**Fin de vida útil:** 9 de mayo de 2023

Para 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](https://auth0.com/docs/api/management/v2/roles/get-role-user).

<div id="legacy-custom-claims">
  ## Claims personalizados heredados
</div>

**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 <Tooltip tip="JSON Web Token (JWT): formato estándar de ID Token (y, con frecuencia, también de Token de acceso) utilizado para representar claims de forma segura entre dos partes." cta="Ver glosario" href="/es/docs/glossary?term=JWT">JWT</Tooltip> 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 <Tooltip tip="ID Token: credencial destinada al propio cliente, en lugar de usarse para acceder a un recurso." cta="Ver glosario" href="/es/docs/glossary?term=ID+tokens">ID Token</Tooltip> mediante código de extensibilidad ([Rules](/es/docs/customize/rules) / [Hooks](/es/docs/customize/hooks) / [Actions](/es/docs/customize/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 <Tooltip tip="Access Token: credencial de autorización, en forma de una cadena opaca o JWT, utilizada para acceder a una API." cta="Ver glosario" href="/es/docs/glossary?term=access+tokens">tokens de acceso</Tooltip>; 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](/es/docs/troubleshoot/product-lifecycle/past-migrations/custom-claims-migration).

Si su Tenant ejecuta código de extensibilidad ([Rules](/es/docs/customize/rules) / [Hooks](/es/docs/customize/hooks) / [Actions](/es/docs/customize/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 <Tooltip tip="OpenID: estándar abierto de autenticación que permite a las aplicaciones verificar la identidad de los usuarios sin recopilar ni almacenar información de inicio de sesión." cta="Ver glosario" href="/es/docs/glossary?term=OPENID">OPENID</Tooltip> 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 <Tooltip tip="Audience: identificador único de la audiencia de un token emitido. Denominado aud en un token, su valor contiene el ID de una aplicación (ID de cliente) para un ID Token o de una API (identificador de API) para un Token de acceso." cta="Ver glosario" href="/es/docs/glossary?term=audience">audiencia</Tooltip> 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 \$.

Para obtener más información sobre los claims personalizados, consulte [Crear claims personalizados](/es/docs/secure/tokens/json-web-tokens/create-custom-claims).

<div id="legacy-private-cloud-platform">
  ## Plataforma heredada de Private Cloud
</div>

**Obsoleto:** 13 de junio de 2022

**Fin de vida útil:** 31 de enero de 2023

Estamos 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.

<div id="log-extensions">
  ## Extensiones de log
</div>

**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](https://marketplace.auth0.com/). 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](/es/docs/troubleshoot/product-lifecycle/past-migrations/migrate-from-log-extensions).

<div id="tenant-hostname-validation">
  ## Validación del nombre de host del Tenant
</div>

**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)

Para obtener más información, consulte [Migración de validación del nombre de host del Tenant](/es/docs/troubleshoot/product-lifecycle/past-migrations/tenant-hostname-migration).

<div id="nodejs-16-migration">
  ## Migración a Node.js 16
</div>

**Fin de vida útil**: 30 de abril de 2022

El 30 de abril de 2022, [Node.js v12 dejó de contar con soporte a largo plazo (LTS)](https://github.com/nodejs/Release#release-schedule), 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](#breaking-changes-rules-only)), 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.

<div id="opaque-access-token-and-authorization-code-fixed-length">
  ## Longitud fija del token de acceso opaco y del código de autorización
</div>

**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](https://datatracker.ietf.org/doc/html/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.

<div id="nodejs-v8-extensibility-runtime-end-of-life">
  ## Fin de vida útil del runtime de extensibilidad de Node.js v8
</div>

**Obsoleto**: 15 de abril de 2020

**Fin 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)](https://github.com/nodejs/Release#release-schedule). 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](/es/docs/troubleshoot/product-lifecycle/past-migrations/migrate-to-nodejs-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](/es/docs/customize/actions/migrate/migrate-from-rules-to-actions).

<div id="legacy-network-edge-deprecation">
  ## Deprecación del borde de red legado
</div>

**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 <Tooltip tip="Dominio personalizado: dominio de terceros con un nombre especializado o distintivo." cta="Ver glosario" href="/es/docs/glossary?term=custom+domains">dominios personalizados</Tooltip> se crean automáticamente en el nuevo borde de red.

<div id="unpaginated-management-api-v2-request-deprecation">
  ## Deprecación de solicitudes no paginadas de Management API v2
</div>

**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.

* [`GET /api/v2/clients`](https://auth0.com/docs/api/management/v2#!/Clients/get_clients)
* [`GET /api/v2/client-grants`](https://auth0.com/docs/api/management/v2#!/Clients/client_grants)
* [`GET /api/v2/grants`](https://auth0.com/docs/api/management/v2#!/Clients/grants)
* [`GET /api/v2/connections`](https://auth0.com/docs/api/management/v2#!/Clients/connections)
* [`GET /api/v2/device-crecentials`](https://auth0.com/docs/api/management/v2#!/Clients/device_credentials)(cuando se usa el parámetro de consulta `type`)
* [`GET /api/v2/resource-servers`](https://auth0.com/docs/api/management/v2#!/Clients/resource_servers)
* [`GET /api/v2/rules`](https://auth0.com/docs/api/management/v2#!/Clients/rules)

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](/es/docs/troubleshoot/product-lifecycle/past-migrations/migrate-to-paginated-queries).

<div id="private-cloud-custom-domain-deprecation">
  ## Deprecación del dominio personalizado de Private Cloud
</div>

**Obsoleto**: 17 de junio de 2021

**Fin de vida**: 20 de diciembre de 2021

Para 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.

<div id="logout-redirect-validation">
  ## Validación de la redirección de Logout
</div>

**Obsoleto**: 25 de mayo de 2021

**Fin de vida útil**: 01 de diciembre de 2021

El 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 <Tooltip tip="Proveedor de identidad (IdP): Servicio que almacena y gestiona identidades digitales." cta="Ver glosario" href="/es/docs/glossary?term=Identity+Providers">Proveedores de identidad</Tooltip> 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](/es/docs/troubleshoot/product-lifecycle/deprecations-and-migrations/logout-return-to).

<div id="application-admin-dashboard-role-deprecation">
  ## Deprecación del rol Application Admin del Dashboard
</div>

**Obsoleto**: 01 de febrero de 2021

**Fin 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

A partir del 01 de febrero de 2021, Auth0 mostrará un selector de migración para ayudarle a prepararse para este cambio. Para obtener más información, lea [Migrar para administrar los nuevos roles del Dashboard](/es/docs/troubleshoot/product-lifecycle/past-migrations/migrate-tenant-member-roles).

<div id="legacy-tls-deprecation">
  ## Deprecación del TLS legado
</div>

**Obsoleto**: 19 de enero de 2021

**Fin 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.

<div id="auth0-analyticsjs-deprecation">
  ## Deprecación de Auth0-analytics.js
</div>

**Deprecación**: enero de 2018

**Fin de vida útil**: enero de 2021

Auth0 ha declarado obsoleto el uso de la [biblioteca auth0-analytics.js](https://github.com/auth0/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](https://github.com/auth0/auth0-tag-manager) y gestionar solicitudes proxy a bibliotecas de analítica de terceros como Facebook, X y Google.

<div id="device-credential-metadata-without-user_id-deprecation">
  ## Deprecación de los metadatos de credenciales de dispositivo sin `user_id`
</div>

**Obsoleto**: 31 de agosto de 2020

**Fin de vida útil**: 17 de diciembre de 2020

Auth0 ahora requiere que proporcione el `user_id` al usar el [endpoint GET /api/v2/device-credentials](https://auth0.com/docs/api/management/v2/#!/Device_Credentials/get_device_credentials). Si su solicitud no incluye un `user_id`, devolverá un código de estado 400. Consulte la `depnote` en los registros del inquilino para ver si esta deprecación le afecta.

Auth0 ha identificado los inquilinos afectados por esta deprecación y se ha puesto en contacto con los administradores de esos inquilinos. Si su inquilino realiza actualmente solicitudes sin un `user_id`, debe hacer este cambio lo antes posible.

<div id="azure-adadfs-email-verification-deprecation">
  ## Deprecación de la verificación de correo electrónico de Azure AD/ADFS
</div>

**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](/es/docs/authenticate/identity-providers/enterprise-identity-providers/azuread-adfs-email-verification).

<div id="samesite-cookie-attribute-changes">
  ## cambios en el atributo sameSite de las cookies
</div>

**Entrada en vigor**: febrero de 2020

Google 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

El objetivo de estos cambios es mejorar la seguridad y ayudar a mitigar los ataques CSRF. Para obtener más información, consulte [Cambios en el atributo sameSite de las cookies](/es/docs/manage-users/cookies/samesite-cookie-attribute-changes).

<div id="user-search-v2-deprecation">
  ## Deprecación de User Search v2
</div>

**Obsoleto**: 10 de noviembre de 2018

**Fin 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.

<div id="passwordless-endpoint-from-confidential-applications-deprecation">
  ## Deprecación del endpoint sin contraseña desde aplicaciones confidenciales
</div>

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](/es/docs/troubleshoot/product-lifecycle/past-migrations/migrate-to-passwordless).Cambios en la protección contra el clickjacking para <Tooltip tip="Universal Login: Tu aplicación redirige a Universal Login, alojado en el Servidor de autorización de Auth0, para verificar la identidad de un usuario." cta="Ver glosario" href="/es/docs/glossary?term=Universal+Login">Universal Login</Tooltip>

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](/es/docs/troubleshoot/product-lifecycle/past-migrations/clickjacking-protection-for-universal-login).

<div id="management-api-endpoints-using-id-token-credentials-deprecation">
  ## Deprecación de los endpoints de Management API que usan credenciales de ID Token
</div>

**Deprecación**: 31 de marzo de 2018

**Fin de vida**: Por determinar

Auth0 está dejando obsoleto el uso de ID Token como credenciales para llamar a algunos de los endpoints de usuarios y dispositivos, y lo está reemplazando por el uso de tokens de acceso. Para obtener más detalles, consulta [Migrar a los endpoints de Management API con tokens de acceso](/es/docs/troubleshoot/product-lifecycle/past-migrations/migrate-to-calling-api-with-access-tokens) y [Migrar la vinculación de cuentas de usuario con tokens de acceso](/es/docs/troubleshoot/product-lifecycle/past-migrations/link-user-accounts-with-access-tokens-migration).

<div id="resource-owner-password-oauthro-deprecation">
  ## Deprecación de Resource Owner Password /oauth/ro
</div>

**Deprecación**: 08 de julio de 2017

**Fin de vida útil**: TBD

A partir del 08 de julio de 2017, Auth0 ha declarado obsoleto el endpoint `/oauth/ro` tanto para conexiones con contraseña como para conexiones <Tooltip tip="Sin contraseña: forma de autenticación que no depende de una contraseña como primer factor." cta="Ver glosario" href="/es/docs/glossary?term=passwordless">sin contraseña</Tooltip>. 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](/es/docs/troubleshoot/product-lifecycle/past-migrations/migration-oauthro-oauthtoken).

<div id="management-api-v1-deprecation">
  ## Deprecación de Management API v1
</div>

**Deprecación**: octubre de 2016

**Fin de vida útil**:

* Public Cloud: 13 de julio de 2020
* 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.

<div id="instagram-connection-deprecation">
  ## Deprecación de la conexión de Instagram
</div>

**Obsoleto**: 05 de marzo de 2020

**Fin de vida útil**: 31 de marzo de 2020

Facebook 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](/es/docs/troubleshoot/product-lifecycle/past-migrations/instagram-connection-deprecation).

<div id="yahoo-api-changes">
  ## Cambios en la API de Yahoo
</div>

**Obsoleto**: 01 March 2020

**Fin de vida útil**: 01 March 2020

Yahoo 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](/es/docs/troubleshoot/product-lifecycle/past-migrations/yahoo-api-changes).

<div id="google-cloud-messaging-deprecation">
  ## Deprecación de Google Cloud Messaging
</div>

**Deprecación**: 11 de abril de 2019

**Fin de vida útil**: 11 de abril de 2019

A partir del 11 de abril de 2019, [Google declaró obsoleto](https://firebase.googleblog.com/2018/04/time-to-upgrade-from-gcm-to-fcm.html) 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](/es/docs/troubleshoot/product-lifecycle/past-migrations/google-firebase-migration).

<div id="facebook-social-context-field-deprecation">
  ## Deprecación del campo Social Context de Facebook
</div>

**Deprecación**: 30 de abril de 2019

**Fin de vida**: 30 de julio de 2019

El 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](/es/docs/troubleshoot/product-lifecycle/past-migrations/facebook-social-context-field-deprecation).

<div id="facebook-graph-api-changes">
  ## Cambios en Facebook Graph API
</div>

**Deprecación**: 01 de agosto de 2018

**Fin de vida útil**: Graph API v3 se lanzó el 08 de enero de 2019

A 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](https://developers.facebook.com/docs/facebook-login/changelog#2018-07-02) para conocer todos los detalles y las fechas clave. Para obtener más información, consulta [Cambios en Facebook Graph API](/es/docs/troubleshoot/product-lifecycle/past-migrations/facebook-graph-api-changes).

<div id="lock-v11-and-auth0js-v9">
  ## Lock v11 y Auth0.js v9
</div>

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](https://auth0.com/blog/managing-and-mitigating-security-vulnerabilities-at-auth0/). 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.

### Funciones afectadas

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.

<div id="tenant-log-search-v2-deprecation">
  ## Deprecación de Tenant Log Search v2
</div>

**Deprecación**: 21 de mayo de 2019

**Fin de vida útil**:

* Gratis: 09 de julio de 2019
* 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](/es/docs/troubleshoot/product-lifecycle/past-migrations/migrate-to-tenant-log-search-v3).

<div id="new-ip-addresses-for-allowlisting-in-australia">
  ## Nuevas direcciones IP para listas de permitidos en Australia
</div>

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.

<div id="features-affected">
  ### Características afectadas
</div>

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`

<div id="new-ip-addresses-for-allowlisting-in-europe">
  ## Nuevas direcciones IP para la lista de permitidos en Europa
</div>

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.

<div id="features-affected">
  ### Características afectadas
</div>

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`

<div id="cdn-provider-migration-in-the-europe-and-australia-environments">
  ## Migración del proveedor de CDN en los entornos de Europa y Australia
</div>

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.

### Funcionalidades afectadas

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.

<div id="password-and-refresh-token-exchange-rules-migration">
  ## Migración de Rules para el intercambio de contraseña y del token de actualización
</div>

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 <Tooltip tip="OAuth 2.0: Marco de autorización que define protocolos y flujos de autorización." cta="Ver glosario" href="/es/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> <Tooltip tip="OAuth 2.0: Marco de autorización que define protocolos y flujos de autorización." cta="Ver glosario" href="/es/docs/glossary?term=Resource+Owner">Resource Owner</Tooltip> Password Grant (intercambio de contraseña) y el intercambio del token de actualización.

### Funcionalidades afectadas

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](https://manage.auth0.com/#) y habilita el interruptor **Run Rules on Password and Refresh Token Exchanges** en [Configuración del Tenant > Advanced](https://manage.auth0.com/#/tenant/advanced).

<div id="account-linking-removal">
  ## Eliminación de la vinculación de cuentas
</div>

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`).

### Funciones afectadas

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.

<div id="allowlist-ip-address-ranges">
  ## Rangos de direcciones IP permitidas
</div>

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.

### Funciones afectadas

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`

<div id="vulnerable-password-flow">
  ## Flujo vulnerable de restablecimiento de contraseña
</div>

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.

### Funciones afectadas

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.

<Warning>
  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.
</Warning>

<div id="state-parameter-required-on-redirect-from-rule">
  ## Parámetro state obligatorio al redirigir desde una Rule
</div>

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.

<div id="features-affected">
  ### Características afectadas
</div>

Solo le afecta este cambio si redirige desde Rules y aún no captura ni devuelve (al endpoint /continue) el parámetro state.

<div id="delete-all-users-endpoint-change">
  ## Cambio en el endpoint para eliminar todos los usuarios
</div>

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.

### Funcionalidades afectadas

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.

<div id="email-delivery-template-customization-changes">
  ## Cambios en la personalización de las plantillas de entrega de correo electrónico
</div>

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](https://aws.amazon.com/ses/), [Mailchimp](https://mailchimp.com/features/transactional-email/), [SendGrid](https://sendgrid.com/en-us/pricing) 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.

<div id="identity-provider-access-tokens-removed-from-user-profile-and-id-token">
  ## Se eliminaron los tokens de acceso del Proveedor de identidad del perfil de usuario y del token de ID
</div>

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.

### Funcionalidades afectadas

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.

<div id="tokeninfo-endpoint-validation">
  ## Validación del endpoint Tokeninfo
</div>

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`.

### Funciones afectadas

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](https://www.jwt.io/) para decodificar el token y confirmar el valor del atributo `iss`.

<div id="email-delivery-from-address-changes">
  ## Cambios en la dirección del remitente de los correos electrónicos
</div>

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](https://aws.amazon.com/ses/), [Mailchimp](https://mailchimp.com/features/transactional-email/), [SendGrid](https://sendgrid.com/en-us/pricing)) u otro proveedor basado en SMTP. Si ya usa un proveedor de correo electrónico personalizado, no habrá cambios.

<div id="patch-and-post-endpoints-no-longer-accept-secret_encoded-flag">
  ## Los endpoints PATCH y POST ya no aceptan el indicador secret\_encoded
</div>

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.

<div id="features-affected">
  ### Características afectadas
</div>

Solo se verá afectado por este cambio si interactúa directamente con estos endpoints.