Abgelaufene API-Tokens: Regeln für die Wiederherstellung bei lang laufenden Agentenjobs

Lang laufende Agentenaufgaben scheitern auf besonders dumme Weise, wenn niemand für den Ablauf eines Tokens zuständig ist. Der Agent sieht einen 401-Fehler, wiederholt denselben Aufruf, verbraucht sein Rate-Limit-Budget und macht aus einer unsicheren Schreiboperation manchmal mehrere. Das ist keine bloße Authentifizierungsstörung. Es ist ein Fehler im Wiederherstellungsdesign.

Plane den Ablauf als erwarteten Zustandswechsel ein. Übertrage die Erneuerung einer Komponente, klassifiziere Fehler vor dem Handeln, begrenze Wiederholungen passend zur Bedeutung der Operation und hinterlasse einen Nachweis, aus dem ein Operator erkennen kann, ob die Gegenseite die Arbeit bereits angenommen hat. Ein Agent sollte nie raten müssen, ob er Zugangsdaten ausstellen darf oder ob es sicher ist, eine Schreiboperation erneut zu senden.

Ablauf ist ein Zustandswechsel, kein außergewöhnlicher Ausfall

Ein abgelaufenes API-Token sagt dir, dass die Autorisierung für ein kurzlebiges Zugangsmittel beendet ist. Es sagt nicht, dass die Aufgabe fehlgeschlagen ist. Ein lang laufender Job kann zehn entfernte Operationen abgeschlossen haben, bevor der nächste Aufruf auf den Ablauf trifft. Der Wiederherstellungscode muss diesen Unterschied bewahren.

Teams fassen oft vier verschiedene Ereignisse in einem Zweig namens auth_failed zusammen. Diese Abkürzung führt zu schlechtem Verhalten, weil jedes Ereignis eine andere Reaktion braucht:

• Ablauf bedeutet, dass die Gültigkeitsdauer des Tokens endete und der berechtigte Erneuerungsbesitzer ein neues Access-Token anfordern darf.
• Widerruf bedeutet, dass ein Benutzer, Administrator oder Anbieter die Freigabe zurückgezogen hat. Eine Erneuerung kann absichtlich scheitern.
• Eine ungültige Anfrageauthentifizierung kann auf einen fehlerhaften Header, den falschen Zugangsdaten-Typ, einen nicht passenden Issuer oder eine falsche Audience hindeuten.
• Fehlende Berechtigungen bedeuten, dass die Identität weiterhin gültig ist, diese Operation aber nicht ausführen darf.

OAuth benennt diese Unterschiede aus gutem Grund. RFC 6750 definiert den Bearer-Token-Fehler invalid_token und besagt, dass ein Resource Server bei einem abgelaufenen, widerrufenen, fehlerhaften oder anderweitig ungültigen Token mit 401 und einer WWW-Authenticate-Challenge antwortet. Das ist nützliche Protokollorientierung, gibt deinem Client aber nicht die Erlaubnis, blind zu erneuern. Der Resource Server meldet lediglich, dass er diese Anfrage abgelehnt hat.

Ein Job hat außerdem zwei Zeitachsen. Seine Arbeitszeitachse hält fest, was er entdeckt, berechnet, erstellt und bestätigt hat. Seine Autorisierungszeitachse hält die Zugangsdaten-Generation fest, mit der er handeln konnte. Läuft ein Token ab, bewahre die Arbeitszeitachse und setze die Autorisierungszeitachse auf renewing oder blocked. Setze nicht den gesamten Job zurück und nenne das Wiederherstellung.

Dieser Unterschied ist bei Agenten besonders wichtig, weil sie Ketten voneinander abhängiger Aufrufe ausführen. Angenommen, ein Agent erstellt einen Änderungsantrag, lädt ein Artefakt hoch und verliert den Zugriff, bevor er das Artefakt anhängen kann. Ein Neustart ab der ersten Anweisung kann einen zweiten Änderungsantrag erzeugen. Ein dauerhafter Checkpoint nach jedem bestätigten entfernten Effekt lässt den Agenten mit dem fehlenden Anhängen fortfahren, statt den gesamten Plan erneut abzuspielen.

Verwende explizite Zustände statt eines booleschen Werts wie authenticated:

ready -\u003e executing -\u003e authorization_expired -\u003e renewal_in_progress
renewal_in_progress -\u003e executing
renewal_in_progress -\u003e authorization_blocked
executing -\u003e outcome_unknown
outcome_unknown -\u003e reconciled -\u003e executing

outcome_unknown verdient einen eigenen Zustand. Eine Verbindung kann abbrechen, nachdem der Dienst eine Schreiboperation verbucht hat, aber bevor der Aufrufer die Antwort erhält. Eine Token-Erneuerung löst diese Unsicherheit nicht. Der Job muss anhand seiner Operations-ID, seines Idempotenz-Tokens oder einer anbieterspezifischen Suche prüfen, was passiert ist, bevor er die Schreiboperation erneut versucht.

Eine Komponente muss die Erneuerung besitzen

Der Client, der das Refresh-Token hält, sollte Access-Tokens erneuern. Der Agent sollte stattdessen eine Aktion anfordern und keine erneuerbaren Zugangsdaten erhalten. Diese Regel klingt restriktiv, bis zwei Agenten gleichzeitig auf einen Ablauf stoßen.

Wenn jeder Worker eine Kopie des Refresh-Tokens besitzt, kann jeder Worker unabhängig erneuern. Sie konkurrieren miteinander, erzeugen eine Spur voller unzusammenhängender Zugangsdatenereignisse, und eine Rotation von Refresh-Tokens kann ein Token ungültig machen, das ein anderer Worker noch hält. Vor allem wird jeder Prozess, der eine Aufgabe lesen kann, zu einem langlebigen Identitätsträger.

Setze einen Credential-Broker oder ein Action-Gateway zwischen die Agenten und den Anbieter. Der Broker verwahrt das Refresh- oder Service-Token, holt kurzlebige Access-Tokens, fügt eines erst bei der Ausführung einer Anfrage ein und gibt die Antwort zurück. Der Agent erhält weder ein Access-Token noch ein Refresh-Token.

Damit hat jeder Beteiligte eine klare Aufgabe:

• Der Agent entscheidet, welche erlaubte Operation er ausführen möchte, und liefert die Eingaben.
• Das Gateway prüft, ob die Sitzung die Anfrage stellen darf, wählt die Referenz der Zugangsdaten und führt den Aufruf aus.
• Der Erneuerungsbesitzer erneuert einmal, wenn der Anbieter einen klassifizierten Ablauf meldet.
• Ein Operator kümmert sich um eine widerrufene Freigabe, eine neue Einwilligung oder Zugangsdaten, die menschliche Beteiligung erfordern.

Mache den Agenten nicht zum Erneuerungsbesitzer, nur weil er einen OAuth-Endpunkt aufrufen kann. Fähigkeit und Zuständigkeit sind verschiedene Dinge. Ein Agent, der einen Kalendereintrag anfordern oder ein Artefakt bereitstellen darf, braucht nicht automatisch die Erlaubnis, die Identität einer Person oder eines Dienstes zu verlängern.

RFC 6749 beschreibt Refresh-Tokens als Zugangsdaten, die dem Client ausgestellt und zum Erhalt neuer Access-Tokens verwendet werden. Lies «Client» in deiner Architektur wörtlich. Wenn dein Agent nicht der registrierte Client ist, sollte er nicht dessen Refresh-Token erben, nur weil er die API-Anfrage erzeugt.

Es gibt legitime Fälle, in denen ein Job selbst für die Erneuerung zuständig ist. Ein eng begrenzter Maschinen-Workload mit eigenem registriertem Client, eigener Speichergrenze und ohne Delegation durch Menschen kann das übernehmen. Auch dann sollte ein Erneuerungskoordinator alle parallelen Operationen dieser Identität bedienen. Verwende einen Mutex oder einen Single-Flight-Mechanismus, der nach der Zugangsdatenreferenz verschlüsselt ist. Der erste fehlschlagende Aufruf erneuert, die anderen warten auf das Ergebnis, statt den Token-Endpunkt zu überrennen.

Ein einfacher Zuständigkeitsdatensatz verhindert vage Designs:

{
  "credential_ref": "billing-write-prod",
  "renewal_owner": "action-gateway",
  "access_token_lifetime": "provider-defined",
  "refresh_allowed": true,
  "reauthorization_owner": "on-call-operator",
  "concurrent_refresh": "single-flight"
}

Der Datensatz enthält eine Referenz, niemals die Zugangsdaten selbst. Er benennt außerdem, wer handeln muss, wenn die Erneuerung nicht mehr funktioniert. Wenn niemand diese Frage vor dem Deployment beantworten kann, wird der Job sie nachts schlecht beantworten.

Ein 401 braucht Belege, bevor er eine Erneuerung auslöst

Erneuere nur, wenn Antwort und Zugangsdaten-Datensatz die Diagnose «abgelaufen» stützen. Jeden 401 als Ablauf zu behandeln, verdeckt Konfigurationsfehler und kann eine lange Kette sinnloser Erneuerungsversuche erzeugen.

Beginne mit dem dokumentierten Fehlertext, den Headern und den Erwartungen des Anbieters an das Tokenformat. Manche APIs liefern OAuth-kompatible WWW-Authenticate-Werte. Andere verwenden JSON-Fehlercodes. Manche verstecken Authentifizierungsfehler hinter einem Gateway mit einem anderen Statuscode. Dein Klassifizierer sollte die dokumentierten Signale des jeweiligen Anbieters verwenden und andernfalls auf einen sicheren terminalen Fehler zurückfallen.

Dies ist ein brauchbarer Klassifizierungsvertrag:

{
  "http_status": 401,
  "provider_code": "invalid_token",
  "www_authenticate": "Bearer error=\"invalid_token\"",
  "credential_ref": "reports-read",
  "token_generation": 17,
  "decision": "renew_once"
}

Eine Antwort darf nur dann renew_once ergeben, wenn alle folgenden Bedingungen erfüllt sind: Die Anfrage verwendete Zugangsdaten, die dein Gateway ausgestellt oder ausgewählt hat; für diese Zugangsdaten gibt es einen Erneuerungsweg; das Signal des Anbieters passt zum dokumentierten Ablauf- oder Invalid-Token-Zustand; und dieser Job hat Generation 17 noch nicht erneuert.

Verwende für jede Fehlerklasse ein anderes Ergebnis. Ein fehlerhafter Header gehört zu configuration_error, damit ein Entwickler den Anfrageaufbau prüfen kann. Eine nicht passende Audience gehört zu credential_binding_error, weil jemand die Token-Anfrage oder die Ressourcenkonfiguration korrigieren muss. Eine widerrufene Freigabe gehört zu reauthorization_required: Das System stoppt externe Aktionen und teilt dem richtigen Operator mit, welche Identität eine Einwilligung benötigt. Ein 403 gehört zu permission_denied; ihn zu erneuern wäre Cargo-Kult-Verhalten.

Uhrprobleme verursachen überraschend viele Fehldiagnosen. Ein Client, der den Ablauf lokal berechnet, kann ein brauchbares Token zu früh ablehnen, während ein Client mit einer driftenden Uhr ein abgelaufenes Token sendet. Speichere die vom Aussteller gelieferte Ablaufzeit beim Empfang des Tokens, halte einen kleinen Sicherheitspuffer ein und verwende eine vertrauenswürdige Systemuhr. Lass nicht jeden Agenten den Ablauf aus einem dekodierten Token-Claim selbst berechnen. Das vervielfacht Protokolllogik und lädt zu unterschiedlichen Ergebnissen ein.

Prüfe einen Token-Payload nicht bloß, um zu entscheiden, ob du ihm vertrauen kannst. Ein JSON Web Token kann einen exp-Claim enthalten, aber das Dekodieren seiner Base64url-Nutzlast prüft weder Signatur noch Aussteller, Audience oder Widerrufsstatus. Verwende sie nur als Hinweis, nachdem die Komponente, die das Token empfangen hat, die dokumentierte Validierung des Anbieters abgeschlossen hat. Opaque Access-Tokens bieten keine Payload zur Prüfung. Das ist ein weiterer guter Grund, die Behandlung von Antworten statt Token-Archäologie zum Maßstab zu machen.

Wiederholungsgrenzen schützen das entfernte System und deine Belege

Erlaube nach einem klassifizierten Ablauf eine koordinierte Erneuerung und eine kontrollierte Wiederholung. Mehr Wiederholungen verbessern die Autorisierung nicht. Sie verbergen hauptsächlich einen fehlerhaften Erneuerungsweg und machen das Auditprotokoll schwerer lesbar.

Die Wiederholungsregel hängt von der Operation ab. Eine Leseanfrage verträgt normalerweise eine Wiederholung nach der Erneuerung. Eine Schreibanfrage braucht stärkere Belege, weil der entfernte Dienst sie bereits verarbeitet haben kann, bevor die Ablaufantwort, ein Timeout oder der Verbindungsabbruch den Aufrufer erreicht.

Klassifiziere Operationen beim Entwurf der Aktionsschnittstelle:

HTTP-Methodennamen entscheiden das nicht. PUT hat oft eine idempotente Absicht, aber ein Anbieter kann daran eine E-Mail-Benachrichtigung oder eine asynchrone Folgeaktion knüpfen. POST kann sicher sein, wenn der Anbieter ein Idempotenzfeld unterstützt. Lies den Vertrag des Endpunkts und teste das tatsächliche Verhalten.

Bei Operationen mit einem Idempotenz-Token erzeuge es vor dem ersten Netzwerkaufruf und speichere es mit einem kanonischen Anfragefingerabdruck. Sende bei jeder Wiederholung genau dasselbe Token und eine logisch identische Payload. Erzeuge nach einem 401 kein neues Token. Ein neues Token teilt dem Anbieter mit, dass es sich um eine neue Operation handelt, und vereitelt damit den Zweck.

{
  "operation_id": "job-84f3/create-draft",
  "idempotency_token": "a stable random value stored before send",
  "request_fingerprint": "method, path, normalized body hash",
  "attempt": 1,
  "authorization_generation": 17
}

Die Formulierung «normalisierter Body-Hash» ist wichtig. Wenn der Builder für Wiederholungen einen Zeitstempel, die Reihenfolge eines Arrays oder eine erzeugte Bezeichnung ändert, kann dasselbe Idempotenz-Token unbemerkt eine inkompatible Anfrage bedeuten. Manche Anbieter lehnen diese Abweichung ab, andere behandeln sie uneinheitlich. Bewahre den ersten serialisierten Request-Body auf oder kanonisiere ihn einmal und verwende ihn wieder.

Rate-Limit- und Netzwerk-Wiederholungen müssen sich dasselbe Budget teilen. Ein Agent, der drei Netzwerk-Wiederholungen, danach eine Erneuerung und anschließend drei weitere Netzwerk-Wiederholungen nutzt, hat sieben Chancen geschaffen, eine Operation zu duplizieren oder zu überlasten. Definiere ein an die Operation gebundenes Versuchslimit. Ein sicherer Lesevorgang kann etwa einen ersten Aufruf, einen Erneuerungsweg und eine Wiederholung erlauben. Eine zahlungsähnliche Aktion kann einen ersten Aufruf und danach nur noch einen Abgleich erlauben.

Protokolliere auch unterdrückte Wiederholungen. Operatoren müssen erkennen können, dass das System absichtlich nach renewal_attempted=true aufgehört hat, statt einen Absturz des Agenten zu vermuten. Dieser Eintrag zeigt außerdem, wenn ein Anbieter das Fehlerformat ändert und dein Klassifizierer eine früher erlaubte Wiederherstellung nicht mehr zulässt.

Checkpoints lassen einen Job fortfahren, ohne seine Vergangenheit zu erfinden

Eine lange Agentenaufgabe sollte abgeschlossene entfernte Effekte und ausstehende Absichten getrennt speichern, weil ein erneuertes Token nicht verrät, was vor dem Fehler passiert ist. Das häufige schlechte Muster speichert nur ein Chatprotokoll oder den finalen Plan des Agenten und bittet ihn nach einer Unterbrechung, den Zustand zu rekonstruieren.

Verwende ein Aufgabenjournal mit Datensätzen, die ein Programm abgleichen kann. Jeder beabsichtigte externe Aufruf braucht eine stabile Operations-ID. Jedes bestätigte Ergebnis braucht die Ressourcen-ID des Anbieters, die Version oder den ETag, sofern vorhanden, und den Anfragefingerabdruck. Jedes unsichere Ergebnis braucht die Suchregel, die es auflöst.

Ein kompakter Checkpoint kann so aussehen:

{
  "task_id": "release-2025-04-17-42",
  "completed": [
    {"operation_id": "create-change", "remote_id": "CR-819", "version": "6"},
    {"operation_id": "upload-bundle", "remote_id": "asset-552"}
  ],
  "pending": {
    "operation_id": "attach-bundle",
    "request_fingerprint": "POST /changes/CR-819/assets body-sha256:...",
    "reconcile": "list assets for CR-819 and match asset-552"
  },
  "authorization_state": "authorization_expired"
}

Der Job muss nicht jeden Zwischengedanken speichern. Er braucht genügend Fakten, um die nächste sichere Aktion auf der Gegenseite zu bestimmen. Halte Geheimnisse, Bearer-Header und Refresh-Antworten aus diesem Journal heraus. Diese Daten gehören dem Besitzer der Zugangsdaten, nicht dem allgemeinen Aufgabenspeicher.

Versionsbedingungen sind während einer Pause wichtig. Wenn die Aufgabe vor dem Ablauf Version 6 eines Dokuments gelesen hat und eine Stunde später fortgesetzt wird, kann ein anderer Akteur es geändert haben. Verwende ETags, Revisionsnummern, bedingte Header oder anbieterspezifische Felder für Nebenläufigkeit, sofern verfügbar. Wenn die Bedingung scheitert, teile dem Agenten mit, dass der alte Plan nicht mehr gilt. Erneuere das Token nicht und überschreibe keinen neueren Zustand, nur weil die Aufgabe glaubt, ihr gehöre die Welt.

Hier braucht autonome Arbeit eine Grenze für Ermessensentscheidungen. Ein Job kann einen Upload sicher fortsetzen, wenn Ziel und Hash bereits gespeichert sind. Er sollte nach einer gealterten ursprünglichen Situation nicht beiläufig ein Deployment neu planen, einen Freigabedatensatz ändern oder ein anderes Ziel wählen. Markiere solche Operationen so, dass sie nach der Wiederherstellung eine neue Bestätigung benötigen.

Die Wiederherstellungsantwort muss dem Agenten sagen, was er tun darf

Ein Action-Gateway sollte ein strukturiertes Wiederherstellungsergebnis zurückgeben, keine vage Authentifizierungsformulierung, die den Agenten zum Improvisieren einlädt. Das Ergebnis sollte angeben, ob der Aufruf ausgeführt wurde, ob das Gateway die Autorisierung erneuert hat, ob eine Wiederholung erlaubt ist und ob ein Mensch eingreifen muss.

Ein nützliches Ergebnis trennt Ausführungs- und Zugangsdatenstatus:

{
  "operation_id": "attach-bundle",
  "execution_state": "not_sent",
  "authorization_state": "reauthorization_required",
  "retry_allowed": false,
  "credential_ref": "release-api",
  "operator_action": "Reauthorize the release-api connection, then resume task release-2025-04-17-42",
  "safe_resume_from": "attach-bundle"
}

not_sent bedeutet, dass das Gateway stoppte, bevor es die Anfrage an den Netzwerkclient übergab. outcome_unknown bedeutet, dass es das nicht behaupten kann. Fasse beide Fälle nicht unter failed zusammen. Der erste kann auf eine erneute Autorisierung warten. Der zweite muss mit dem entfernten Dienst abgeglichen werden, bevor etwas wiederholt wird.

Agenten brauchen außerdem ein enges Vokabular für die Wiederherstellung. Gib ihnen Ergebnisse wie completed, renewed_and_replayed, needs_reconciliation, reauthorization_required, permission_denied und configuration_error. Jedes Ergebnis sollte genau einem erlaubten Verhalten entsprechen. Nach renewed_and_replayed kann ein Agent beispielsweise fortfahren; nach needs_reconciliation darf er einen dokumentierten schreibgeschützten Abgleich durchführen; nach reauthorization_required muss er externe Schreiboperationen stoppen.

Vermeide, rohe Antworten des Anbieters als einziges Signal zurückzugeben. Rohdaten helfen bei der Diagnose, aber Agenten können sie schlecht interpretieren, besonders wenn Anbieter uneinheitliche Formulierungen verwenden. Bewahre die Rohantwort in einem geschützten Diagnoseeintrag auf und gib dem Aufrufer eine stabile, maschinenlesbare Entscheidung.

Eine gute Fehlermeldung nennt die Identitätsreferenz und die blockierte Operation, ohne Geheimnisse preiszugeben. «Credential release-api needs reauthorization before attach-bundle can run» sagt einem Operator, wo er handeln muss. «Unauthorized» sagt niemandem etwas.

Refresh-Tokens brauchen strengere Kontrollen als Access-Tokens

Ein Refresh-Token verdient stärkeren Schutz, weil es gewöhnlich länger gültig ist als das Access-Token, das es ersetzt. Löse den Ablauf eines Tokens nicht dadurch, dass du dieses langlebigere Zugangsmittel an jeden Agentenarbeitsbereich, jedes Build-Verzeichnis, jede Umgebungsvariable oder jedes Transkript verteilst.

Die OAuth 2.0 Security Best Current Practice, RFC 9700, empfiehlt für öffentliche Clients die Rotation von Refresh-Tokens oder an den Absender gebundene Refresh-Tokens. Die konkrete Unterstützung variiert je nach Anbieter, aber die Sicherheitslehre gilt auch bei einem anderen Protokoll: Ein gestohlenes erneuerbares Zugangsmittel bietet ein deutlich längeres Missbrauchsfenster als ein gewöhnliches kurzlebiges Bearer-Token.

Bewahre die Erneuerungsdaten im verschlüsselten Credential Store des Action-Gateways auf. Beschränke, welche Aktionsdefinitionen darauf zugreifen dürfen, verlange bei geeigneten Aktionen eine ausdrückliche menschliche Freigabe und mache die erneute Autorisierung zu einer eigenen Operatoraktion. Ein gesperrter Credential Store muss Arbeit verweigern, statt Agenten auf kopierte Geheimnisse in Konfigurationsdateien ausweichen zu lassen.

Sallyport folgt diesem Modell bei unterstützten HTTP- und SSH-Aktionen: Sein verschlüsselter Tresor verwahrt die Zugangsdaten, während der Agent über seinen MCP-Shim eine Aktion anfordert und nur das Ergebnis erhält. Diese Aufteilung ist hilfreich, weil der Agent bei einer fehlerhaften Wiederherstellung kein Refresh-Token in seinen eigenen Kontext schreiben kann.

Gehe mit Antworten auf Erneuerungen sorgfältig um. Manche Anbieter rotieren das Refresh-Token und machen den alten Wert bei der Verwendung ungültig. Der Erneuerungsbesitzer muss den gespeicherten Wert atomar ersetzen, bevor er wartende Aufrufe freigibt. Wenn er das neue Access-Token schreibt, aber das Ersatz-Refresh-Token verliert, kann der Job kurz funktionieren und beim nächsten Ablauf dauerhaft scheitern.

Protokolliere niemals diese Felder: Authorization, Access-Token, Refresh-Token, Client-Secret, signierte Assertion oder den vollständigen Body des Token-Endpunkts. Maskieren reicht nicht, wenn Systeme rohe Anfrageobjekte kopieren, bevor der Maskierer läuft. Entwirf den Logger so, dass er Referenzen auf Zugangsdaten und Token-Generationen statt geheimnishaltiger Strukturen akzeptiert.

Menschliche Freigaben sollten Autorität wiederherstellen, keinen Wiederholungssturm erzeugen

Eine menschliche Freigabe hilft nur, wenn sie einer klaren Entscheidung entspricht: diesen Agentenlauf erlauben, diesen sensiblen Aufruf erlauben oder eine widerrufene Autorisierung wiederherstellen. Eine allgemeine «Wiederholen»-Schaltfläche nach einem Ablauf macht den Operator oft zum Abnickenden einer unklaren Aktion.

Trenne die Freigaben. Eine erneute Autorisierung gibt dem Besitzer der Zugangsdaten eine neue Freigabe oder einen nutzbaren Erneuerungsweg. Die Sitzungsautorisierung entscheidet, ob dieser konkrete Agentenprozess Aktionen anfordern darf. Die Freigabe pro Aufruf entscheidet, ob eine sensible Operation jetzt stattfinden darf. Das sind verschiedene Entscheidungen. Ihre Vermischung erzeugt entweder zu viele Eingabeaufforderungen oder zu weitreichende dauerhafte Berechtigungen.

Wenn Zugangsdaten eine erneute Autorisierung brauchen, zeige die betroffene Referenz, die Identitäts- oder Verbindungsbezeichnung, die blockierte Operation und den Aufgaben-Checkpoint. Zeige nicht das Token selbst. Sobald der Operator die Autorisierung wiederhergestellt hat, sollte das Gateway nur die im Checkpoint gespeicherte ausstehende Operation fortsetzen. Es sollte nicht stillschweigend jeden fehlgeschlagenen Aufruf aus dem Agentenprotokoll wiederholen.

Sallyports feste Entscheidungskette passt gut zu dieser Grenze: Ein gesperrter Tresor verweigert jede Aktion, neue Agentenprozesse benötigen standardmäßig eine Sitzungsfreigabe, und ausgewählte Zugangsdaten können bei jeder Nutzung eine Freigabe verlangen. Die Kontrollen versuchen nicht, Absichten aus einem Haufen Regeln abzuleiten. Das hilft, wenn ein abgelaufenes Token einen ansonsten legitimen Lauf unterbricht.

Freigabemüdigkeit ist meist ein Designfehler. Wenn ein Operator ein Dutzend Aufforderungen sieht, weil zehn parallele Aufrufe denselben Ablauf bemerken, hat der Erneuerungskoordinator das Ereignis nicht zusammengeführt. Zeige eine einzige Anfrage zur erneuten Autorisierung, lass die anderen Aufrufe warten und melde jeder Aufgabe das Ergebnis.

Verwende eine Freigabe nicht, um eine unbekannte Schreibwirkung zu überdecken. Die richtige Aufforderung fragt in diesem Fall, ob das System den entfernten Zustand abgleichen soll, nicht, ob es wiederholen soll. Auch ein Mensch kann versehentlich eine Duplikation autorisieren.

Ablaufprüfungen müssen unsichere Schreibvorgänge und parallele Worker einschließen

Ein Erneuerungstest, der vor einem Lesevorgang einen künstlichen 401 zurückgibt, beweist wenig. Die schädlichen Fehler treten an Grenzen auf: während paralleler Arbeit, nachdem eine Schreiboperation verbucht wurde, bei der Rotation einer Erneuerung oder nach dem Widerruf einer Freigabe.

Baue einen Testanbieter oder ein steuerbares HTTP-Fixture, das empfangene Operations-IDs aufzeichnet und Fehler an festgelegten Punkten einschleusen kann. Deine Assertions sollten sowohl den Datensatz der entfernten Wirkung als auch den lokalen Auditdatensatz prüfen. Eine erfolgreiche abschließende Antwort kann eine doppelte Erstellung verbergen.

Führe diese Fälle aus, bevor du einem lang laufenden Agenten vertraust:

1. Lass das Access-Token vor einer Leseoperation ablaufen. Bestätige, dass nur ein Worker erneuert und alle wartenden Lesevorgänge die neue Generation verwenden.
2. Lass es vor einer idempotenten Schreiboperation ablaufen. Bestätige, dass das Gateway einmal erneuert und mit ursprünglicher Operations-ID und ursprünglichem Request-Body wiederholt.
3. Verwirf die Antwort, nachdem der Anbieter eine nicht idempotente Schreiboperation verbucht hat. Bestätige, dass der Job in outcome_unknown wechselt, seine Suche ausführt und keine zweite Wirkung erzeugt.
4. Widerrufe die Freigabe vor der Erneuerung. Bestätige, dass jede abhängige Aktion mit reauthorization_required stoppt und keine Schleife den Token-Endpunkt wiederholt aufruft.
5. Gib ein rotiertes Refresh-Token zurück und unterbrich dann die Speicherung. Bestätige, dass das Gateway den unvollständigen Austausch erkennt und künftige Erneuerungen blockiert, statt eine alte Kopie zu verwenden.

Teste die Zeit ausdrücklich. Injiziere eine Uhr in die Zugangsdatenkomponente, damit du den Ablauf kurz vor dem Aufbau der Anfrage, kurz nach dem Aufbau des Headers und während des Wartens in einer Queue platzieren kannst. Bis zum tatsächlichen Ablauf eines Tokens zu schlafen macht Tests langsam und lässt die wichtigen Timing-Fälle ungeprüft.

Teste schließlich den Auditpfad ohne Zugriff auf den Tresor. Du solltest prüfen können, dass sich die Folge der versuchten Aufrufe und Erneuerungsentscheidungen nicht verändert hat, auch wenn du nicht jeden Datensatz entschlüsseln kannst. Sallyports sp audit verify prüft die Hash-Kette über verschlüsselte Auditdaten ohne Tresorschlüssel. Das ist die richtige Form der Prüfung für einen Vorfall, bei dem der Zugang zu den Zugangsdaten möglicherweise gesperrt bleiben muss.

Ein Job, der Abläufe gut behandelt, tut weniger, nachdem die Autorisierung scheitert. Er stoppt, klassifiziert den Fehler, lässt einen Besitzer einmal erneuern, gleicht Unsicherheiten ab und setzt nur die aufgezeichnete Operation fort. Diese Zurückhaltung verhindert doppelte Seiteneffekte und liefert dem Operator Belege statt eines Haufens von Wiederholungen.