Autenticación unificada del ecosistema
Estado: pendiente de implementación
Al 13 de septiembre de 2026, cada facultad gestiona su autenticación de forma independiente. Axia y GNOSIS usan dos aplicaciones Clerk distintas y todavía no comparten sesión. El plan aprobado comienza con preparación e integración de PACT en Q3; la fusión de Axia y GNOSIS se prevé para Q4, después de los primeros pagos de GNOSIS.
Visión
La cuenta Dikaia permitirá usar una misma identidad en las facultades integradas. Cada producto seguirá aplicando sus propios planes, roles y permisos. El acceso Founding Member se centralizará en una etapa posterior.
Estado actual
Estado relevado en los repositorios del ecosistema el 13 de septiembre de 2026:
| Facultad | Autenticación actual | Situación para la unificación |
|---|---|---|
| Axia | Clerk, aplicación propia (clerk.axia.dikaia.io) | En producción; padrón independiente de GNOSIS |
| GNOSIS | Clerk, otra aplicación (clerk.gnosis.dikaia.io) | En producción; su aplicación Clerk es la elegida para conservarse en la fusión |
| ARGOS | better-auth | Mantiene su proveedor; integración futura mediante «Continuar con Dikaia» |
| PACT | Auth.js / NextAuth v5 | En desarrollo en pact.dikaia.io, sin lanzamiento ni usuarios externos; primera integración prevista |
| ERGON | Supabase Auth | Producto pausado |
| FORUM | Por verificar | El relevamiento no confirmó un proveedor de autenticación |
| AEGIS | Auth.js / NextAuth con adaptador Prisma | Incorporación fuera del alcance de Q3 |
| PRAXIS | Supabase Auth | Incorporación fuera del alcance de Q3 |
| SCRIBE | Supabase Auth | Incorporación fuera del alcance de Q3 |
Usar Clerk en dos productos no une sus cuentas: hoy el usuario debe registrarse e iniciar sesión por separado en Axia y GNOSIS. La activación del beneficio Founding Member se realiza en cada sistema.
Objetivos de la unificación
- Identidad: una cuenta y una sesión compartidas entre las facultades que se integren a la aplicación Clerk común.
- Derecho de acceso: centralizar el beneficio Founding Member para que cada producto derive el plan correspondiente.
- Permisos y organizaciones: mantener los roles y la pertenencia a empresas o estudios bajo las reglas de cada facultad.
Diseño previsto
Una aplicación Clerk para los subdominios Dikaia
La integración usará una sola aplicación Clerk para los productos que se incorporen bajo *.dikaia.io, con Frontend API previsto en clerk.dikaia.io. Se conservará la aplicación de GNOSIS para reducir los cambios de identificadores vinculados a datos existentes.
Clerk permite compartir sesiones entre subdominios de una misma aplicación. Los productos alojados en otro dominio raíz requieren una configuración adicional de dominios satélite o su traslado a un subdominio Dikaia antes de integrarse. Ver la documentación de Clerk sobre dominios y sesiones.
La fusión requiere medir ambos padrones, resolver las cuentas presentes en los dos productos y preparar el remapeo de identificadores de Axia. Antes de ejecutarla se confirmará con Clerk cómo cambiar el dominio de la aplicación de GNOSIS y cómo trasladar las cuentas con contraseña.
Flujo de autenticación (futuro)
- El usuario entra a una facultad integrada e inicia sesión con la cuenta Dikaia.
- Clerk mantiene la identidad y la sesión compartida entre los subdominios configurados.
- La facultad valida la sesión y aplica sus propios permisos, plan y requisitos de aceptación de términos.
- Al entrar a otra facultad integrada, esta reconoce la sesión y verifica el acceso correspondiente a ese producto.
ARGOS conservará better-auth. Su integración se prevé mediante el botón «Continuar con Dikaia», con Clerk como proveedor OAuth; sus sesiones y organizaciones seguirán gestionándose en ARGOS. Esa integración todavía está pendiente.
Roles y permisos
Cada facultad define sus roles. La cuenta Dikaia llevará identidad y derecho de acceso compartido, como el beneficio Founding Member. Un administrador de GNOSIS no obtiene por ello permisos de administrador en Axia.
La metadata compartida se organizará en espacios separados por producto para evitar colisiones. El esquema definitivo se aprobará antes de fusionar los padrones. Las organizaciones y sus miembros seguirán administrándose en cada facultad durante estas fases.
Integración técnica (prevista)
| Elemento | Diseño aprobado |
|---|---|
| Proveedor común | Clerk, una sola aplicación para los productos integrados |
| Aplicación que se conserva | GNOSIS, sujeto a confirmar con Clerk el procedimiento de cambio de dominio |
| Frontend API e issuer previstos | https://clerk.dikaia.io |
| Validación de tokens | RS256 mediante las claves públicas de Clerk; cada backend valida el emisor y los orígenes autorizados de su integración |
| Autorización | Roles, planes y organizaciones de cada producto |
| Excepción prevista | ARGOS mantiene better-auth e incorpora el acceso con Dikaia mediante OAuth |
Estos valores describen la configuración objetivo; todavía no acreditan un servicio compartido activo.
Roadmap
Fase 0 — Preparación en Q3 2026
- Corregir esta documentación con el estado real por producto.
- Medir los padrones de producción de Axia y GNOSIS y sus coincidencias.
- Confirmar con Clerk el traslado de cuentas con contraseña y el cambio de dominio de la aplicación de GNOSIS.
- Diseñar la metadata compartida y preparar la configuración DNS de
clerk.dikaia.io. - Preparar términos generales del ecosistema y anexos por facultad, sujetos a revisión antes de publicar.
Fase 1 — PACT durante su desarrollo, prevista para Q3 2026
- Integrar PACT con la aplicación Clerk común mientras sigue sin usuarios externos.
- Adaptar la validación de sesión de su backend y conservar el vínculo de cada usuario con su empresa.
- Verificar el recorrido completo en staging antes de aprobar el paso a
pact.dikaia.io.
Fase 2 — Fusión de Axia y GNOSIS, prevista para Q4 2026
La ejecución comienza después de los primeros pagos de GNOSIS y requiere aprobar la ventana de migración.
- Configurar el dominio común en la aplicación Clerk de GNOSIS según el procedimiento confirmado con el proveedor.
- Incorporar las cuentas de Axia y remapear sus identificadores, preservando el acceso al historial y la evidencia de aceptación legal.
- Aplicar la separación de metadata por producto y comprobar que los roles no se propaguen entre facultades.
- Verificar el inicio de sesión y los planes de ambos productos antes de retirar la aplicación Clerk anterior de Axia.
Fase 3 — Acceso compartido y ARGOS, después de la fusión
- Centralizar el beneficio Founding Member y derivar el plan correspondiente en cada facultad.
- Integrar «Continuar con Dikaia» en ARGOS conservando better-auth.
- Evaluar la incorporación de otras facultades cuando se reactiven o estén listas para integrarse.
Seguridad y acceso mientras tanto
El acceso sigue administrándose por producto. La disponibilidad y activación de MFA deben comprobarse en la configuración de cada aplicación antes de ofrecerlo como una protección activa. Los administradores deben revisar periódicamente los usuarios y permisos de cada facultad y revocar las sesiones afectadas ante accesos no reconocidos.
Para problemas con una cuenta o con la activación de un beneficio, consultá el Centro de soporte.
Siguientes pasos
- Revisar Datos compartidos para conocer la propuesta de sincronización, que corresponde a otra iniciativa.
- Explorar el Workflow multi-facultad para ver los escenarios de integración previstos.