Todas las entradas

Dejar el Duende autoalojado: qué migra y qué dejas de operar

AuthagonalJune 18, 2026
duendeidentityserverdotnetoidcmigration

Traducido con IA del original en inglés. Leer el original

Duende IdentityServer es un software realmente bueno: si quieres ser dueño de tu capa de identidad de principio a fin, es el estándar en .NET. Pero "ser dueño" es justamente todo el coste: lo alojas, lo parcheas, lo escalas y construyes todo lo que lo rodea, la interfaz de administración, el MFA, los registros de auditoría, la imagen de marca, una página de estado, la gestión de usuarios y roles. En algún momento, un equipo decide que prefiere no operar un IdP, y la única pregunta que importa es cuán doloroso resulta migrar. Esto es lo que realmente migra.

Lo que realmente estás ejecutando

Autoalojar Duende te hace responsable de mucho más que los endpoints de tokens:

  • El propio IdP: alojamiento, escalado, parcheo y la licencia (SAML es un complemento de pago adicional).
  • Todo lo que lo rodea y que construiste tú mismo: portal de administración, registro de MFA, registro de auditoría, imagen de marca personalizada, una página de estado, gestión de usuarios y roles.

Esa segunda lista suele ser donde se va el verdadero tiempo.

Lo que migra, y es en su mayoría mecánico

Duende guarda su configuración en SQL (la ConfigurationDb) y sus usuarios en ASP.NET Identity. Una migración lee ambos:

  • Clients → clientes OAuth, incluidos los URI de redirección y de cierre de sesión, los orígenes CORS, los tipos de concesión, la semántica de uso y expiración de los refresh tokens y las duraciones de los device codes. Los clientes deshabilitados se importan deshabilitados; los secretos expirados se omiten con una advertencia.
  • Scopes → los ApiScopes e IdentityResources se mapean directamente. La capa intermedia ApiResource de Duende (una audiencia más una lista de claims compartida) se aplana sobre el modelo más simple: el nombre del recurso se convierte en una audiencia en cada cliente que usa un scope miembro, y sus claims se fusionan con esos scopes.
  • Users → la buena noticia: los hashes de contraseña de ASP.NET Identity V3 (y el bcrypt heredado) se verifican de forma nativa y se vuelven a hashear en el primer inicio de sesión. Sin restablecimientos de contraseña, sin tickets de soporte, nada que tus usuarios noten. (Esta es la parte que es genuinamente difícil al dejar Auth0: con Duende simplemente funciona, porque es el mismo hashing que tu aplicación ya usa.)
  • Los roles y asignaciones, los inicios de sesión externos y los proveedores de identidad OIDC se traen todos. Los proveedores SAML se marcan para que los reconfigures en el otro lado.

La parte de la estabilidad de la identidad

Como en cualquier cambio de IdP, lo que hay que hacer bien es no cambiar el sub del usuario ni el client_id: los refresh tokens posteriores, las filas SCIM en los IdP de los clientes y los identificadores de usuario almacenados en tu propia base de datos los referencian todos. El importador preserva ambos. Y si uno de los propietarios de tu portal también existe como usuario de Duende con un identificador distinto, los reconcilia (rotando al sub de Duende) mediante pasos escalonados y recuperables, en lugar de dejar a un propietario migrado a medias que no puede iniciar sesión.

Un inciso sobre probar migraciones (una trampa de .NET)

Probamos el importador contra una base de datos Duende real y poblada, no contra mocks, y dio resultado. ASP.NET Identity almacena AspNetUsers.LockoutEnd como datetimeoffset, y leerlo con reader.GetDateTime() lanza una InvalidCastException con ese tipo. Así que un único usuario bloqueado habría hecho fallar toda la importación de usuarios. Eso solo se descubre ejecutando el importador contra datos reales que incluyan un usuario bloqueado. Si estás sopesando alguna herramienta de migración, esa es la pregunta que merece la pena hacer: ¿se prueba contra una base de datos poblada, o solo se mockea contra la API de origen?

Lo que dejas de hacer

El sentido de migrar no es la migración: es todo lo que viene después. SAML, SCIM, MFA, registros de auditoría, dominios personalizados e imagen de marca vienen incluidos en lugar de ser cosas que construyes y operas, y parchear y escalar el IdP dejan de ser tu problema. Si autoalojar Duende fue una decisión deliberada ("queremos control total") y sigue siéndolo, quédate: es una elección perfectamente buena. Esto es para cuando operar un IdP ha dejado de ser donde quieres dedicar tu tiempo.

Si te lo estás planteando

La migración es en su mayoría mecánica, las contraseñas se trasladan sin restablecimientos, y la vista previa es de solo lectura: apúntala a tu base de datos Duende y te muestra exactamente lo que se importaría antes de escribir nada.

Migrar desde Duende