Der Connect-Knopf verbindet jetzt

Einen Assistenten zu genehmigen tat nichts. Die Seite sagte, das Formular komme nicht von hier — und hatte auf falsche Weise recht: die Genehmigungsseite bat Browser, keinen Referrer zu senden, und Chrome leitet den Origin einer Seite aus derselben Einstellung ab. So kam das eigene Formular der Seite von nirgendwo, und die Prüfung, die andere Websites am Genehmigen hindert, hielt die Seite selbst auf. Verbunden worden war darüber noch nie etwas. Dahinter saß ein zweiter Fehler: die Seite darf den Browser nur zu dem Assistenten schicken, der gefragt hat — und sie nannte lange nur uns selbst, sodass die Rückreise von der Seite selbst abgelehnt wurde. Jetzt nennt sie genau diese eine Adresse.

Einen Assistenten zu genehmigen ist eine Seite und ein Knopf. Das steht dahinter.

Was das Genehmigen tatsächlich tut

Sie melden sich mit dem Konto an, das Sie ohnehin benutzen, lesen eine Seite, die den Client und die Adresse nennt, als die er handeln wird, und drücken Connect. Was er mitnimmt, ist ein Token dieser Website — nicht Ihre Sitzung und kein API-Schlüssel. Es erreicht die Dokumente des Kontos und nichts weiter: nicht das Konto, nicht die Anmeldung, nicht Ihre API-Schlüssel. Eine nur lesende Verbindung kann nicht speichern, teilen oder löschen — durchgesetzt an der Berechtigung, nicht an den Werkzeugen.

TransformPipe muss dafür sein eigener Autorisierungsserver sein: laut MCP-Spezifikation darf eine Ressource kein fremdes Token annehmen, die Anmeldesitzung lässt sich also nicht weitergeben.

Die Reihenfolge der Ereignisse

  1. Der Assistent schickt ein POST an /api/mcp ohne Token und bekommt eine 401, die sagt, wo nachzusehen ist.
  2. Er liest /.well-known/oauth-protected-resource, dann /.well-known/oauth-authorization-server, um die Endpunkte zu finden.
  3. Er sagt, wer er ist — über ein Metadatendokument, das er veröffentlicht, oder indem er sich hier registriert. Ein Geheimnis gibt es nie: ein Client auf dem Rechner eines anderen kann keines hüten, und genau dafür ist PKCE da.
  4. Er schickt Sie mit einer Challenge an /authorize. code_challenge_method=S256 ist Pflicht; eine einfache Challenge wird abgelehnt.
  5. Sie genehmigen mit einem POST von der Seite, die Ihnen gezeigt wurde — ein Link allein genehmigt nichts.
  6. Er tauscht Code und Verifier an /token ein.

Was die Token danach tun

Ein Code lebt fünf Minuten und wird zu Beginn des Tauschs verbrannt, bevor etwas gegen ihn geprüft wird: eine Kopie, die während des ersten Aufrufs eintrifft, bekommt nichts. Refresh-Token rotieren — wer eines einreicht, entwertet es und erhält ein frisches Paar. Wer eines vorlegt, das schon rotiert wurde, beendet die ganze Berechtigung: Zugriffstoken, Refresh-Token und jede Rotation davor. Ein zweimal vorgelegtes Refresh-Token ist das einzige Zeichen dafür, dass es kopiert wurde.

Zurücknehmen können Sie das im Konto-Menü unter MCP-Konnektor; beim nächsten Aufruf ist Schluss.

Warum der Knopf nie etwas getan hat

Zwei Kopfzeilen auf unserer eigenen Seite. Sie bat Browser, keinen Referrer zu senden, und Chrome leitet den Origin eines Formular-POSTs aus derselben Einstellung ab — das eigene Formular der Seite kam also von nirgendwo, und die Prüfung, die fremde Websites am Genehmigen hindert, hielt die Seite selbst auf. Dahinter nannte ihr form-action nur diese Website: die Rückreise zum Assistenten lehnte die Richtlinie ab, nachdem der Code längst erzeugt war. Jetzt steht dort nur die eine Adresse, an die die Anfrage geht.

Weiter: Dokumente aus einem Assistenten heraus konvertieren und ob ein Online-Konverter sicher ist.