Authentifizierung
Ein Bearer-Token beschaffen und die Cockpit-API im Namen eines Mandanten aufrufen.
Bearer-Tokens
Jede Management-API-Anfrage (/api/…) muss ein Bearer-Token enthalten:
Authorization: Bearer <access-token>
Das Token identifiziert den Benutzer, den Mandanten, in dessen Namen er handelt, und die Berechtigungen, die er besitzt. Anfragen ohne gültiges Token erhalten 401 Unauthorized; ein gültiges Token ohne die erforderliche Berechtigung erhält 403 Forbidden.
Ein Token beschaffen
Anmelden
Authentifizieren Sie sich mit den Anmeldedaten des Benutzers (und einem zweiten Faktor, falls aktiviert) über den Cockpit-Anmeldeendpunkt. Bei Erfolg erhalten Sie ein Access-Token und ein Refresh-Token.
Die API aufrufen
Senden Sie das Access-Token im Authorization-Header bei jeder Anfrage.
Erneuern
Wenn das Access-Token bald abläuft, verwenden Sie das Refresh-Token, um ein neues zu erhalten, ohne die Anmeldedaten erneut einzugeben. Die Token-Lebensdauer wird in den Hosteinstellungen konfiguriert.
Verwenden Sie für Machine-to-Machine-Zugriff eine von Ihrem Administrator konfigurierte Dienstidentität anstelle der Anmeldedaten eines menschlichen Benutzers.
Sitzungen und Invalidierung
Tokens sind an eine Sitzung gebunden. Ein Token wird nicht mehr akzeptiert, sobald die Sitzung widerrufen wird, sich das Passwort des Benutzers ändert oder sich der Benutzer abmeldet — sodass ein durchgesickertes Token zentral gekappt werden kann. Access-Tokens sind kurzlebig; Refresh-Tokens sind länger gültig und ebenfalls widerrufbar.
Multi-Faktor und Single Sign-on
Das Cockpit unterstützt mehrere Anmeldemethoden; welche verfügbar sind, hängt von der Konfiguration Ihres Mandanten ab:
| Methode | Hinweise |
|---|---|
| Passwort | Mit konfigurierbarer Passwortrichtlinie |
| TOTP-Zwei-Faktor | Zeitbasierte Einmalpasswörter mit Wiederherstellungscodes |
| WebAuthn / FIDO2 | Passkeys, Sicherheitsschlüssel und Windows Hello |
| Single Sign-on | Azure AD / Entra ID, Okta, Keycloak über Ihren Identitätsanbieter |
Host- vs. Mandanten-Tokens
Die meisten Endpunkte arbeiten innerhalb eines einzelnen Mandanten. Hostbezogene Endpunkte (Mandanten anlegen, plattformweite Einstellungen bearbeiten, Editionen verwalten) erfordern ein im Hostkontext ausgestelltes Token und die entsprechende Host-Berechtigung — siehe Plattformadministration.
Öffentliche Protokollendpunkte
Die öffentlichen Protokollendpunkte verwenden keine Cockpit-Bearer-Tokens. Jeder verwendet die im jeweiligen Standard definierte Authentifizierung — zum Beispiel ein Azure-AD-Token für DKE-Entschlüsselungsanfragen oder ACME-Kontoschlüssel für die ACME-Registrierung.