Uecko_ERP/docs/architecture/identity-roadmap.md

218 lines
3.9 KiB
Markdown

# 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:
```txt
login
refresh rotado
logout
session
access token verifier
refresh token persistence
middlewares genéricos
```
Pendiente técnico recomendado:
```txt
- sanear typings de bcrypt/jsonwebtoken en identity
- revisar errores reales de node tsc
```
## Fase 2 · Migración backend desde `@erp/auth/api`
Estado:
```txt
catalogs migrado
customers migrado
customer-invoices migrado
factuges migrado
supplier pendiente intencionado
```
Siguiente decisión:
```txt
migrar supplier o mantenerlo legacy temporalmente
```
## Fase 3 · Frontend login
Objetivo:
Crear pantalla `/login` en Frontend ERP contra:
```http
POST /identity/auth/login
```
Debe implementar:
```txt
email/password
persistencia temporal de tokens
carga de sesión actual
logout básico
preparación para refresh automático
```
No incluir todavía:
```txt
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:
```txt
GET /identity/companies
GET /identity/companies/current
PATCH /identity/companies/current
```
Frontend deberá:
```txt
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:
```txt
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:
```txt
Role
PermissionCode
PermissionDefinition
IPermissionCatalog
RolePermissionValidator
```
Pendiente:
```txt
RoleCreator
RoleUpdater
PermissionResolver
AuthorizationService
middleware authorize(permission)
endpoints /identity/roles
endpoints /identity/permissions
```
Reglas:
```txt
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:
```txt
registro público
creación de primera empresa
invitaciones
alta interna por admin
```
Posible secuencia segura:
```txt
1. RegisterAccountUseCase
2. CreateInitialCompanyUseCase
3. CreateOwnerMembershipUseCase
4. Seed owner role
5. Emitir sesión
```
Debe evitarse:
```txt
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:
```txt
- 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:
```powershell
rg -n -F "@erp/auth" modules apps packages
rg -n -F "mockUser" modules apps packages
```
## Decisiones explícitas
No hacer:
```txt
- 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:
```txt
- 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
```