Sicherheitsmodell

Scope-gesteuert. Auditiert. Sicher.

Jeder Zugriff — ob via REST API oder MCP — läuft durch dieselbe Scope-Prüfung. Kein Scope, kein Zugriff. Jede Aktion landet im Audit-Log.

API-KeyBearer TokenScope-gesteuertAudit-Log403 on mismatch

Authentifizierung

REST APIZugriff über Bearer-basierte Authentifizierung. Der API-Key wird als Authorization: Bearer <key> Header mitgeschickt. Jede Route ist einem Modul zugeordnet und prüft den passenden Scope.

MCPDer API-Key wird über den jeweiligen Transport oder MCP-Client übergeben. Jedes Tool hat feste Modul-Scopes und wird nur ausgeführt, wenn der Key den passenden Scope trägt.

OAuth-MCP-Clients erhalten bei jedem Authorization-Code-Austausch einen kurzlebigen access_token (Standard 30 Minuten) und einen rotierenden refresh_token (Standard 30 Tage). Der Refresh-Token rotiert bei jeder Nutzung; ein bereits verbrauchter Token, der erneut vorgelegt wird, widerruft die gesamte Token-Familie. Eine Ausweitung der Scopes beim Refresh wird abgelehnt.

Clients, die ein Client ID Metadata Document (CIMD) veröffentlichen, können die HTTPS-URL des Dokuments als client_id übergeben, anstatt sich per Dynamic Client Registration zu registrieren. LedgerLou lädt das Dokument einmalig (5 s Timeout, 256 KiB Limit, SSRF-geschützt, Zod-validiert), cached es 24 h und unterstützt ETag-basiertes Conditional-Fetch. Der admin-Superscope und config:*-Scopes werden CIMD-Clients nicht gewährt — der scope-String des Dokuments wird mit den per OAuth verfügbaren Modul-Scopes geschnitten.

Scopes

Scopes folgen dem Format modul:aktion. Ein Key trägt nur die Scopes, die er explizit benötigt — kein Default-Zugriff auf alles.

	`journal`	`bank`	`kreditoren`	`perioden`	`auswertungen`	`config`
`:read`	✓	✓	✓	✓	✓	✓
`:write`	✓	✓	✓	✓	—	✓
`admin`	Globaler Superscope — umfasst alle Modul-/Aktionskombinationen

✓ nur via REST API und Dashboard — config:* ist über MCP nicht verfügbar.

Empfehlungen für den Betrieb

Ein Key pro IntegrationVerwende pro Integration einen eigenen Schlüssel mit minimal notwendigen Scopes. So lässt sich jede Integration gezielt sperren, ohne andere zu beeinflussen.

Schlüssel regelmäßig rotierenRotiere Keys in regelmäßigen Abständen. Kompromittierte oder nicht mehr benötigte Keys sofort deaktivieren.

Keine Scope-InflationWenn eine Integration mehr Rechte benötigt, neuen Key ausstellen — nicht bestehende Scopes aufblähen. Minimalprinzip konsequent einhalten.

Audit-Log auswertenJede Aktion wird mit Key-ID, Zeitstempel und Scope dokumentiert. Unerwartete Zugriffsmuster im Log erkennen und reagieren.

Weiterführend

Schnellstart Erste Integration in wenigen Schritten — API-Key, Request, fertig. REST Endpoints Welche Route welchen Scope benötigt — vollständige Referenz. MCP Setup Öffentlicher Überblick zum MCP-Zugang und Scope-Modell.