OAuth & ChurchTools API (am Beispiel eines MCP Servers)
-
Gude liebes ChurchTools-Team,
ich habe mich letzte Woche aus Spaß und Interesse hingesetzt und wollte einen MCP-Server für unsere Gemeinde bauen.
Zum groben Hintergrund:
Mir ging es darum herauszufinden, was man alles mit der CT API machen kann und wie wir als Gemeinde vielleicht kleinere Apps entwickeln können, die bestimmten Personengruppen im Umgang damit sehr helfen. Außerdem wäre es spannend, gegebenenfalls verschiedene Systeme miteinander zu vernetzen.Dabei habe ich zunächst eine Implementierung mit Personal Access Tokens angestrebt, die auch wunderbar funktioniert hat. Ein Video dazu ist im Repository zu finden. (https://github.com/samuelspagl/ct-mcp)
Im zweiten Schritt wollte ich eine Authentifizierung über OAuth umsetzen, da es aus meiner Sicht natürlich besser wäre, wenn der MCP-Server Anfragen immer mit den jeweiligen User Credentials stellt, ohne einen „God-Token“ zu besitzen.
Die Authentifizierung über OAuth lief wie geschmiert, getestet in einem Demo-System. Über /oauth/userinfo konnte ich auch die jeweilige E-Mail-Adresse und Gruppenzugehörigkeit auslesen. Allerdings habe ich keine Möglichkeit gefunden, diesen access_token auch in der API als Authentifizierungsmaßnahme zu nutzen.
Daher meine Frage: Ist das aktuell nicht möglich?
Die Authentifizierung über Nutzername und Passwort mit dem /api/login-Endpunkt wäre zwar auch eine Option. Im Fall des MCP-Servers müsste ich ihn dann aber so bauen, dass diese Daten „durchgereicht“ werden, was nicht ganz meine bevorzugte Lösung wäre.
Eine Andere Lösung, die ich zwischenzeitlich eingebaut habe, ist das "Forwarding" des PAT's.
Allerdings fühlt sich auch das nicht ganz richtig an.Was denkt ihr dazu? Wie sollte man eine solche Integration planen? Wird in der Zukunft ggf. der OAuth Token auch zur API Authentifizierung genutzt werden können?
Beste Grüße, und vielen Dank vorab.
-
@samuelspagl Hallo, ich bin zu wenig Fachmann, um wirklich alles umfassend zu verstehen, aber unser Projekt Heizkalender nutzt Token API in Form einer virtuellen Person — ohne Probleme. Wir kommen so an die Daten. Siehe siehe Anleitung, die sich auf der Homepage des Heizkalender befindet. www.Heizkalender.de
-
Hallo @samuelspagl,
vielen Dank für deine Arbeit — ich habe genau dort angeknüpft und für mein Claude Cowork Szenario erweitert!
Nun habe ich einen benutzerdefinierten Claude Connector und bekomme morgens im Briefing alle meine Dienste, Geburtstage, Termine genannt.
Ich habe deinen MCP-Server geforkt und einen stdio-Einstieg ergänzt, sodass der Server direkt über npx von Claude Desktop oder Claude Code gestartet werden kann — ohne eigenen HTTP-Server oder Docker. Das Paket ist auf npm als churchtools-mcp verfügbar.
Zur OAuth-Frage: Ich teile deine Einschätzung, dass ein God-Token nicht ideal ist. Für unser Szenario (Cowork mit mehreren Mitarbeitern) haben wir aber festgestellt, dass PAT-Forwarding funktional dasselbe erreicht wie OAuth — jeder Nutzer schickt seinen eigenen PAT mit, der Server handelt immer im Rahmen der Rechte des jeweiligen Nutzers. Was OAuth wirklich besser machen würde, ist die Nutzererfahrung (kein manuelles Token-Kopieren, automatisches Ablaufen). Aber das Sicherheitsmodell ist gleichwertig.
Der einzige Weg das wirklich sauber zu lösen wäre, wenn ChurchTools den OAuth-Access-Token auch für REST-API-Calls akzeptiert — das wäre mein Wunsch ans ChurchTools-Team.
Repository: https://github.com/integrenns-ae/churchtools-mcp
npm: npx -y churchtools-mcpBeste Grüße,
Alexander
