PullMD Teil 10: Absichern, aber richtig
Der Reddit-Post aus Teil 9 hatte einen Nebeneffekt: Von dem Moment an wussten eine ganze Menge Leute, dass es einen Dienst gibt, den man ohne Konto aufrufen kann, sofern man ihn ins Internet stellen sollte.
Bei mir war das ja kein Problem, weil der Dienst nur im eigenen Netz lief. Jetzt konnte ihn aber jemand aufsetzen, der sich damit nicht so auskennt, ihn auf einen vServer stellen und sich eines Tages beschweren. Damit rückte die Authentifizierung deutlich weiter nach vorn.
Drei Commits am selben Tag
Am 28. April sind deshalb drei Sachen dazugekommen. Ein Token in der Konfiguration, das der Dienst bei jeder Anfrage prüft. Dazu zwei OAuth-Wege für die Fälle, in denen ein Token nicht reicht.
Das war die schnelle Antwort. Ein Riegel vor die Tür, damit erst mal Ruhe ist. Aber eine schnelle Antwort birgt die Gefahr, dass man sie für fertig hält.
Der eigene Review sagte nein
Am nächsten Morgen lief ein Review über den OAuth-Zweig, und der kam mit einem blockierenden Befund zurück.
Der Endpunkt, an dem sich ein Client 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 Client 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?“
Denn genau da hörte die schnelle Antwort eben auf zu funktionieren. Das Token schützte die Schnittstelle. 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.
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“
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, 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 Weitere 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 halt nicht, denn OAuth ohne Benutzer ist ja 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 →