Umgang mit Zugangsdaten

Den ersten Token zu erhalten ist erst der Anfang. Sobald eine OAuth-Anwendung produktiv läuft, müssen ihre Zugangsdaten sicher gespeichert, gelegentlich rotiert und bei Problemen schnell widerrufen werden können. Das sind genau die Fragen, die ein Sicherheits-Review stellt. Diese Seite behandelt alle drei Punkte, dazu, was ein geleakter Token tatsächlich erreichen kann und was bei einem Leak zu tun ist.

Wo ein Client Secret hingehört

Speichern Sie es in einer Umgebungsvariable oder einem Secrets Manager (AWS Secrets Manager, Vault o. Ä.), niemals in der Versionskontrolle und niemals in einer Konfigurationsdatei, die zusammen mit Ihrem Code committet wird.
Verwenden Sie es niemals in einer Desktop-Anwendung oder einem browserbasierten Client. Alles, was auf dem Rechner eines Benutzers installiert ist oder an einen Browser ausgeliefert wird, kann in seinem Bundle inspiziert werden: ein darin eingebettetes Secret muss ab dem Moment der Auslieferung als öffentlich gelten.
Genau deshalb vergibt der Native-Application-Flow überhaupt kein Client Secret: er ist für Desktop- und CLI-Integrationen gedacht, die keine Möglichkeit haben, eines vertraulich zu halten, und setzt stattdessen auf PKCE (einen Nachweis pro Anfrage, der an den Autorisierungscode gebunden ist). Der Authorization-Code-Flow mit benutzerdefinierter HTTPS-Redirect-URI verwendet ebenfalls PKCE und erlaubt ein Client Secret nur für vertrauliche Clients, deren Redirect-Handler auf einem Server läuft, den Sie kontrollieren. Eine reine Browser-Implementierung (SPA) dieses Flows sollte auf das Secret verzichten, aus demselben Grund, aus dem der Native-Flow nie eines hat. Siehe Erste Schritte: OAuth-Flow auswählen.
Client Credentials ist ein Server-zu-Server-Flow und erfordert immer ein Secret: speichern Sie es nach denselben Regeln wie jede andere serverseitige Zugangsdaten.

Ein Client Secret ohne Ausfallzeit rotieren

Wenn Sie unter Settings → OAuth an Ihrer Anwendung ein Secret neu generieren, wird es vollständig ersetzt. Es gibt kein Fenster mit zwei gleichzeitig gültigen Secrets: ein Aufrufer, der noch das alte Secret verwendet, wird ab der nächsten Token- oder Refresh-Anfrage abgewiesen.

Das heißt aber nicht, dass jede laufende Anfrage sofort beim Rotieren fehlschlägt. Ein bereits ausgestellter Access Token funktioniert weiter, bis seine eigene TTL abläuft (etwa eine Stunde, siehe Token-Lebenszyklus), unabhängig davon, was anschließend mit dem Secret passiert, mit dem er ursprünglich ausgestellt wurde. Nur eine neue Token-Anfrage oder ein Refresh benötigt das neue Secret.

Empfohlene Umstellungsreihenfolge:

Secret neu generieren.
Im selben Zug jede Stelle aktualisieren, an der Ihre Integration das Secret speichert (Konfiguration, Secrets Manager, jede Instanz oder jeder Worker), bevor eine davon als Nächstes einen Token anfordern oder erneuern muss.
Bestätigen, dass neue Token-Anfragen mit dem neuen Secret erfolgreich sind.

Wenn Sie nicht jede Instanz atomar aktualisieren können, planen Sie die Rotation als koordiniertes Deployment statt als schrittweisen Rollout: Eine Instanz, die noch das alte Secret hat, schlägt beim nächsten Token-Bedarf vollständig fehl, statt elegant zurückzufallen.

Zugriff widerrufen

Es gibt zwei Möglichkeiten, den Zugriff zu entziehen, und beide stoppen neuen Zugriff:

Eine einzelne Autorisierung widerrufen unter Settings → Third-party access. Dadurch kann die Anwendung über diese Autorisierung keine Token mehr erneuern oder erhalten, ohne die Anwendung für andere Benutzer zu beeinträchtigen.
Die OAuth-Anwendung löschen unter Settings → OAuth. Damit wird sie für alle widerrufen: Für diese Anwendung können keine weiteren Access- oder Refresh-Token mehr ausgestellt werden, und ihr Client Secret funktioniert nicht mehr, genau wie bei einer Rotation. Bei einer Anwendung, die Client Credentials verwendet, wird dabei im selben Vorgang auch ihr Service-Benutzer deaktiviert.

Das Widerrufen einer Autorisierung, das Löschen der Anwendung und das Rotieren ihres Secrets lassen einen bereits ausgestellten Access Token unberührt: Keine dieser Aktionen lässt ihn zwangsweise ablaufen. Behandeln Sie diesen Token als nutzbar, mit seinen ursprünglichen Scopes, bis seine eigene TTL abläuft. Siehe Token-Lebenszyklus für die vollständige Übersicht, was einen aktiven Token beeinflusst und was nicht.

Was ein geleakter Token erreichen kann

Ein geleakter Token ist kein Leak Ihrer gesamten Organisation: er ist doppelt begrenzt, passend zum dreistufigen Sicherheitsmodell:

Seine OAuth-Scopes (Ebene 1): bei der Ausstellung fest im Token verankert. Ein später von der Anwendung entfernter Scope verkleinert einen bereits ausgestellten Token nicht; das wirkt sich erst beim nächsten Refresh oder bei der Neuausstellung aus.
Inhaltszugriff und Rolle des Service-Benutzers (Ebenen 2 und 3): welche Knoten (Organisationen, Divisionen, Sites) der Service-Benutzer des Tokens sehen kann und was er dort tun darf. Anders als bei Scopes ist das nicht im Token verankert: Es wird bei jeder Anfrage anhand Ihrer aktuellen Konfiguration geprüft.

Die praktische Konsequenz: Je enger Sie die Anwendung und ihren Service-Benutzer von Anfang an einschränken, desto weniger ist ein geleakter Token wert.

Nach einem vermuteten Leak

Arbeiten Sie das der Reihe nach ab:

Client Secret sofort rotieren (Settings → OAuth → Ihre Anwendung). Das ist das Schnellste, was Sie tun können, und stoppt sofort jede neue Token- oder Refresh-Anfrage mit dem alten Secret.
OAuth-Anwendung löschen, wenn Sie sie nicht weiterverwenden wollen oder vermuten, dass die Kompromittierung über ein Secret hinausgeht. Bei einer Client-Credentials-Anwendung deaktiviert das auch den Service-Benutzer und unterbindet die Ausstellung neuer Token vollständig.
Inhaltszugriff des Service-Benutzers einschränken oder entziehen. Da Inhalts- und Rollenzugriff (Ebenen 2–3) live geprüft und nicht im Token verankert wird, verkleinert das sofort, was ein noch gültiger geleakter Token erreichen kann, noch bevor dessen TTL abläuft.
Den Token für ein weiteres TTL-Fenster als aktiv behandeln (etwa eine Stunde). Keiner der obigen Schritte lässt einen bereits ausgestellten Token zwangsweise ablaufen.
Neue Zugangsdaten ausstellen (ein neues Secret oder eine neue Anwendung) und Ihre Integration aktualisieren, bevor Sie den Normalbetrieb wiederaufnehmen.

Wie geht es weiter?

Token-Lebenszyklus für TTLs, Caching und Refresh-Verhalten
Erste Schritte: Sicherheitsmodell dafür, wie Scopes, Inhaltszugriff und Rollen zusammenspielen