API-Token erstellen und verwalten

Token erstellen

1. Mein Konto → API → Tokens
2. Neuer Token
3. Name vergeben (z.B. "Terraform Automation", "Home Server DynDNS")
4. Scopes wählen (was der Token darf)
5. Ablaufdatum (optional aber empfohlen)
6. Erstellen

Nach Erstellen wird der Token einmalig angezeigt — kopiere ihn sofort in Ihren Passwort-Manager. Danach ist er nicht mehr einsehbar.

Scopes

Scopes sind Berechtigungen. Prinzip Least Privilege: Token bekommt nur was er wirklich braucht.

Verfügbare Scopes:

• read:account — Kontoinfo lesen
• read:domains — Domain-Liste lesen
• write:domains — Domains verwalten
• write:dns — DNS-Records ändern
• read:vps — VPS-Liste und Status
• write:vps — VPS steuern (reboot, snapshots)
• read:email — E-Mail-Konfiguration lesen
• write:email — Postfächer verwalten
• read:billing — Rechnungen lesen
• admin — alles (nur wenn wirklich nötig)

Beispiel: Ein Token für DynDNS-Updates braucht nur write:dns, sonst nichts. Wenn er kompromittiert wird, kann Angreifer nur DNS ändern (schlimm genug), aber keine Rechnungen sehen oder VPS rebooten.

Ablaufdatum

Empfehlung: alle Token mit max. 1 Jahr Ablauf. Danach müssen Sie neuen erstellen — das ist die Gelegenheit alte, ungenutzte Tokens auszumisten.

Alternative: Kein Ablauf für Produktiv-Systeme wo Rotation kompliziert ist — dann aber wenigstens jährliche manuelle Prüfung "Nutze ich diesen Token noch?".

Token verwenden

In HTTP-Requests als Header:

Authorization: Bearer wts_pat_a1b2c3d4e5f6...

Token widerrufen

Wenn Sie glauben ein Token wurde kompromittiert:

1. Mein Konto → API → Tokens
2. Den betroffenen Token finden
3. Widerrufen klicken

Token wird sofort ungültig — alle Requests damit werden abgelehnt.

Ersatzlos — kein "vorübergehend deaktivieren", einmal weg = weg.

Token-Historie

Für jeden Token sehen Sie:

• Wann erstellt
• Zuletzt verwendet (Datum + IP)
• Anzahl Requests im letzten Monat
• Aktive/widerrufen

Praktisch um zu erkennen welche Tokens ungenutzt sind (können weg) und welche aktiv (bloß nicht widerrufen ohne vorher zu prüfen).

Sicherheits-Empfehlungen

• Nie in Git committen — Tokens gehören in Umgebungsvariablen oder Secret-Manager (Vault, AWS Secrets, Kubernetes Secrets)
• Nie öffentlich teilen — Support fragt nie nach Tokens
• Nie als URL-Parameter — landen in Logs, sind einsehbar
• Nach Mitarbeiter-Wechsel widerrufen — wenn jemand geht, alle seine Tokens weg

Token pro Anwendung

Statt einem "Master-Token" der alles kann: pro Anwendung ein eigener Token.

Vorteile:

• Bei Kompromittierung nur eine Anwendung betroffen
• Widerruf ohne alle anderen Anwendungen zu brechen
• Nachvollziehbar wer was gemacht hat (in Logs)

Personal Access Tokens vs OAuth-Apps

Personal Access Token (PAT) — für persönliche Skripte, Server, CI/CD.

OAuth-App — für Third-Party-Anwendungen die Ihnen Zugriff bitten (nutzen Standard-OAuth-Flow, kein Token-Teilen nötig).

Details: siehe API-Dokumentation.