Zusammenfassung

  • Ein an den Client-Schlüssel gebundener GNAP-Fortsetzungstoken setzt einen bestimmten Grant-Antrag fort, nicht einen Aufruf an einen geschützten Resource Server.
  • Solange der Antrag aussteht, dürfen weder API-Token ausgegeben noch Subject-Informationen freigegeben werden. Auch nach einer Interaktion muss der Autorisierungsserver den gesamten Kontext erneut bewerten.

Eine Oberfläche kann melden, dass jemand den Zustimmungsschritt abgeschlossen hat. Das ist kein belangloses Signal, aber auch kein endgültiges Urteil. Es kann lediglich heißen, dass ein Browser zum Client zurückkehrte, dass der Client eine Fortsetzungs-URI erhielt oder dass er den Besitz eines Schlüssels signiert nachwies. Daraus folgt noch nicht, dass dieser Client jetzt diese konkrete API-Operation ausführen darf.

RFC 9635 ordnet GNAP gerade gegen diesen Kurzschluss. Der Client stellt beim Autorisierungsserver einen Grant-Antrag. Sind Zustimmung des Resource Owners oder Nutzerinteraktion noch erforderlich, wird der Antrag pending. Der Server darf dann Fortsetzungsinformationen zurückgeben, aber weder API-Zugriffstoken erteilen noch Subject-Informationen herausgeben. Über Zugriff wird noch verhandelt; Zugriff wurde noch nicht gewährt.

Der Fortsetzungsnachweis hat eine absichtlich enge Aufgabe. Er muss an den Schlüssel der Client-Instanz gebunden sein, darf kein Bearer Token sein und muss zusammen mit einem Beweis dieses Schlüssels an der Fortsetzungs-URI vorgelegt werden. Der Autorisierungsserver prüft Signatur und Schlüsselbindung. Das schützt, wer dasselbe Gespräch weiterführen darf. Es erzeugt keine Befugnis am Resource Server.

Die Trennung gilt normativ in beide Richtungen. Ein gewöhnlicher Access Token darf nicht am Fortsetzungsendpunkt funktionieren. Umgekehrt darf ein Fortsetzungstoken nicht für einen autorisierten Request an einen Resource Server nutzbar sein, auch nicht bei gemeinsamem Deployment von Resource und Authorization Server. Zwei ähnlich aussehende Werte haben damit weder denselben Prüfer noch dieselbe URI, Reichweite oder Wirkung.

Auch der Abschluss einer Interaktion beendet die Entscheidung nicht automatisch. Danach geht der Antrag wieder in die Verarbeitung, und der Autorisierungsserver bewertet den gesamten Kontext neu — unabhängig davon, ob der Resource Owner zugestimmt oder abgelehnt hat. Nur ein genehmigter Antrag kann API-Token oder Subject-Informationen liefern. Ein finalisierter Antrag kann keine neuen Token ausgeben, keine Informationen zurückgeben und keine Interaktion wieder aufnehmen; künftiger Zugriff verlangt einen neuen Antrag.

Das Token-Management ist eine dritte Oberfläche. Ein API-Token kann eine eigene Management-URI und ein separates Management-Credential für Rotation oder Widerruf enthalten. Rotation behält Rechte und Eigenschaften des Ausgangstokens bei; sie erweitert sie nicht. Andere Rechte verlangen eine Fortsetzungsaktualisierung samt neuer Bewertung oder einen neuen Antrag. Verwaltungskontinuität ist keine Ausweitung von Autorität.

Der Resource Server behält seinen eigenen Prüfpunkt. Ein GNAP-API-Token wird mit dem vorgeschriebenen Schlüsselnachweis vorgelegt; der Server kann Anfragen ohne Token oder mit ungültigem Token herausfordern. Auch das beweist nicht, dass ein Geschäftszweck noch aktuell ist, Betriebsbedingungen erfüllt sind oder die gewünschte Wirkung eintrat.

Die belastbare Nachweiskette trennt daher Antrag und beantragten Access, Pending-Status, Fortsetzungs-URI und Schlüsselbeweis, Interaktionsergebnis, Neubewertung, Umfang des API-Tokens, Prüfung am Resource Server, Request-Eingang und beobachtete Wirkung. Alles als „autorisiert“ zu bezeichnen, löscht die Verantwortungslinien, die das Protokoll bewusst erhält.

Quellen