OAuth-Berechtigungen für Agenten: Scopes erst anfordern, wenn sie gebraucht werden

Ein Agent, der gleich bei der Anmeldung alle Berechtigungen verlangt, bittet aus unserer Sicht um einen Vertrauensvorschuss. Dabei gibt es eine einfache Regel: Ein Agent fragt eine Berechtigung erst an, wenn eine konkrete Funktion sie braucht.

Neu ist diese Regel nicht. Google beschreibt sie in seinem Best-Practices-Leitfaden für OAuth 2.0. Die Normungsorganisation IETF bündelt in RFC 9700 die bewährten Sicherheitspraktiken für OAuth. Wie gut die Regeln auf Agenten passen und wo sie an ihre Grenze stoßen, ist unsere eigene Einordnung.

Rechte im Moment des Bedarfs

Google nennt das Prinzip „incremental authorization“, also schrittweise Autorisierung. Es dreht sich um Scopes, also einzelne Zugriffsrechte wie „Kalender lesen“ oder „E-Mails senden“. Laut Leitfaden fragt eine App einen Scope erst an, wenn eine Funktion ihn tatsächlich braucht. Beim Einstieg soll sie nur dann Datenzugriff verlangen, wenn die Kernfunktion ohne ihn nicht läuft. Auch dann wählt sie die kleinsten Scopes, die für die Aufgabe genügen.

Für einen Agenten sieht der Ablauf so aus: Du meldest dich an, und er bietet zunächst nur, was ohne zusätzliche Daten funktioniert. Willst du mehr, fragt er genau das eine Recht an, das dafür nötig ist. Lehnst du ab, bleibt die Funktion aus, und er erklärt, wie du den Zugriff später doch noch erteilen kannst.

Nach Angaben von Google sollen Scopes immer im Kontext angefragt werden, damit Nutzer verstehen, warum die App Zugriff verlangt und wie sie die Daten verwendet. Für den Berechtigungsdialog eines Agenten folgt daraus, dass die Anfrage dort erscheint, wo die Aufgabe entsteht: als ein Recht mit einem Satz Begründung statt einer langen Liste beim Onboarding, die niemand ernsthaft prüft.

Agenten in dynamischen Umgebungen

RFC 9700 beschreibt eine allgemeine Entwicklung: OAuth läuft heute in deutlich dynamischeren Umgebungen als ursprünglich gedacht. Das alte Modell fester Beziehungen zwischen Client, Autorisierungsserver und Ressourcenserver hat sich laut RFC in mehreren Szenarien aufgelöst. Der RFC widmet außerdem der Einschränkung von Access-Token-Rechten einen eigenen Abschnitt. Nach unserer Einschätzung gehört ein Agent, der wechselnde Dienste anspricht, genau in dieses dynamische Bild.

Hypothetisches Beispiel: Ein Assistent soll deine Termine zusammenfassen. Dafür reicht ein lesender Kalender-Scope. Bittest du ihn später, eine Einladung zu verschicken, fragt er im Dialog nach dem zusätzlichen Recht und sagt in einem Satz, wozu er es braucht. Lehnst du ab, läuft die Zusammenfassung weiter. Nur das Versenden bleibt gesperrt.

Ein Nein ist eine Antwort

Wer mehrere Scopes auf einmal anfragt, bekommt nach Googles Leitfaden nicht unbedingt alle. Die App soll dann die betroffenen Funktionen abschalten und weiterlaufen, statt abzubrechen. Erneut fragen darf sie erst, wenn der Nutzer klar zeigt, dass er die betreffende Funktion nutzen will.

Bei Agenten halte ich diese letzte Regel für die wichtigste im ganzen Leitfaden. Sparsame Scopes bringen wenig, wenn ein Agent eine Ablehnung als Hindernis behandelt, das sich durch Nachfragen überwinden lässt, und genau dazu verleitet ein System, das bei jedem neuen Arbeitsschritt prüft, ob ihm ein Recht fehlt. Wer nach einem Nein in jeder Runde wieder fragt, setzt auf Ermüdung. Mit Zustimmung hat das nichts zu tun.

Der Agent merkt sich die Ablehnung also. Die Funktion gilt danach als nicht verfügbar, bis eine neue, ausdrückliche Bitte des Nutzers eine neue Anfrage rechtfertigt.

Wann Rechte wieder enden

Kleine Scopes sind nur die halbe Arbeit. Zu den Nutzer-Tokens zählt Google sowohl Refresh-Tokens, mit denen eine Anwendung neue Zugänge abholt, als auch die Access-Tokens selbst. Beide gehören laut Leitfaden in einen sicheren Speicher und dürfen nie im Klartext übertragen werden. Braucht der Agent sie nicht mehr, sollen sie widerrufen und dauerhaft gelöscht werden. Die Client-Zugangsdaten der Anwendung selbst gehören laut Google in einen Secret Manager, nicht hartkodiert in den Code und nicht in ein Repository. Wohin Zugangsdaten sonst noch nicht gehören, beschreibt unser Beitrag Bearer-Tokens in Agentenaufrufen: Warum Zugangsdaten nicht in URLs gehören.

Rechte können auch von der anderen Seite enden. Refresh-Tokens werden laut Google ungültig, wenn sie ablaufen oder wenn der Nutzer oder ein automatischer Prozess den Zugriff entzieht. Als mögliche Reaktionen nennt der Leitfaden, bei der nächsten Anmeldung erneut zu fragen oder die zugehörigen Daten aufzuräumen.

Für einen Agenten heißt das: Ein abgelaufenes oder entzogenes Token ist kein technischer Fehler, den er durch Wiederholen behebt. Er beendet die betroffene Aufgabe sauber, sagt dem Nutzer, welches Recht fehlt, und fragt erst bei der nächsten Gelegenheit wieder nach, wenn der Nutzer die Funktion tatsächlich braucht. Eine Schleife aus Fehlversuchen ist die falsche Antwort.

Dasselbe Aufräumen betrifft die OAuth-Clients, also die registrierten Anwendungen selbst. Ungenutzte Clients sind nach Angaben von Google ein Risiko, falls ihre Zugangsdaten in falsche Hände geraten. Google löscht Clients auf seiner Plattform nach sechs Monaten Inaktivität automatisch. Das ist eine Regel dieses Anbieters, keine allgemeine OAuth-Vorgabe. Google empfiehlt ohnehin, ungenutzte Clients schon vorher selbst zu entfernen.

Das Protokoll-Fundament bleibt Pflicht

Schrittweise Scopes ersetzen keine saubere OAuth-Implementierung. RFC 9700 nennt dafür mehrere zentrale Anforderungen. Drei davon betreffen Agenten besonders.

Erstens die Weiterleitungen. Autorisierungsserver müssen Redirect-URIs laut RFC exakt mit den vorab registrierten Adressen vergleichen; nur bei localhost-Adressen nativer Apps darf die Portnummer abweichen. Offene Weiterleitungen, die den Browser an beliebige Ziele schicken, dürfen weder Clients noch Server anbieten.

Zweitens der Schutz vor Cross-Site Request Forgery (CSRF), also vor Anfragen, die ein Dritter dem Client unterschiebt. Clients müssen solche Angriffe laut RFC verhindern. Auf den Schutz durch PKCE, ein Verfahren zur Absicherung des Autorisierungscodes, darf sich ein Client nur verlassen, wenn er sichergestellt hat, dass der Autorisierungsserver PKCE unterstützt. In OpenID-Connect-Abläufen übernimmt der nonce-Parameter diese Aufgabe. Andernfalls sind einmalig verwendbare CSRF-Tokens im state-Parameter Pflicht, die sicher an den jeweiligen Browser oder User-Agent gebunden sind.

Drittens, und das ist für Agenten der heikelste Punkt: Spricht ein Client mit mehr als einem Autorisierungsserver, braucht er laut RFC einen Schutz gegen Mix-up-Angriffe. Dabei wird eine Antwort dem falschen Server zugeordnet. Ein Agent, der Kalender, Mail und Ablage verschiedener Anbieter verbindet, landet schnell in genau dieser Lage. Ob die Anforderung im Einzelfall greift, hängt davon ab, wie viele Autorisierungsserver tatsächlich beteiligt sind.

Fazit: Rechte folgen der Aufgabe

Beide Quellen sprechen für eine klare Linie bei Agenten. Rechte richten sich nach der Aufgabe, nicht nach der Vermutung, was später einmal nützlich sein könnte. Scopes werden im Kontext angefragt und klein gehalten. Ein Nein bleibt ein Nein. Nicht mehr benötigte Tokens werden widerrufen und gelöscht.

Die Grenze ist trotzdem deutlich. Schrittweise Autorisierung begrenzt, wie viel ein Agent darf, sagt aber nichts darüber, ob er das Erlaubte sinnvoll nutzt. Ein Agent mit einem einzigen Schreibrecht für E-Mails kann mit genau diesem Recht immer noch die falsche Nachricht verschicken. Der mögliche Schaden wird kleiner. Verhindert wird er nicht. Wie sich solche Grenzen auf wiederkehrende Aufträge übertragen lassen, zeigt unser Beitrag über Daueraufträge mit klaren Grenzen.