--- title: "Autenticación" description: "Los modos password y none, sesiones del lado del servidor, invitaciones y restablecimientos, y recuperación del administrador desde la CLI." --- # Autenticación La autenticación en Notarium está integrada y funciona por completo sobre la base de datos de metadatos: sin IdP externo, sin JWT, sin SMTP. El modo se elige con la variable `AUTH_MODE` y determina si existe siquiera un inicio de sesión. ## El modo `password` (por defecto) Seguro por defecto: autenticación multiusuario completa. - **Primer arranque.** En una instancia limpia, el primer visitante crea al propietario desde la pantalla de configuración inicial (administrador del host —host-admin— y propietario de los espacios configurados). No hay contraseña preestablecida; una vez registrada esa cuenta, la configuración inicial se cierra para siempre. - **Sesiones.** Un inicio de sesión crea una **sesión del lado del servidor**: una fila en la base de datos, no un JWT. Vive en la cookie HttpOnly `nt_session`, con un TTL deslizante de 30 días y el flag `Secure` detrás de HTTPS. La revocación es instantánea: deshabilitar un usuario o cambiar una contraseña invalida de inmediato las sesiones activas. - **Hace falta una base de datos de metadatos.** Está ahí por defecto: SQLite bajo `DATA_DIR`, sin nada que configurar. Solo tocas `META_DB_URL` para migrar a un Postgres externo. Consulta [Base de datos](/docs/self-hosting/database/). ## El modo `none` Un único principal con acceso total: el operador activa este modo de forma deliberada, para el escritorio, el desarrollo local o una intranet de confianza. Las rutas de autenticación devuelven `404`, no existe interfaz de inicio de sesión y la autenticación no necesita ninguna base de datos de metadatos. > [!danger] No expongas a la red una instancia en modo `none` > En el modo `none`, cualquiera que pueda alcanzar el puerto obtiene acceso total a todos los datos, incluido el endpoint MCP de los agentes. Úsalo solo en una red aislada o de confianza. ## Roles y acceso El acceso a los datos se concede por membresía en un espacio, y hay tres roles: | Rol | Permisos | |---|---| | `reader` | Lee todo en el espacio. | | `writer` | Edita notas. | | `owner` | Gestiona la membresía. | El flag **host-admin** otorga control sobre usuarios y espacios, pero para **leer los datos** de un espacio concreto sigues necesitando membresía en él. Más sobre el modelo: [Modelo de acceso](/docs/concepts/access-model/). ## Invitaciones y restablecimientos de contraseña Notarium no tiene SMTP: la entrega inicial de una cuenta es un **enlace de un solo uso** que el administrador pasa a mano. Un mecanismo, dos propósitos: - **Invitación**: agrega un usuario sin contraseña; el enlace vive 7 días. - **Restablecimiento de contraseña**: el enlace vive 24 horas; aceptarlo termina las sesiones antiguas. El token viaja en el fragmento de la URL (`/invite#`), así que nunca llega a los registros de acceso. Un usuario tiene un solo enlace de este tipo activo a la vez, y el administrador nunca conoce la contraseña de nadie. ## Tokens para agentes Los agentes de IA se autentican con un token de acceso personal (PAT) de la forma `Authorization: Bearer ntp_…`, con alcance `read` o `write`, opcionalmente acotado a espacios concretos. El secreto se muestra **exactamente una vez**. La emisión de tokens y las demás acciones de gestión solo están disponibles dentro de una sesión: un PAT filtrado no puede escalar privilegios. Detalles: [Conectar un agente](/docs/agents/connect/) y [Seguridad y visibilidad](/docs/agents/security/). ## Recuperar el acceso Como solo el administrador emite un enlace de restablecimiento, perder la contraseña del único administrador significaría perder el acceso. La vía de escape es la **CLI de administración**, que trabaja directamente contra la base de datos de metadatos. Es uno de los comandos integrados de la imagen, así que la llamada es corta y va directa al contenedor en marcha: ```bash docker compose exec notarium admin create-admin --random # para un docker run a secas: docker exec -it notarium admin create-admin --random ``` No hace falta detener el servidor: SQLite en modo WAL tolera un segundo escritor, y Postgres, con mayor razón. La CLI localiza por su cuenta la base de datos de metadatos, con la misma lógica que sigue el servidor (`META_DB_URL`, o la raíz derivada de `DATA_DIR`); ante una ruta equivocada termina con un error en vez de crear en silencio una base de datos vacía en la que «no hay usuarios». Comandos disponibles: | Comando | Acción | |---|---| | `list` | Lista los usuarios. | | `passwd [--password \| --random]` | Cambia una contraseña. | | `create-admin [--random] [--display "Name"]` | Crea un administrador. | | `grant ` | Concede un rol en un espacio. | Sin ningún flag, la contraseña se lee de stdin con el eco suprimido, de modo que nunca llega al historial de comandos. `setPassword`/`createAdmin` solo están disponibles **desde la CLI**: no hay ruta HTTP para ellos; este es el límite del operador del host. Los demás comandos de la imagen se cubren en la página [CLI de la imagen](/docs/self-hosting/cli/).