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
SOCIAL SHARE CARD GENERATOR