OAuth für Service-Accounts

Nur aktuelle Workspace-Owner verwalten OAuth-Clients für aktive Service-Accounts. Der Client gehört dem Team, nicht dem Ersteller. Secrets werden einmal angezeigt; bei Verlust rotieren. Rotation entzieht bisherige Access-Tokens. Der Service-Account benötigt weiterhin aktuelle Rolle und Scopes.

Öffne Maschinen und Tokens im Workspace. Lege zuerst einen aktiven Service-Account an und registriere danach einen OAuth-Server-Client mit den benötigten Scopes und optionaler IP-Liste. Sichere das Secret aus der einmaligen Anzeige und blende es danach aus. Ein Seitenneuladen stellt es nicht wieder her. Ein wiederholter Erstellungsaufruf liefert kein Secret; rotiere es bei Verlust.

Verwende am Token-Endpunkt grant_type=client_credentials, Client-ID und Secret. Das Secret bleibt auf deinem Server. Rotation ersetzt es und entzieht bisherige Zugriffstokens. Widerrufen deaktiviert den Client endgültig. Diese Aktionen stehen nur aktuellen Ownern zu; der Service-Account verwaltet sich nicht selbst.

Server-Clients können sich mit HTTP Basic anmelden: Client-ID und Secret separat form-URL-kodieren, mit : verbinden und Base64-kodieren. Alternativ beide im Formular senden; Methoden nicht kombinieren. Das Token-Limit ist von Login und anderen Clients desselben Hosts getrennt.

Eine Tokenfamilie endet spätestens 30 Tage nach dem ersten Codetausch; Rotation verlängert diese Frist nicht. Danach ist eine erneute Zustimmung nötig. Beim Upgrade auf diese Laufzeitregel werden bestehende Refresh-Familien einmalig widerrufen; betroffene Anwendungen müssen neu autorisiert werden. SA-Client-Credentials bleiben davon unberührt.

Abgelaufene Zugangsdaten haben eine operative Schonfrist von mindestens 24 Stunden, ohne dadurch länger gültig zu sein. Referenzen aus Zustellungen, Webhooks, Buchungsseiten oder Automation können die technische Aufbewahrung verlängern; die Bereinigung läuft begrenzt im Hintergrund. Deine Zustimmungshistorie bleibt erhalten.

Bildbeispiele