--- title: "Authentification" description: "Les modes password et none, les sessions côté serveur, les invitations et les réinitialisations, et la récupération de l'accès administrateur via la CLI." --- # Authentification L'authentification de Notarium est intégrée et repose entièrement sur la base de métadonnées — aucun IdP externe, aucun JWT, aucun SMTP. Le mode se choisit avec la variable `AUTH_MODE` et détermine s'il y a une connexion ou non. ## Le mode `password` (par défaut) Sécurisé par défaut : authentification multi-utilisateur complète. - **Premier démarrage.** Sur une instance vierge, le premier visiteur crée le propriétaire via l'écran de configuration initiale (host-admin et propriétaire des espaces configurés). Aucun mot de passe n'est préréglé ; une fois ce compte enregistré, la configuration se ferme définitivement. - **Sessions.** Une connexion crée une **session côté serveur** — une ligne dans la base, pas un JWT. Elle réside dans le cookie HttpOnly `nt_session`, avec un TTL glissant de 30 jours et le drapeau `Secure` derrière HTTPS. La révocation est instantanée : désactiver un utilisateur ou changer un mot de passe supprime aussitôt les sessions actives. - **Une base de métadonnées est nécessaire.** Elle est présente par défaut — SQLite sous `DATA_DIR`, rien à configurer. On ne touche à `META_DB_URL` que pour migrer vers un Postgres externe. Voir [Base de données](/docs/self-hosting/database/). ## Le mode `none` Un unique principal disposant de tous les accès — l'opérateur active ce mode de façon délibérée, pour le poste de travail, le développement local ou un intranet de confiance. Les routes d'authentification renvoient `404`, il n'existe aucune interface de connexion, et aucune base de métadonnées n'est requise pour l'authentification. > [!danger] N'exposez pas une instance `none` sur le réseau > En mode `none`, quiconque peut atteindre le port obtient un accès complet à toutes les données — y compris le point d'accès MCP des agents. Ne l'utilisez que sur un réseau isolé ou de confiance. ## Rôles et accès L'accès aux données est accordé par l'appartenance à un espace, et il existe trois rôles : | Rôle | Permissions | |---|---| | `reader` | Lit tout dans l'espace. | | `writer` | Modifie les notes. | | `owner` | Gère l'appartenance. | Le drapeau **host-admin** confère le contrôle des utilisateurs et des espaces, mais pour **lire les données** d'un espace précis, l'appartenance à celui-ci reste nécessaire. Plus de détails sur le modèle — [Modèle d'accès](/docs/concepts/access-model/). ## Invitations et réinitialisations de mot de passe Notarium n'embarque aucun SMTP — la remise initiale d'un compte passe par un **lien à usage unique** que l'administrateur transmet à la main. Un seul mécanisme, deux usages : - **Invitation** — ajoute un utilisateur sans mot de passe ; le lien reste valide 7 jours. - **Réinitialisation de mot de passe** — le lien reste valide 24 heures ; l'accepter met fin aux anciennes sessions. Le jeton voyage dans le fragment de l'URL (`/invite#`), il n'atterrit donc jamais dans les journaux d'accès. Un utilisateur n'a qu'un seul lien de ce type actif à la fois, et l'administrateur ne connaît jamais le mot de passe de quiconque. ## Jetons pour les agents Les agents IA s'authentifient avec un jeton d'accès personnel (PAT) de la forme `Authorization: Bearer ntp_…`, avec une portée `read` ou `write`, éventuellement restreinte à des espaces précis. Le secret n'est affiché **qu'une seule fois**. L'émission de jetons et les autres actions de gestion ne sont accessibles qu'au sein d'une session — un PAT divulgué ne peut pas élever ses privilèges. Détails — [Connecter un agent](/docs/agents/connect/) et [Sécurité et visibilité](/docs/agents/security/). ## Récupérer l'accès Comme seul l'administrateur émet un lien de réinitialisation, perdre le mot de passe de l'unique administrateur reviendrait à perdre l'accès. La solution est la **CLI d'administration**, qui agit directement sur la base de métadonnées. C'est l'une des commandes intégrées à l'image, l'appel est donc court et s'exécute directement dans le conteneur en cours d'exécution : ```bash docker compose exec notarium admin create-admin --random # pour un simple docker run : docker exec -it notarium admin create-admin --random ``` Nul besoin d'arrêter le serveur : SQLite en mode WAL tolère un second processus en écriture, et Postgres plus encore. La CLI retrouve la base de métadonnées toute seule, selon la même logique que le serveur (`META_DB_URL`, ou la racine dérivée de `DATA_DIR`) ; face à un mauvais chemin, elle s'arrête sur une erreur au lieu de créer en silence une base vide où « il n'y a aucun utilisateur ». Commandes disponibles : | Commande | Action | |---|---| | `list` | Liste les utilisateurs. | | `passwd [--password \| --random]` | Change un mot de passe. | | `create-admin [--random] [--display "Name"]` | Crée un administrateur. | | `grant ` | Octroie un rôle dans un espace. | Sans option, le mot de passe est lu depuis stdin avec l'écho supprimé, il n'atterrit donc jamais dans l'historique des commandes. `setPassword`/`createAdmin` ne sont disponibles **que depuis la CLI** — il n'existe aucun chemin HTTP pour ces opérations : c'est la frontière opérateur de l'hôte. Les autres commandes de l'image sont décrites sur la page [CLI de l'image](/docs/self-hosting/cli/).