OAuth & ChurchTools API (am Beispiel eines MCP Servers)

samuelspagl

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.

DiedrichsHW

@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

AlexanderEnns

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-mcp

Beste Grüße,
Alexander

joe24

@AlexanderEnns Aus Interesse: Wie löst ihr das Datenschutzmäßig? Bin in der Materie nicht ganz drin, aber da du von Claude Cowork sprichst, gehe ich davon aus, dass auf die Daten, die du genannt hast Claude Cowork Zugriff hat, also Namen und Geburtsdaten von Mitgliedern, potentiell noch sensiblere Informationen. Oder verstehe ich das falsch?

EDIT:
Vielleicht habe ich es auch falsch verstanden, aber du nutzt KI um dir deine Termine zeigen zu lassen? Nennt mich Oldschool, aber irgendwie finde ich einen Blick in den Kalender da schneller und günstiger

AlexanderEnns

Hallo @joe24, Cowork ist das agentische Modul der Claude KI Produktpalette. Es erledigt Dinge an deinem Computer, in deinem Namen und unter deinem Berechtigungsspektrum.

Ich lasse es also mit meinem CT Token dort reinschauen und die Daten lesen.

Warum das einfacher ist?
Die meisten haben mehr als einen Kalender

Privat auf Google und Apple, gemeindetechnisch auf Churchtools, geschäftlich in Outlook, schulisch in iserv etc.

Neben den Kalendern, sage ich ihm, es soll mir Top 3 Nachrichten aus der KI Welt und Nachrichten aus Israel geben.

Ein bekanntes Szenario für einen KI Agenten ist das sogenannte Briefing. Dein Agent (KI Assistent) holt sich alle Infos und "brieft" dich morgens mit allen Infos, wie ein Sekretär (auch oldschool, aber cool :D).

Einfacher wäre es für solche Szenarien, wenn CT einen offiziell, registrierten KI Connector baut, der mit einigen Fragen seitens des Agenten leicht aktivierbar wäre.

Agenten handeln in deinem Namen. Ich kann aber verstehen, wenn sicherheitsorientierte Anwender da nicht mitmachen.

LG

Alex

jziegeler

@AlexanderEnns der Sicherheitsaspekt ist glaube ich nicht das Problem, sondern der Datenschutz: Claude bekommt Zugriff auf schützenswerte Daten wie zb Adresse oder Geburtsdatum

Andi 1

@AlexanderEnns sagte in OAuth & ChurchTools API (am Beispiel eines MCP Servers):

Es erledigt Dinge an deinem Computer, in deinem Namen und unter deinem Berechtigungsspektrum. Ich lasse es also mit meinem CT Token dort reinschauen und die Daten lesen.

Das halte ich tatsächlich auch für problematisch. Ist das für die betroffenen Personen OK?

joe24

@AlexanderEnns Wenn dein KI-Tool in deinem Namen personenbezogene Daten von Menschen in deine Gemeinde abgreift halte ich das für

einen Vertrauensmissbrauch der Menschen in deiner Gemeinde, wenn es nicht ganz klar kommuniziert ist.
schlicht illegal, wenn es nicht in der Dateschutzerklärung eures ChurchTools klar geregelt ist. Du machst dich ganz klar strafbar.

@AlexanderEnns sagte in OAuth & ChurchTools API (am Beispiel eines MCP Servers):

Die meisten haben mehr als einen Kalender

Privat auf Google und Apple, gemeindetechnisch auf Churchtools, geschäftlich in Outlook, schulisch in iserv etc.

Übrigens Side-Note: Genau das macht jedes Kalendertool der Welt für dich
Ich löse gern Probleme mit KI, insbesondere beim Coden, aber was du beschreibst ist wie einen Taucheranzug anziehen um bei Regen nicht nasszuwerden, wenn an der Garderobe ein Regenschirm hängt

joe24

@AlexanderEnns Um es noch mal ganz deutlich zu machen: Personen, die Zugriff auf personenbezogene Daten haben, müssen auf das Datengeheimnis verplichtet werden (§ 53 des Bundesdatenschutzgesetzes). Dieses verplichtet u.a. dazu Verschwiegenheit über alle personenbezogenen Daten, die du auf Grund deiner (ehrenamtlichen) Tätigkeit erfährst zu behalten und „technische und organisatorische Maßnahmen“ treffen, um personenbezogene Daten zu schützen, z.B. personenbezogene Daten nur veschlüsselt auf privaten Geräten speichern.

Du schickst personenbezogene Daten einfach so unverschlüsselt an einen amerikanischen KI-Dienstleister, der wahrscheinlich noch sein Modell auf deiner Nutzung trainiert. Du machst dich mit sehr, sehr hoher Wahrscheinlichkeit strafbar. Das kann mit Freiheitsstrafe bis zu einem Jahr oder Geldstrafen geahndet werden.

So wie du schreibst, bist du offensichtlich nicht auf das Datengeheimnis verplichtet worden, weswegen ich dir ganz dringend raten würde mit den Verantwortlichen Personen in deine Gemeinde zu reden und zu fragen ob es eine verantwortliche Person für Datenschutz gibt und falls nein, warum nicht?

EDIT: nachdem ich mir dein Repo angeschaut habe, addressiere ich diesen Post auch an dich @samuelspagl