Dejar Auth0: qué se migra de verdad, y lo único que no te van a entregar

La mayoría de los equipos no abandonan Auth0 porque les disguste. Se van porque la factura se disparó, o porque SAML y SCIM resultaron estar escondidos detrás de un nivel empresarial cobrado por conexión, y el enlace SSO de cada nuevo cliente hace correr el contador. Luego se plantean migrar de verdad su proveedor de identidad, deciden que suena aterrador y se quedan un año más.

Es menos aterrador de lo que parece. Esto es lo que implica una migración real desde Auth0 (las partes aburridas, las partes peliagudas y la única parte genuinamente difícil) para que puedas juzgarlo por ti mismo.

Qué hay en tu inquilino de Auth0

Un puñado de cosas tienen que aterrizar en algún sitio nuevo:

• Aplicaciones → clientes OAuth/OIDC. Callbacks, URL de cierre de sesión, orígenes permitidos, tipos de concesión y el secreto de cliente. Mecánico.
• APIs (servidores de recursos) + scopes → audiencias y scopes, conectados a los clientes que los usan (Auth0 lo registra como «client grants»).
• Roles y sus asignaciones → roles + vínculos de rol por usuario.
• Conexiones → conexiones empresariales (OIDC/SAML), sociales y de base de datos. El OIDC empresarial se mapea limpiamente a un proveedor federado; el resto lo reconfiguras.
• Usuarios → perfiles, metadatos e identidades sociales/empresariales vinculadas.

Nada de eso es difícil en principio. El nerviosismo viene de tres cosas concretas.

Las tres cosas que ponen nervioso a la gente

1. Mantener estables las identidades. A tus usuarios se les referencia por su sub (y a tus aplicaciones por client_id) por todas partes: refresh tokens en manos de aplicaciones aguas abajo, filas SCIM en los IdP de tus clientes, identificadores de usuario almacenados en tu propia base de datos. Si una migración genera identificadores nuevos, todo eso se rompe en silencio. La solución es sencilla de enunciar y esencial de acertar: preservar el user_id de Auth0 como sub y mantener client_id idéntico. Entonces nada aguas abajo lo nota.

2. Las contraseñas, la parte genuinamente difícil. La Management API de Auth0 nunca devuelve los hashes de contraseñas. Es una política deliberada de Auth0, no una carencia de tu herramienta. Tienes dos caminos honestos:

• Solicitar la exportación masiva asistida por el soporte de Auth0, que te entrega un archivo NDJSON con el hash bcrypt de cada usuario. bcrypt es portable: cualquier cosa que verifique bcrypt puede tomar esos hashes idénticos, y tus usuarios no restablecen nada.
• O bien omitir los hashes por completo y hacer que los usuarios definan una nueva contraseña en el primer inicio de sesión. No se «pierde» nada (no había hash que llevar) pero es un paso visible para tus usuarios.

No existe ninguna API de autoservicio para los hashes. Quien te diga que una exportación de Auth0 con un solo clic incluye las contraseñas sin ese archivo del soporte está exagerando.

3. El tope de los 1.000 usuarios. La API de listado de usuarios de Auth0 devuelve como máximo 1.000 usuarios. Para un inquilino más grande, el archivo de exportación masiva (el mismo que lleva los hashes) es la fuente real y completa de usuarios, no la API en vivo.

Convertirlo en un solo clic

Esto es lo que integramos en Authagonal. Apuntas el importador a una aplicación machine-to-machine de Auth0 (solo scopes de lectura) y este:

• Ejecuta primero una vista previa de solo lectura: cuenta cada aplicación, API, rol, conexión y usuario que importará y señala todo lo que requiere atención. No se escribe nada hasta que confirmas.
• Trae las aplicaciones, los scopes/audiencias de API, los roles + asignaciones, los usuarios + metadatos y las conexiones OIDC empresariales, preservando sub y client_id para que los tokens y referencias existentes sigan resolviéndose.
• Vuelve a hashear los secretos de cliente de Auth0 (legibles en texto plano) para que tus aplicaciones sigan autenticándose sin rotación.
• Importa los hashes de contraseña bcrypt idénticos si proporcionas el archivo de exportación, y ese archivo también levanta el tope de los 1.000 usuarios. ¿Sin exportación? Los usuarios definen una contraseña en el primer inicio de sesión.

Y como las funciones empresariales (SAML, SCIM, MFA, registros de auditoría, dominios personalizados) van incluidas en cada plan en lugar de cobrarse por conexión, aquello que te empujó hacia la salida no te espera al otro lado.

Un inciso sobre probar migraciones

Probamos el importador contra una base de datos real y precargada, no contra mocks, y mereció la pena. ASP.NET Identity almacena LockoutEnd como un datetimeoffset, y leerlo con GetDateTime() lanza una excepción en ese tipo. Un solo usuario bloqueado habría hecho fracasar una importación entera. Eso solo lo detectas ejecutando el importador real contra datos reales. Si estás evaluando alguna herramienta de migración, pregunta cómo se prueba: «mockeamos la API de origen» no es lo mismo que «la ejecutamos contra un inquilino poblado».

Si estás mirando hacia la salida

La migración es más aburrida de lo que temes (previsualízala, conserva tus identificadores, decide tu camino de contraseñas) siendo la única restricción real la exportación de hashes de Auth0. Si quieres ver qué pasaría desde tu inquilino, la vista previa es de solo lectura y te lo muestra todo antes de que confirmes.

→ Migrar desde Auth0