Rutas: /login, /register, /forgot-password, /reset-password y /auth/callback, más las nuevas /acceso/activar y /acceso/enlace (de Sistema de demos) y /acceso/verificar y /acceso/completar (propuestas en esta página) · Archivos principales: web: apps/web/src/app/{login,register,forgot-password,reset-password}/page.tsx, apps/web/src/app/auth/callback/page.tsx, apps/web/src/lib/api.ts, apps/web/src/components/layout/{Navbar,ConditionalLayout}.tsx, apps/web/src/components/dashboard/DashboardLayout.tsx, apps/web/src/components/admin/AdminLayout.tsx, apps/web/middleware.ts; backend: apps/backend/src/routes/auth.routes.ts, apps/backend/src/controllers/auth.controller.ts, apps/backend/src/middleware/auth.ts, apps/backend/src/models/User.ts, apps/backend/src/config/passport.ts · Prioridad: P0 · Esfuerzo total: XL (≈ 43 días-dev, de los cuales ≈ 5 ya están contados en Sistema de demos; el núcleo P0 son ≈ 12 días)

Captura de producción (rama main). Páginas relacionadas: Sistema de demos (roles, enlace mágico y control de acceso), Portal del cliente, Panel de administración, Legal, Contacto, Seguridad y calidad, Backend y API.

La cuenta es lo que convierte a un visitante en un prospecto con demos y, después, en un cliente con proyecto. Esta sección tiene que lograr cinco cosas:

1. Un prospecto aprobado llega a su demo con un clic: el enlace mágico del email, crear la contraseña (o entrar con Google) y abrir Mis demos, sin volver a escribir sus datos.
2. Una identidad por email que evoluciona de invitado a prospecto y de prospecto a cliente, sin cuentas duplicadas y sin que nadie pierda su rol.
3. Una sesión estable y segura:
   • la barra de navegación no "cierra la sesión" a los 15 minutos;
   • las credenciales viven en cookies httpOnly;
   • se puede cerrar la sesión en todos los dispositivos.
4. La interfaz depende del rol. La barra muestra Iniciar sesión o, según el caso, Mis demos, Mi portal o Panel, y después de entrar cada rol llega a su lugar.
5. La autorización se decide en el servidor, con roles, estado de la cuenta y versión del token (DECISIÓN 5).

Evidencia tomada de la rama main.

1. No existe el camino del prospecto aprobado. No hay roles prospect, client ni sales, ni cuentas en estado invitado, ni enlace mágico. El flujo de Sistema de demos no tiene dónde apoyarse.
2. La barra de navegación "cierra la sesión" sola. A los 15 minutos el prospecto ve "Iniciar sesión" aunque su sesión siga vigente, y si vuelve a entrar puede cerrar la sesión de su otro dispositivo.
3. Una sola sesión por persona. Entrar desde el celular cierra la sesión del portátil, justo cuando el prospecto le muestra la demo a su jefe.
4. Las credenciales viven donde JavaScript puede leerlas. Los tokens están en cookies normales y el usuario en localStorage. Pasar a cookies httpOnly ya es una tarea de Seguridad y calidad.
5. No hay forma de suspender una cuenta ni de cerrar todas sus sesiones. Si un comercial deja el equipo, la única salida hoy es borrar su cuenta y perder su historial.
6. El inicio de sesión depende de Redis. Si Redis falla, nadie entra, ni los clientes ni el equipo.
7. Las cuentas creadas con Google no aceptan nada: ni términos ni autorización de datos (ver Legal).
8. El registro pierde datos y promete precios viejos. Empresa y teléfono no llegan al backend, la tarjeta del plan muestra precios que contradicen los planes RAG y los requisitos de contraseña que se muestran no se exigen.
9. El destino al entrar no respeta el rol ni lo que se pidió: Google siempre lleva a /dashboard y el inicio de sesión decide el panel con una regla de email fija.
10. Hay funciones simuladas que engañan: el cambio de contraseña dice "actualizada" sin hacer nada; GitHub y "Recordarme" no funcionan.
11. La protección de las páginas solo existe en el navegador, y el equipo ve dos cabeceras en /admin.
12. Textos sin i18n y con voseo: "Iniciá sesión para continuar", "Creá tu cuenta", "Completing authentication...".
13. Datos personales en los logs: el email de cada intento de inicio de sesión.

El modelo User cambia como define la sección 5.2 de Sistema de demos. Esta página propone tres campos más.

Cómo cambia el rol

stateDiagram-v2
  [*] --> invitado: aprobación o invitación directa
  [*] --> activo: registro propio o cuenta nueva con Google
  invitado --> activo: consume el enlace mágico o entra con Google
  activo --> suspendido: el admin suspende
  suspendido --> activo: el admin reactiva

Ver diagrama como imagen

Una cuenta invitado no tiene contraseña y no puede iniciar sesión. Para eso necesita el enlace. Una cuenta suspendido no puede iniciar sesión ni refrescar. La supresión por la Ley 1581 se hace anonimizando el Lead y la cuenta (ver Legal); no es un estado.

flowchart TD
  A1["Correo y contraseña"] --> S["Sesión en cookies httpOnly"]
  A2["Continuar con Google"] --> GQ{"¿Cuenta nueva?"}
  GQ -->|"Sí"| CR["Completa tu registro: términos y autorización"]
  GQ -->|"No"| S
  CR --> S
  A3["Enlace mágico de invitación, 72 h"] --> AC["Activar: crear contraseña o Google"]
  AC --> S
  A4["Enlace de acceso sin contraseña, 15 min"] --> S
  A5["Registro propio"] --> S
  A5 --> VE["Email para verificar el correo, 24 h"]
  A6["Olvidé mi contraseña"] --> RS["Enlace de 1 h para crear una nueva"]
  RS --> A1
  S --> RD{"¿Trae un redirect interno válido?"}
  RD -->|"Sí"| D4["La ruta pedida, por ejemplo una demo"]
  RD -->|"No"| RO{"Rol"}
  RO -->|"prospect"| D1["Mis demos"]
  RO -->|"client"| D2["Portal del cliente"]
  RO -->|"Equipo"| D3["Panel de administración"]

Ver diagrama como imagen

Una sola función, lib/auth-redirect.ts (destinationFor(user, redirect)). La usan el inicio de sesión, el regreso de Google, la activación y el enlace de acceso.

Reglas de ?redirect= (lib/safe-redirect.ts):

• solo se aceptan rutas internas relativas que empiecen por una de las secciones conocidas: /demo/, /dashboard, /admin, /productos/ o /solicitar-demo;
• todo lo demás se descarta y se usa el destino del rol;
• si la ruta pedida no corresponde al rol (un prospecto que pide /admin), también se usa el destino del rol.

Se elimina la regla del email fijo en el inicio de sesión.

Es una tarea de la Fase 0 con prioridad P1: no bloquea el sistema de demos (sección 17 de Sistema de demos), pero arregla la barra de navegación, las sesiones múltiples y la dependencia de Redis.

sequenceDiagram
  autonumber
  participant N as Navegador
  participant W as Web Next
  participant A as API backend
  participant D as MongoDB
  N->>A: POST /api/auth/login con correo y contraseña
  A->>D: Busca el usuario y verifica estado y contraseña
  A->>D: Crea la AuthSession con el hash del refresco
  A-->>N: Cookies kp_at, kp_rt y kp_s, más el destino según el rol
  N->>W: Abre el destino
  W->>W: El middleware ve kp_s y deja pasar
  N->>A: GET /api/auth/profile con las cookies
  A-->>N: Nombre, rol, estado y accesos activos
  Note over N,A: A los 15 minutos vence el token de acceso
  N->>A: Petición con kp_at vencido
  A-->>N: 401 TOKEN_EXPIRED
  N->>A: POST /api/auth/refresh con kp_rt
  A->>D: Verifica la sesión, tokenVersion y el estado de la cuenta
  alt Sesión válida
    A->>D: Rota el refresco
    A-->>N: Cookies kp_at y kp_rt nuevas
    N->>A: Repite la petición
  else Refresco reutilizado, rol cambiado o cuenta suspendida
    A->>D: Revoca la familia de sesiones
    A-->>N: 401 y borra las cookies
    N->>W: Va a /login con el aviso de sesión terminada
  end

Ver diagrama como imagen

Cerrar sesión

• POST /api/auth/logout revoca la sesión actual y borra las cookies; después la web lleva a la página de inicio con el aviso "Cerraste sesión".
• En Mi cuenta, "Cerrar sesión en todos los dispositivos" llama a POST /api/auth/logout-all (endpoint nuevo propuesto), que hace tokenVersion++ y revoca todas las sesiones.

La secuencia del backend está en la sección 7.2 de Sistema de demos. Aquí se definen las pantallas de /acceso/activar?token=.

flowchart TD
  E["Email: botón Activar mi acceso"] --> P["Página de activación con el token"]
  P --> R["Lee el token y lo quita de la barra de direcciones"]
  R --> C["POST magic-link/check sin consumirlo"]
  C --> V{"Resultado"}
  V -->|"Válido, cuenta invitada"| F["Saludo, demos, crear contraseña o Google y condiciones de las demos"]
  V -->|"Válido, cuenta ya activa"| G["Botón Entrar"]
  V -->|"Vencido o usado"| X["Este enlace ya no funciona"]
  V -->|"Error de red"| Y["Reintentar"]
  F -->|"Activar mi acceso"| K["POST magic-link/consume"]
  G -->|"Entrar"| K
  K --> S{"¿Se consumió?"}
  S -->|"Sí"| M["Sesión iniciada: Mis demos o la demo del enlace"]
  S -->|"No: ya se había usado"| X
  X --> N2["Enviarme un enlace nuevo"]
  F -->|"Continuar con Google"| GG{"¿El email de Google es el invitado?"}
  GG -->|"Sí"| M
  GG -->|"No"| GE["Aviso: usa la cuenta invitada o crea una contraseña"]

Ver diagrama como imagen

Detalles

• El token: se lee una vez y se reemplaza la URL con history.replaceState. La página lleva Referrer-Policy: no-referrer y no carga scripts de analítica ni de terceros. Lo mismo aplica a /reset-password y /acceso/verificar.
• Abrir el enlace no gasta el token. Solo lo consume el botón; los filtros de correo abren los enlaces antes que la persona (DECISIÓN 6 de Sistema de demos).
• Destino: si el email de invitación es de una sola demo, el enlace puede llevar next=/demo/<slug>, que pasa por safe-redirect antes de usarse.
• /acceso/enlace: formulario de un campo, "Escribe tu correo y te enviamos un enlace para entrar". Siempre responde "Si tu correo tiene acceso, te llegará un enlace en unos minutos".

Mensajes

Se conserva, pero cambia de papel. La puerta principal para pedir una demo es Solicitar demo. El registro sirve a quien quiere una cuenta para pedir demos desde el portal y seguir sus solicitudes.

• Sin credenciales en la URL:
  • el callback del backend fija las cookies de sesión (sección 4) y redirige al destino que calcula auth-redirect;
  • el parámetro state de OAuth, firmado, transporta el redirect y, si existe, la invitación.
• Email verificado: solo se aceptan perfiles de Google con el email verificado.
• Cuenta nueva:
  • se crea con prospect, activo y emailVerifiedAt (Google ya lo verificó);
  • antes de entrar al portal pasa por /acceso/completar (propuesta aquí): "Completa tu registro", con empresa, cargo y teléfono opcional, y las mismas tres casillas del registro;
  • mientras no acepte, GET /api/auth/profile responde needsCompletion: true y la web lo vuelve a llevar ahí.
• Email invitado: si coincide con una cuenta invitado, la activa y marca como usados sus enlaces pendientes (caso borde de la sección 16 de Sistema de demos).
• Cuenta local con el mismo email: se vincula agregando google_id, como hoy.
• /auth/callback: queda como pantalla de paso, en español ("Iniciando sesión…"), y respeta el destino.

• /forgot-password:

  • pasa a i18n y conserva la respuesta única ("Si existe una cuenta con ese correo, te enviamos un enlace");

  • el email que se envía depende de la cuenta:

    Tipo de cuenta	Email
    Cuenta local	Enlace para restablecer, válido 1 hora
    Solo con Google	"Tu cuenta usa Google para entrar"
    invitado	Una invitación nueva de 72 horas

• Tokens: pasan de Redis a MagicLinkToken, con dos propósitos nuevos que esta página propone sumar al enum: reset (1 h) y verificacion (24 h).

• /reset-password:

  • el token sale de la URL al leerlo;
  • si falla: "El enlace venció o ya se usó" con Enviarme uno nuevo;
  • si funciona: tokenVersion++, se revocan todas las sesiones y llega el email "Tu contraseña cambió".

• Cambio de contraseña en Mi cuenta:

  • POST /api/auth/change-password (nuevo), que pide la contraseña actual y la nueva;
  • opción "Cerrar las otras sesiones";
  • reemplaza el formulario simulado de dashboard/profile/page.tsx;
  • guardar el perfil usa la API (PATCH /api/me/profile, nuevo) en lugar de localStorage.

• Quién la necesita: solo las cuentas de registro propio con contraseña. Las que se activan con un enlace mágico o con Google quedan verificadas automáticamente, porque ya demostraron que controlan el correo.
• Flujo:
  • email account_verify con un enlace de 24 h;
  • /acceso/verificar?token= (propuesta aquí) consume el token con un POST y fija emailVerifiedAt.
• En el portal: banner "Confirma tu correo para pedir demos" con Reenviar (máximo 3 por hora).
• Efecto: sin verificar, la persona entra al portal, pero POST /api/me/demo-requests responde 403 email_no_verificado y no recibe comunicaciones comerciales.

La sesión se lee con useSession():

• usa GET /api/auth/profile, ampliado con accountStatus, emailVerified, needsCompletion, activeGrants, expiringGrants y, para admin y sales, pendingDemoRequests;
• tiene una caché de 60 s;
• kp_s evita el parpadeo mientras carga.

La barra deja de mirar la cookie de 15 minutos.

En móvil se repiten las mismas opciones dentro del menú, a ancho completo. "Soporte" deja de llevar a /contact; para un cliente, lleva a Mensajes.

Después de entrar, el prospecto llega a Mis demos:

• Middleware de Next (apps/web/middleware.ts):
  • conserva la lógica de idioma y la del pase de demo de la sección 10.2 de Sistema de demos;
  • para /dashboard/* y /admin/* sin kp_s, redirige a /login?redirect=<ruta>;
  • es solo comodidad: la autorización real sigue en la API.
• Layouts:
  • DashboardLayout y AdminLayout dejan de leer localStorage y usan useSession();
  • con el rol equivocado muestran "No tienes acceso a esta sección" y un botón al destino de su rol;
  • el menú del panel depende del rol (tarea 23 de Sistema de demos).
• ConditionalLayout:
  • oculta la navegación pública en /admin (se acaba la doble cabecera);
  • en /acceso/* muestra una cabecera mínima, solo con el logo.
• Servidor: authenticate + requirePermission en todas las rutas (sección 3 de Sistema de demos), con accountStatus y tokenVersion verificados.

Todos pasan por el outbox (OutboundMessage) y viven en apps/backend/src/templates/account/. Las invitaciones (demo_invite_*, invite_reminder, demo_new_access) ya están en la sección 11 de Sistema de demos.

password_changed (texto propuesto):

Asunto: Tu contraseña cambió

Hola {{nombre}}:

La contraseña de tu cuenta de KopTup cambió el {{fecha}} a las {{hora}} (hora de Colombia). Por seguridad, cerramos tus otras sesiones.

Si no fuiste tú, restablécela ahora: {{resetUrl}} y escríbenos a {{buzonSoporte}}.

• Rate-limit con almacén compartido (tarea transversal de Seguridad y calidad):

  Acción	Límite
  Inicio de sesión	Por IP y por correo. Después de 5 intentos fallidos en 15 minutos, se pide Turnstile
  Registro	5 por hora por IP
  Olvidé mi contraseña y enlace nuevo	3 por hora por correo

• Respuestas uniformes en todos los endpoints públicos que tocan cuentas.

• Logs:

  • sin correos en claro: se guarda un hash del correo y el resultado;
  • una alerta al admin si hay muchos intentos fallidos sobre cuentas del equipo.

• 2FA para el equipo (Fase 2): TOTP con códigos de recuperación, obligatorio para admin y sales, porque son quienes dan acceso a las demos privadas.

Se suman a los de la sección 8 de Sistema de demos y deben agregarse a Backend y API.

SEO

• Todas las páginas de autenticación y de /acceso/* llevan robots: noindex, nofollow en su metadata (no basta con robots.txt).
• Títulos propios: "Iniciar sesión | KopTup", "Crear cuenta | KopTup", "Activa tu acceso | KopTup", "Recuperar contraseña | KopTup".

i18n

• Todo el texto va en messages: loginPage, registerPage y un namespace nuevo authPages para recuperar, restablecer, activar, verificar y completar.
• Español con "tú" (sin "Iniciá" ni "Creá") y textos en inglés.
• Se borran los TODO: extract to i18n y el texto en inglés de /auth/callback.

Accesibilidad

• Etiquetas visibles y autocomplete: email, current-password en el inicio de sesión y new-password en el registro, la activación y el restablecimiento.
• Botón "Mostrar" con aria-pressed y etiqueta.
• Errores con aria-live y foco en el primer campo con error.
• No se bloquea pegar la contraseña, para que funcionen los gestores de contraseñas.
• Contraste AA y foco visible.
• Turnstile en modo gestionado: casi nunca pide interacción.

Rendimiento

• Las páginas son cascarones server con formularios client pequeños, y solo reciben sus namespaces de mensajes.
• Sin analítica ni scripts de terceros en /acceso/*, /reset-password ni /auth/callback: es un tema de privacidad y de seguridad, porque esas páginas reciben tokens.

Metas iniciales, para validar con 8 semanas de datos reales (ver la nota de Flujo del cliente).