Skip to main content

Modelo de autenticación: usuarios normales vs. superadmin

La plataforma expone dos flujos de autenticación completamente separados, con distintos endpoints, distintos scopes de token y distinta superficie de datos accesible.

Figura 3. Separación de autenticación entre usuario normal y superadmin.

Usuarios normales (estudiantes/desarrolladores de una célula)​

  • Registro y login público en /api/auth/register y /api/auth/login.
  • El JWT emitido incluye el tenant_id/celula_id al que pertenece el usuario.
  • Cada petición a un endpoint de tenant valida que el tenant_id del token coincida con el tenant resuelto desde el path; si no coincide, se responde 403 sin tocar la base de datos.
  • No tienen visibilidad de otras células ni del catálogo global.

Superadmin​

  • Login exclusivo en /api/admin/auth/login, sin endpoint de autorregistro: las cuentas de superadmin se crean manualmente (seed/migration) o por invitación de otro superadmin, nunca por un formulario público.
  • El JWT emitido lleva un claim de rol distinto (SuperAdmin) y ningún tenant_id asociado, ya que su alcance es el catálogo completo.
  • Únicamente el superadmin puede invocar los endpoints de aprovisionamiento, pausa, eliminación de bases de datos y consulta de cuotas globales.
  • Se recomienda 2FA obligatorio para estas cuentas, dado el nivel de privilegio (pueden crear/eliminar bases de datos reales).
Por qué así

Separar los flujos de login (no solo los roles dentro de un mismo login) reduce la superficie de ataque: un endpoint de autorregistro público para superadmin sería una puerta de escalación de privilegios trivial de explotar. Al no existir ese endpoint, la única forma de obtener una cuenta de superadmin es a través de un proceso controlado fuera de la API pública. Además, mantener JWTs con estructuras de claims distintas (con/sin tenant_id) permite que el middleware de autorización rechace por diseño cualquier intento de un usuario normal de acceder a rutas de administración, y viceversa, sin necesitar lógica de negocio adicional: la validación de claims es un concern transversal de autenticación, no una regla de negocio, por lo que puede vivir en el backend sin romper la filosofía database-centric.