PullMD Teil 10: Absichern, aber richtig – Einfach erklärt
Der Reddit-Post aus Teil 9 hatte einen Nebeneffekt. Von dem Moment an wussten eine Menge Leute, dass es einen Dienst gibt, den man einfach so aufrufen kann, ohne sich irgendwo einzuloggen.
Bei mir war das kein Problem, weil der Dienst nur im eigenen Netz lief. Aber jetzt konnte jemand das Tool bei sich aufsetzen, es ins Internet stellen und sich eines Tages wundern, warum Fremde dort mitlesen. Damit rückte ein Thema nach oben, das bisher warten konnte: die Authentifizierung. Das ist die Frage, wer sich überhaupt ausweisen muss, bevor er einen Dienst benutzen darf.
Drei Sachen auf einmal
Am 28. April kamen deshalb drei Dinge gleichzeitig dazu. Erstens ein Token: ein geheimes Kennwort in der Konfiguration, das der Dienst bei jeder Anfrage prüft. Dazu zwei OAuth-Wege. OAuth ist ein Verfahren, bei dem man sich nicht direkt beim Dienst einloggt, sondern über einen Mittler. Statt dem Dienst ein Passwort zu geben, sagt ein vertrauenswürdiger Dritter: „Ja, den kenne ich, der darf rein.“
Das war die schnelle Antwort. Ein Riegel vor die Tür, damit erst mal Ruhe ist. Aber schnelle Antworten haben eine Tücke: man hält sie leicht für fertig.
Der eigene Review sagte nein
Am nächsten Morgen lief ein Review über den OAuth-Teil, und der kam mit einem blockierenden Befund zurück. Der Endpunkt, also die Stelle, an der sich ein Programm die Erlaubnis abholt, war selbst nicht abgesichert. Dazu fehlte eine Liste erlaubter Rücksprung-Adressen. Beides zusammen heißt: Das Geheimnis, mit dem sich ein Programm ausweisen soll, lässt sich umgehen.
Das ist der unangenehme Teil an Reviews, die man selbst bestellt. Sie finden genau das, was man nicht finden wollte, und zwar bevor es jemand anderes tut. An der Stelle hätte ich die Befunde einfach abarbeiten können. Habe ich dann aber nicht.
Die Frage, die alles wieder aufmachte
Stattdessen kam mir beim Draufschauen etwas anderes:
„also da muss ich generell mal drüber nachdenken… wie würde das aussehen, angenommen wir fixen die bugs alle… ich starte mein docker und hab in den env schon ein secret konfiguriert und auth aktiviert… wenn ich die webseite aufrufe, was ist dann? wenn ich die PWA aufrufe, was ist dann?“
(PWA steht für Progressive Web App: eine Webseite, die sich auf dem Handy verhält wie eine echte App.)
Genau da hörte die schnelle Antwort auf zu funktionieren. Das Token schützte die API (die Schnittstelle, über die Programme miteinander reden). Die Weboberfläche und die App standen weiterhin offen.
Wer die Adresse kannte, konnte den Dienst im Browser benutzen, die Historie durchsehen und sehen, was ich so lese. Die Historie ist das Gedächtnis des Dienstes: eine Liste aller Seiten, die man schon einmal durchgeschickt hat.
Ein Riegel vor einer von drei Türen.
Also richtig
Die Antwort auf meine eigene Frage fiel dann ziemlich schnell:
„Variante 1: das macht doch kaum sinn, wenn der rest offen ist, wozu soll ich dann mcp absichern? nur damit ich es über claude.ai nutzen kann? dann muss der server aber aus dem internet erreichbar sein… ohne den rest zu schützen? na viel spass ;-)
Variante 2: auch nicht vollständig, wen dann richtig! also user/passwort login auf web und PWA, alles was agent ist per API key oder?
Also absichern, aber richtig“
(MCP steht für Model Context Protocol: so etwas wie eine Steckdose, über die ein KI-Assistent fremde Werkzeuge direkt mitbenutzen kann.)
Was das bedeutet, war mir in dem Moment schon klar. Es war deutlich mehr Arbeit, als ich an dem Tag eigentlich vorhatte.
Wenn es einen Login geben soll, braucht es Benutzer. Wenn es Benutzer gibt, braucht es Sitzungen (also laufende Anmeldungen, die sich merken, dass man eingeloggt ist), Passwörter und Schlüssel. Und dann gehört auch die Historie nicht mehr allen, sondern jedem seine eigene.
Aus einem Riegel wird damit ein Umbau.
Die eine Einschränkung, die alles bestimmt hat
Ein Punkt war mir dabei wichtig genug, um ihn noch am selben Vormittag nachzuschieben:
„nochmal zur api key auth für agents, weil du es einfach so hingenommen hast: würde damit auch claude.ai zugriff per mcp funktionieren oder ist dort oauth pflicht? weil das möchte ich uns nicht verbauen…“
Das war die richtige Frage, auch wenn mir die Antwort nicht gefallen hat. Ein Schlüssel reicht für Werkzeuge, die man selbst konfiguriert. Für den Weg über die Weboberfläche von claude.ai reicht er nicht: da führt kein Weg an OAuth vorbei.
Damit stand die Reihenfolge fest, noch bevor ich eine Zeile davon gebaut hatte. Erst die Benutzer, dann OAuth obendrauf. Andersherum geht es nicht, denn OAuth ohne Benutzer ist sinnlos.
Was daraus wurde, steht in Teil 11. Und dass OAuth danach trotzdem nicht funktionierte, aus einem Grund, den ich zunächst ganz woanders vermutet habe, steht in Teil 12 und Teil 13.
Teil 10 von 15 der PullMD Serie.
← PullMD Teil 9: Reddit-Tag und die ersten Issues | PullMD Teil 11: Multi-User-Pivot →