Saltar al contenido principal
Al desarrollar productos de Auth0, nos comprometemos a:
  • Ofrecer valor a los clientes desde el principio y con frecuencia, iterando en función de sus comentarios
  • Buscar una comprensión profunda de nuestros clientes y tenerlos en cuenta en cada decisión
  • Recopilar y analizar datos de forma constante para poder tomar mejores decisiones
  • Visualizar y diseñar las versiones actuales, idealizadas y futuras de todo nuestro producto al agregar funcionalidades
Este documento proporciona orientación sobre qué constituye cambios compatibles con versiones anteriores (non-breaking) y cambios incompatibles con versiones anteriores (breaking) en la plataforma Auth0. La distinción entre estos cambios ayuda a los desarrolladores a anticipar posibles impactos en sus aplicaciones al consumir servicios de Auth0. Este documento describe cambios comunes y su compatibilidad para ayudar a establecer expectativas sobre las integraciones. Los cambios descritos no son exhaustivos ni completos; para obtener más detalles sobre los cambios incompatibles, consulta los temas a continuación.
Lee…Para obtener información sobre…
Etapas de lanzamiento del productoCómo Auth0 incorpora, lanza y retira funcionalidades del producto.
Proceso de migraciónCómo funciona el proceso de deprecación y migración de Auth0.
Deprecaciones y migracionesInformación sobre las deprecaciones actuales y cómo migrar a nuevos comportamientos o funcionalidades.
Migraciones anterioresMigraciones anteriores habilitadas previamente para los clientes.

APIs de Auth0

Auth0 expone y mantiene APIs como Authentication API y Management API, cada una de las cuales define un contrato entre Auth0 y sus clientes en función de las especificaciones de API documentadas y sus artefactos asociados. Auth0 sigue estándares reconocidos de organismos como el IETF y OIDC; cuando no existen estándares, se desarrollan APIs propietarias siguiendo las prácticas recomendadas. De vez en cuando, es necesario realizar cambios en estas APIs, ya sean compatibles con versiones anteriores o no retrocompatibles, para mejorar su funcionalidad, seguridad o rendimiento.

Cambios compatibles con versiones anteriores que no generan incompatibilidades

Un cambio compatible con versiones anteriores no interrumpe la interoperabilidad entre la plataforma de Auth0 y las aplicaciones de los clientes, y no requiere que los clientes tomen medidas inmediatas ni participen en el proceso de migración. Algunos ejemplos de cambios que no generan incompatibilidades son:
  • Cadenas opacas: El formato y el tamaño de las cadenas opacas (por ejemplo, tokens e identificadores) pueden cambiar. Los clientes no deben asumir un tamaño ni un formato fijos. El tamaño máximo de las cadenas opacas no superará los 4096 caracteres.
  • Tamaño del : Según la especificación de (RFC6749), el tamaño de las credenciales JWT no está definido. Auth0 puede emitir JWT de tamaño variable, y los clientes no deben asumir un tamaño específico.
  • Tamaño del código de autorización: Los clientes deben prever que los códigos de autorización, según la especificación de OAuth, pueden variar de tamaño.
  • Parámetros de respuesta no reconocidos: Los clientes deben ignorar los parámetros de respuesta no reconocidos, lo que permite a Auth0 añadir nuevas funcionalidades sin afectar la funcionalidad actual.
  • Nuevos recursos, campos, encabezados o alcances: La incorporación de nuevos recursos, campos, encabezados o alcances de la API no afectará a los clientes existentes que no reconozcan ni utilicen estos elementos.
Para obtener una explicación más detallada de los cambios compatibles con versiones anteriores, consulta las directrices de cambios de API de Auth0 en las etapas del ciclo de vida del producto.

Cambios incompatibles con versiones anteriores

Un cambio incompatible con versiones anteriores puede provocar fallos cuando altera la interoperabilidad entre la plataforma de Auth0 y las aplicaciones de los clientes. Cuando este tipo de cambio es necesario, se sigue el proceso de deprecación y migración para notificar a los clientes y darles soporte a fin de que ajusten las implementaciones en sus inquilinos. Algunos ejemplos de cambios incompatibles con versiones anteriores son:
  • Eliminación de recursos de API: Si se elimina o se cambia el nombre de un recurso de API, los clientes que dependan de ese recurso experimentarán un cambio incompatible con versiones anteriores.
  • Cambios en la estructura de URI: Modificar la estructura de una URI existente puede afectar a los clientes que dependen de ella.
  • Eliminación de métodos, parámetros o campos: Si se elimina o se cambia el nombre de un método, parámetro o campo, esto supondrá un cambio incompatible con versiones anteriores para los clientes que utilicen estos elementos.
  • Cambios en los valores predeterminados: Los cambios en el valor predeterminado de un campo pueden afectar a las integraciones existentes y constituir un cambio incompatible con versiones anteriores.
  • Cambios en las respuestas de error y los códigos de estado: Las modificaciones en los formatos de respuesta de error, los códigos de error o los códigos de estado pueden romper el comportamiento existente de los clientes.
  • Formato JWT: Los cambios en el formato JWT de los tokens son cambios incompatibles con versiones anteriores.
  • Formato JSON: Cambiar el tipo de un valor JSON es un cambio incompatible con versiones anteriores.
Cualquier cambio incompatible con versiones anteriores activa el proceso de deprecación, en el que se notifica a los clientes y se les concede al menos seis meses para migrar al nuevo comportamiento. Para obtener más información, consulta el proceso de deprecación y fin de vida útil.

El compromiso de Auth0

Auth0 minimiza las interrupciones causadas por cambios no compatibles con versiones anteriores mediante el siguiente proceso:
  • Anuncio de deprecación: Auth0 anuncia la deprecación para avisar a los clientes de un cambio próximo.
  • Ventana de migración: Los clientes disponen de un período mínimo de seis meses para migrar a la funcionalidad actualizada, con orientación en nuestro proceso de migración.
  • Fin de vida útil: Cuando finaliza la ventana de migración, la funcionalidad deprecada pasa a la etapa de fin de vida útil y deja de estar disponible.

API no documentadas

Las API no documentadas de Auth0 se consideran privadas y pueden cambiar sin previo aviso. Estas API no están cubiertas por el proceso de deprecación, y los clientes deben evitar depender de ellas en sistemas de producción.