---
title: "Authentifizierung"
description: "Die Modi password und none, serverseitige Sessions, Einladungen und Zurücksetzungen sowie die Admin-Wiederherstellung über die CLI."
---

# Authentifizierung

Die Authentifizierung in Notarium ist eingebaut und läuft vollständig über die Metadaten-Datenbank — kein externer IdP, kein JWT, kein SMTP. Der Modus wird über die Variable `AUTH_MODE` gewählt und entscheidet, ob es überhaupt einen Login gibt.

## Der `password`-Modus (Standard)

Standardmäßig sicher: vollwertige Mehrbenutzer-Authentifizierung.

- **Erster Start.** Auf einer sauberen Instanz legt der erste Besucher über den Setup-Bildschirm beim ersten Start den Eigentümer an (Host-Admin und zugleich Eigentümer der konfigurierten Spaces). Ein voreingestelltes Passwort gibt es nicht; sobald dieses Konto registriert ist, schließt sich das Setup für immer.
- **Sessions.** Ein Login erzeugt eine **serverseitige Session** — eine Zeile in der Datenbank, kein JWT. Sie lebt im HttpOnly-Cookie `nt_session` mit einer gleitenden TTL von 30 Tagen und dem `Secure`-Flag hinter HTTPS. Der Entzug erfolgt sofort: Wird ein Benutzer deaktiviert oder ein Passwort geändert, werden aktive Sessions umgehend beendet.
- **Eine Metadaten-Datenbank ist erforderlich.** Sie ist standardmäßig vorhanden — SQLite unter `DATA_DIR`, ohne Konfigurationsaufwand. `META_DB_URL` fasst du nur an, um auf ein externes Postgres umzuziehen. Siehe [Datenbank](/docs/self-hosting/database/).

## Der `none`-Modus

Ein einziger Principal mit Vollzugriff — der Betreiber aktiviert diesen Modus bewusst, für den Desktop, die lokale Entwicklung oder ein vertrauenswürdiges Intranet. Auth-Routen antworten mit `404`, es gibt keine Login-Oberfläche, und für die Authentifizierung wird keine Metadaten-Datenbank benötigt.

> [!danger] Eine `none`-Instanz nicht ins Netz stellen
> Im `none`-Modus erhält jeder, der den Port erreicht, vollen Zugriff auf alle Daten — einschließlich des MCP-Endpunkts der Agenten. Nutze ihn nur in einem isolierten oder vertrauenswürdigen Netz.

## Rollen und Zugriff

Der Zugriff auf Daten wird über die Space-Mitgliedschaft gewährt, und es gibt drei Rollen:

| Rolle | Berechtigungen |
|---|---|
| `reader` | Liest alles im Space. |
| `writer` | Bearbeitet Notizen. |
| `owner` | Verwaltet die Mitgliedschaft. |

Das **Host-Admin**-Flag gewährt Kontrolle über Benutzer und Spaces, doch um die **Daten** eines bestimmten Spaces zu **lesen**, brauchst du trotzdem eine Mitgliedschaft darin. Mehr zum Modell — [Zugriffsmodell](/docs/concepts/access-model/).

## Einladungen und Passwort-Zurücksetzung

SMTP gibt es in Notarium nicht — die erstmalige Übergabe eines Kontos erfolgt über einen **Einmal-Link**, den der Administrator von Hand weiterreicht. Ein Mechanismus, zwei Zwecke:

- **Einladung** — fügt einen Benutzer ohne Passwort hinzu; der Link ist 7 Tage gültig.
- **Passwort-Zurücksetzung** — der Link ist 24 Stunden gültig; beim Einlösen werden alte Sessions beendet.

Das Token wird im URL-Fragment übertragen (`/invite#<token>`) und landet daher nie in den Zugriffsprotokollen. Pro Benutzer ist jeweils nur ein solcher Link aktiv, und der Administrator kennt niemals das Passwort eines anderen.

## Tokens für Agenten

KI-Agenten authentifizieren sich mit einem Personal Access Token (PAT) der Form `Authorization: Bearer ntp_…`, mit dem Scope `read` oder `write` und optional auf bestimmte Spaces eingeschränkt. Das Geheimnis wird **genau einmal** angezeigt. Das Ausstellen von Tokens und andere Verwaltungsaktionen sind nur innerhalb einer Session möglich — ein geleaktes PAT kann keine Rechte ausweiten. Details — [Agent verbinden](/docs/agents/connect/) und [Sicherheit und Sichtbarkeit](/docs/agents/security/).

## Zugriff wiederherstellen

Da nur der Administrator einen Reset-Link ausstellt, hätte ein verlorenes Passwort des einzigen Admins den Verlust des Zugriffs zur Folge. Der Ausweg ist die **Admin-CLI**, die direkt auf der Metadaten-Datenbank arbeitet. Sie ist einer der eingebauten Befehle des Images und lässt sich deshalb kurz und direkt im laufenden Container aufrufen:

```bash
docker compose exec notarium admin create-admin <user> --random

# für ein reines docker run:
docker exec -it notarium admin create-admin <user> --random
```

Den Server musst du dafür nicht anhalten: SQLite im WAL-Modus verträgt einen zweiten Schreiber, Postgres erst recht. Die Metadaten-Datenbank findet die CLI von allein — nach derselben Logik wie der Server (`META_DB_URL` oder das aus `DATA_DIR` abgeleitete Datenverzeichnis); bei einem falschen Pfad bricht sie mit einem Fehler ab, statt stillschweigend eine leere Datenbank anzulegen, in der es dann „keine Benutzer“ gibt.

Verfügbare Befehle:

| Befehl | Aktion |
|---|---|
| `list` | Listet Benutzer auf. |
| `passwd <user> [--password <pw> \| --random]` | Ändert ein Passwort. |
| `create-admin <user> [--random] [--display "Name"]` | Erstellt einen Administrator. |
| `grant <user> <space> <owner\|writer\|reader>` | Gewährt eine Rolle in einem Space. |

Ohne Flag wird das Passwort mit unterdrücktem Echo aus stdin gelesen, damit es nicht in die Befehlshistorie gerät. `setPassword`/`createAdmin` sind **nur über die CLI** verfügbar — einen HTTP-Weg gibt es dafür nicht: das ist die Betreibergrenze des Hosts. Die übrigen Befehle des Images findest du auf der Seite [Image-CLI](/docs/self-hosting/cli/).