Authentifizierung im Überblick
Welcher Weg passt zu Ihrer Anwendung? Alle Wege nutzen dieselben Scopes und dasselbe Rechtemodell.
| Anwendungsfall | Verfahren | Wo einrichten |
|---|---|---|
| Skripte, CI/CD, Server-Integrationen, Plugins ohne Benutzeranmeldung | OAuth 2.0 Client Credentials — kurzlebige Tokens | API-Zugang |
| Apps, bei denen sich ein Mensch anmeldet (z. B. Claude, ChatGPT, eigene Web-Apps) | OAuth 2.0 Authorization Code + PKCE mit Einwilligung | OIDC-Integration, MCP verbinden |
| Weboberfläche | Login (Passwort, Passkey, SSO) → Sitzungs-Token | — |
Client Credentials (Server-zu-Server)
- Unter API-Zugang einen Zugang anlegen: Sie erhalten
client_idundclient_secret. - Ihr Dienst holt sich bei Bedarf einen Access-Token:
POST /oauth/tokenmitgrant_type=client_credentials(Client-Daten per HTTP-Basic oder im Body). - Den Token als
Authorization: Bearer …mit jeder Anfrage senden. Läuft er ab (expires_in, Standard 1 Stunde), einen neuen holen.
Optional können Sie mit dem Parameter scope weniger Rechte anfordern als der Zugang besitzt (z. B. scope=scan:read).
Scopes
| Scope | Erlaubt |
|---|---|
scan:read | Scans, Jobs und Domains lesen |
scan:write | Scans starten, KI-Auswertung anstoßen |
report:read | PDF-Berichte abrufen |
code:audit | Code-Audits ausführen und lesen |
monitor:read | Monitoring lesen: Websites, Server, Messwerte, Statusseite, E-Mail-Berichte (DMARC, TLS-RPT) |
monitor:write | Monitoring verwalten: Website-Monitore und Server anlegen/ändern/löschen, Domains der E-Mail-Sicherheit verwalten |
Die Verwaltung Ihres Kontos (Passwort, Team, Abrechnung, Domains anlegen, Zugänge verwalten) ist nur über die Weboberfläche möglich — nie mit einem Access-Token.
Sicherheit
- Das Secret nie in Repositories oder Clients (Browser, Apps) ablegen — nur in Secret-Managern oder Umgebungsvariablen.
- Pro Integration einen eigenen Zugang mit den kleinsten nötigen Scopes anlegen.
- Secret rotieren: im Zugang „Neues Secret“ wählen; das alte Secret ist sofort ungültig.
- Der Token handelt im Namen des Nutzers, der den Zugang angelegt hat. Wird dieser Nutzer deaktiviert oder gelöscht, funktioniert der Zugang nicht mehr.
Fehler
| Antwort | Bedeutung |
|---|---|
400 invalid_scope | Angeforderter Scope ist für den Zugang nicht erlaubt |
400 unauthorized_client | Der Client ist kein API-Zugang (Service-Client) |
401 invalid_client | Client-ID oder Secret falsch |
401 bei API-Aufruf | Token abgelaufen oder ungültig — neuen Token holen |
403 Missing scope | Dem Token fehlt der Scope für diesen Endpunkt |