Token-Lifecycle in der Praxis

Jeder OAuth-Flow-Leitfaden erwähnt refresh_token, aber eine langlaufende Integration (eine, die über viele Anfragen, Worker oder Tage hinweg läuft) braucht mehr als “Token bei Ablauf austauschen”. Diese Seite behandelt reale Token-Laufzeiten, das Cachen eines Tokens über mehrere Worker hinweg, wann aktualisiert werden sollte und was einen Token ungültig machen kann, bevor er sonst ablaufen würde.

---

Token-Laufzeiten je Flow

Die Laufzeit des Access Tokens ist eine feste Dauer, identisch für jeden Flow. Die Laufzeit des Refresh Tokens ist es nicht: sie hängt davon ab, welcher OAuth-Flow ihn ausgestellt hat.

Flow	Access-Token-TTL	Refresh-Token-TTL
Client-Credentials-Flow	Etwa 1 Stunde	Etwa 30 Tage
Native-Anwendungsflow (PKCE, Loopback-Redirect)	Etwa 1 Stunde	Kein festes Ablaufdatum: bleibt gültig, bis er durch Rotation ersetzt oder widerrufen wird
Authorization Code + Custom Redirect Flow	Etwa 1 Stunde	Kein festes Ablaufdatum: bleibt gültig, bis er durch Rotation ersetzt oder widerrufen wird

Hinweis

Beide Authorization-Code-Flows stellen einen Refresh Token ohne jede Sitzungsuhr aus. Er liegt trotzdem nicht endlos ungenutzt herum: Es ist ein Einmal-Token, der bei jeder Aktualisierung ersetzt wird (siehe Race Conditions bei gleichzeitigem Refresh unten), und er funktioniert sofort nicht mehr, wenn die Grant widerrufen wird.

Token cachen statt pro Anfrage neu anfordern

Für jede API-Anfrage oder unabhängig in jedem Worker-Prozess einen neuen Access Token anzufordern, funktioniert, verschwendet aber bei jeder einzelnen Anfrage einen Roundtrip für einen Token, der bereits etwa eine Stunde lang gültig ist. Fordern Sie einen Token an, cachen Sie ihn (im Speicher für einen einzelnen Prozess, oder in einem gemeinsamen Store wie Redis für eine Flotte von Workern), verschlüsselt nach dem Credential, das ihn ausgestellt hat, und geben Sie den gecachten Token an jede Anfrage weiter, bis er kurz vor dem Ablauf steht.

Das gilt auch für den Refresh Token: Je weniger Prozesse ihn unabhängig voneinander austauschen, desto unwahrscheinlicher ist es, dass Sie in die unten beschriebene Race Condition laufen.

Bei Ablauf statt nur bei 401 aktualisieren

Da die Access-Token-TTL fest und im Voraus bekannt ist, aktualisieren Sie proaktiv: merken Sie sich, wann Sie den Token erhalten haben (oder decodieren Sie seinen exp-Claim), und fordern Sie kurz davor einen neuen an, statt zu warten, bis eine Anfrage zuerst fehlschlägt.

Behandeln Sie eine fehlgeschlagene Anfrage trotzdem als Fallback, aber unterscheiden Sie nach dem Fehler:

• 401 mit not_authenticated: die Anfrage enthielt gar keinen brauchbaren Bearer-Token. Das ist ein clientseitiger Fehler (fehlender oder fehlerhafter Authorization-Header), kein Signal zum Aktualisieren.
• 401 mit invalid_token: die Signatur- oder Ablaufprüfung des Tokens ist fehlgeschlagen. Aktualisieren und einmal erneut versuchen.
• 403: nie ein Token-Problem. Der Token ist gültig; dem Aufrufer fehlt der Scope, der Content-Zugriff oder die Rolle, die der Vorgang erfordert. Ein Refresh hilft hier nicht. Die vollständige Aufschlüsselung finden Sie unter Fehlercodes: Ratenbegrenzung, Authentifizierung und Zugriffskontrolle.

Race Conditions bei gleichzeitigem Refresh

Ein Refresh Token ist ein Einmal-Token: Wird er mit grant_type=refresh_token eingelöst, wird genau dieser Refresh Token ungültig, und es werden ein neuer Access Token und ein neuer Refresh Token gemeinsam ausgestellt. Teilen sich mehrere Worker einen gecachten Refresh Token und versuchen zwei davon fast gleichzeitig zu aktualisieren, gelingt nur einer der beiden Austausche; der andere erhält einen generischen 401, keinen unterscheidbaren “bereits verwendet”-Fehler.

Achtung

Lassen Sie nicht jeden Worker unabhängig gegen einen gemeinsam genutzten Refresh Token aktualisieren. Bestimmen Sie einen einzigen Eigentümer für den Refresh-Aufruf (eine Sperre um den Refresh-Pfad oder eine dedizierte Refresh-Routine) und lassen Sie die übrigen Worker den resultierenden Access Token aus dem gemeinsamen Cache lesen, statt selbst zu aktualisieren.

Was einen Token vorzeitig ungültig macht

Keines der folgenden Ereignisse widerruft einen aktiven Access Token direkt. Jedes blockiert nur etwas Neues (eine neue Token-Anfrage oder den nächsten Refresh), während der bereits vorhandene Access Token weiterfunktioniert, bis seine eigene TTL abläuft.

Auslöser	Wirkung
Das Client-Secret der OAuth-Anwendung wird rotiert	Neue Token- oder Refresh-Anfragen mit dem alten Secret werden sofort abgelehnt. Ein bereits ausgestellter Access Token ist davon nicht betroffen und funktioniert weiter, bis er natürlich abläuft.
Die OAuth-Anwendung oder ihr Service-Benutzer wird entfernt	Blockiert das Ausstellen neuer Token für diese Anwendung. Bereits ausgestellte Token werden nicht proaktiv widerrufen.
Die Scopes der OAuth-Anwendung werden geändert	Ein bereits ausgestellter Access Token behält seine ursprünglichen Scopes für den Rest seiner Lebensdauer. Der Token übernimmt die neuen Scopes erst beim nächsten Refresh oder bei erneuter Ausstellung.
Die Grant wird ausdrücklich widerrufen	Blockiert den nächsten Refresh-Versuch sofort. Der weiterhin gültige Access Token wird nicht zwangsweise ungültig und funktioniert weiter, bis er natürlich abläuft.

Hinweis

Das praktische Zeitfenster nach jedem dieser Ereignisse entspricht der eigenen TTL des Access Tokens (etwa einer Stunde), nicht der des Refresh Tokens, da keines von ihnen einen bereits ausgestellten Token berührt. Um dieses Fenster sofort zu schließen, widerrufen Sie die Grant und rotieren Sie das Secret zusammen, und behandeln Sie die Integration dann bis zum Ablauf einer Access-Token-TTL als nicht autorisiert.

Wie geht es weiter?

• Fehlercodes für die vollständige Aufschlüsselung von 401- und 403-Antworten
• Client-Credentials-Flow, Native-Anwendungsflow oder Authorization Code + Custom Redirect Flow, um Ihren ersten Token zu erhalten