Was gilt es zur Token-Sicherheit zu beachten?

Ab Tarif Basic

Kurzantwort

Behandle einen API-Token wie ein Passwort: Er gewährt jedem, der ihn kennt, Zugriff mit deinen Rechten. Die wichtigsten Regeln: minimale Scopes (read, wenn Schreiben nicht nötig ist), Ablaufdatum setzen, je Einsatzzweck ein eigener Token, Ablage nur im Secret-Store (nie im Code oder Git) sowie nicht mehr Gebrauchte sofort widerrufen.

Voraussetzungen

Least Privilege per Scope. Wähle beim Erstellen nur read, wenn die Integration lediglich liest (Reports, Exporte, Monitoring). write nur für Werkzeuge, die wirklich Daten ändern. Bedenke: Ohne Scope-Auswahl gilt der volle Zugriff deiner Rolle.
Ablaufdatum setzen. Gib jedem Token ein Enddatum, besonders für Tests und einmalige Migrationen. Ein vergessener Token läuft dann von selbst aus.
Ein Token pro Zweck. „CI-Pipeline”, „Grafana-Export”, „Asset-Import”: Getrennte Tokens lassen sich gezielt widerrufen, ohne andere Integrationen zu brechen, und die Spalte Zuletzt genutzt bleibt aussagekräftig.
Sicher aufbewahren. Der Wert erscheint nur einmal. Ablage ausschließlich im Passwort-Manager bzw. Secret-Management (GitHub/GitLab Secrets, Vault, .env außerhalb des Repos). Niemals in Code, Tickets, Chats oder Logs.
Regelmäßig aufräumen und rotieren. Prüfe die Liste periodisch: Tokens ohne aktuelles Zuletzt genutzt widerrufen; langlebige Tokens turnusmäßig ersetzen (neu erstellen → Integration umstellen → alten widerrufen).

Sicherheitsrelevante Muster für die Praxis:

curl -X POST https://demo.notory.io/api/v1/api-tokens \
  -H "Authorization: Bearer inv_bestehender_token" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Grafana (read-only)", "scopes": "read", "expires_at": "2026-12-31T23:59:59Z" }'

curl -H "Authorization: Bearer inv_dein_token" \
  https://demo.notory.io/api/v1/api-tokens
# → prüfe "last_used_at" und "expires_at" je Eintrag

Ein read-Token, der schreiben will, erhält deterministisch:

{ "detail": "API token scope does not permit this operation" }

Merke: Der Token gehört in den Authorization-Header, nie in die URL (URLs landen in Server- und Proxy-Logs).

Was passiert dabei?

So schützt Notory Tokens serverseitig, und wo du trotzdem gefragt bist:

Nur der Hash wird gespeichert. Serverseitig liegt ausschließlich der SHA-256-Hash; ein Datenbank-Leak verrät die Token-Werte nicht. Kehrseite: Auch Notory kann den Wert nie wieder anzeigen. Der Schutz deiner Kopie liegt bei dir.
Scope-Durchsetzung bei jeder Anfrage. read → nur GET/HEAD/OPTIONS; write → zusätzlich ändernde Methoden. Geprüft wird vor der eigentlichen Aktion, zusätzlich zu Rolle/Berechtigungen deines Kontos und der Mandanten-Isolation (RLS).
Sofortige Entwertung. Widerruf löscht den Token; Ablaufdatum und Konto-Deaktivierung wirken bei der nächsten Anfrage (401). Es gibt keine Karenzzeit.
Nutzungsspur. last_used_at wird bei jeder Verwendung aktualisiert: deine Grundlage für Aufräum-Runden. Die API-Zugriffe unterliegen außerdem dem regulären Protokoll und dem Rate-Limiting der Instanz.
Kein Rechte-Ausbruch möglich. Ein Token kann nie mehr als sein Besitzer: Rolle, eigene Rollen und Mandant des Kontos begrenzen jeden Aufruf. Für risikoarme Integrationen lohnt daher ein dediziertes Konto mit schmaler Rolle (z. B. Betrachter) als Token-Besitzer.