3.9 KiB
Identity Roadmap
Objetivo general
Completar la transición desde el módulo legacy auth hacia identity, sin mezclar autenticación con autorización, tenant context, datos documentales o frontend legacy.
Fase 1 · Backend auth runtime
Estado: prácticamente completado.
Incluye:
login
refresh rotado
logout
session
access token verifier
refresh token persistence
middlewares genéricos
Pendiente técnico recomendado:
- sanear typings de bcrypt/jsonwebtoken en identity
- revisar errores reales de node tsc
Fase 2 · Migración backend desde @erp/auth/api
Estado:
catalogs migrado
customers migrado
customer-invoices migrado
factuges migrado
supplier pendiente intencionado
Siguiente decisión:
migrar supplier o mantenerlo legacy temporalmente
Fase 3 · Frontend login
Objetivo:
Crear pantalla /login en Frontend ERP contra:
POST /identity/auth/login
Debe implementar:
email/password
persistencia temporal de tokens
carga de sesión actual
logout básico
preparación para refresh automático
No incluir todavía:
register
forgot password
MFA
OAuth
roles/permisos
selección avanzada de empresa
Fase 4 · Selección de empresa
Backend ya usa X-Company-Id para rutas tenant-scoped.
Pendiente:
GET /identity/companies
GET /identity/companies/current
PATCH /identity/companies/current
Frontend deberá:
listar empresas accesibles
permitir seleccionar empresa activa
enviar X-Company-Id en rutas tenant-scoped
Fase 5 · Membership real
Actualmente X-Company-Id se valida sintácticamente pero no contra membership real.
Pendiente:
persistencia Company
persistencia CompanyMembership
validación accountId + companyId
bloqueo si membership disabled/invited
No validar membership en access token.
La validación debe ocurrir en backend por request o mediante contexto cacheado controlado.
Fase 6 · Roles y permisos
Ya existe base conceptual:
Role
PermissionCode
PermissionDefinition
IPermissionCatalog
RolePermissionValidator
Pendiente:
RoleCreator
RoleUpdater
PermissionResolver
AuthorizationService
middleware authorize(permission)
endpoints /identity/roles
endpoints /identity/permissions
Reglas:
cada módulo declara sus propios permisos
identity no define permisos de otros módulos
Role.permissionCodes usa PermissionCode[] transversal
Fase 7 · Registro y onboarding
No implementar registro público sin decisión previa.
Opciones futuras:
registro público
creación de primera empresa
invitaciones
alta interna por admin
Posible secuencia segura:
1. RegisterAccountUseCase
2. CreateInitialCompanyUseCase
3. CreateOwnerMembershipUseCase
4. Seed owner role
5. Emitir sesión
Debe evitarse:
crear cuentas sin empresa cuando el producto exige tenant
crear empresas sin owner
crear roles sin permisos válidos
Fase 8 · Retirada de modules/auth
Solo posible cuando:
- supplier deje de usar @erp/auth/api
- frontend deje de usar @erp/auth/client
- no queden imports a @erp/auth en runtime
Antes de retirar:
rg -n -F "@erp/auth" modules apps packages
rg -n -F "mockUser" modules apps packages
Decisiones explícitas
No hacer:
- meter companyId en access token
- meter roles/permisos en access token
- meter companySlug en access token
- poblar companySlug desde auth middleware
- crear helpers auth por módulo
- usar getInternal("identity") desde módulos consumidores
- usar IdentityInternalDeps desde módulos consumidores
Sí hacer:
- usar requireIdentityTenant(params) en rutas tenant-scoped
- usar requireIdentityAuthenticated(params) en rutas solo autenticadas
- resolver datos documentales desde servicios específicos
- validar membership en backend cuando exista persistencia real