Auth
TED OS autentica con Clerk. La autenticación está centralizada en un paquete @tedos/auth
reutilizable y compartida entre las superficies de la plataforma, que viven en subdominios de
tuempresa.digital.
Esta página describe la mecánica de auth. No aparecen claves, tokens ni valores de entorno reales en ninguna parte — las variables de entorno (claves de Clerk, el token de GitHub) se mencionan solo por su nombre.
El paquete reutilizable
@tedos/auth centraliza las dos piezas que toda superficie necesita:
- CSP — una Content-Security-Policy que permite la API frontend de Clerk. La CSP se deriva de la clave publicable de Clerk, así que cada superficie obtiene el dominio Clerk correcto sin mantener a mano un hostname. (El punto de entrada de la CSP es JavaScript plano, porque la configuración de Next corre en Node y no puede importar TypeScript.)
- Middleware — el middleware de Clerk que protege las rutas.
El entry de React del paquete (@tedos/auth/react) también provee la puerta del lado del cliente
usada por el sitio de documentación.
La decisión de la plataforma es proteger las superficies internas con Clerk vía este paquete, no con un muro de acceso de pago del proveedor de hosting.
Las apps de cliente en subdominios comparten la sesión
Las superficies de la plataforma — admin, consola y apps de cliente — corren en subdominios de
tuempresa.digital. Comparten la sesión de Clerk gratis vía la cookie raíz, sin necesidad de
satellite / tier Pro de Clerk. Para que una superficie inicie sesión, deben cumplirse las tres cosas:
- La app es código Clerk plano (no una configuración satellite).
- Su CSP permite la API frontend de Clerk para
tuempresa.digital(derivada de la clave publicable). - El subdominio está añadido a la allowlist del Dashboard de Clerk.
Cómo autentica cada superficie
| Superficie | Cómo |
|---|---|
| admin | Clerk; una guardia requireProject mapea una org de Clerk → proyecto + rol; cada ruta /p/:id/* se autoriza del lado del servidor |
| console | App de Clerk en un subdominio, compartiendo la sesión de cookie raíz |
| comprender (app de cliente) | App de Clerk en un subdominio bajo la marca/URL del cliente, compartiendo la sesión |
| este sitio de docs | Una puerta Clerk del lado del cliente vía @tedos/auth/react — la puerta renderiza sin protección cuando no hay clave publicable configurada, así el dev local y el build nunca se rompen |
Tenancy + roles
En el producto, una organización de Clerk es un tenant (= un proyecto = un cliente). La membresía de org de un usuario mapea a un rol de proyecto (Owner · Sales · Finanzas · Soporte · Alumno); el operador es superadmin. El alcance de tenant se impone del lado del servidor, nunca confiado del cliente. Ver SoR del producto → Roles.
La puerta de la documentación
Este sitio de documentación está protegido por Clerk. La puerta es un módulo de cliente que lee la clave publicable de Clerk desde un custom field de tiempo de build; cuando la clave no está definida (dev local o un build sin configurar) la puerta renderiza sin protección para que el sitio siempre compile. La puerta debe permanecer intacta cuando este sitio cambie.