@Thomas-Kuschan wie du es beschrieben hast ist es korrekt. Aktuell funktioniert der OAuth Access Token noch nicht für die CT-Api.

Hallo! Ist es mittlerweile möglich, einen API Token mittels Oauth access_token zu holen oder sich damit an der API zu authentifizieren? Wenn nein, wann ist das eingeplant?

Welche Redirect URI muss ich bei CT eintragen, wenn der Proxy dazwischen ist?

Die URL wo der Docker Container deployed ist. Ich empfehle das ganze durch ein caddy Reverse Proxy mit https zu deployen.

https://sociallogin-to-oidc.deinedomain.de/login/oauth2/code/custom-client

OAUTH_SOCIAL_LOGIN_SECRET= -> hier denke ich mir was aus, aber an welcher Stelle kommt das zum Einsatz? Bei Add OpenID von MS?

Das kommt zum Einsatz wenn sociallogin-to-openidconnect zum Church Tools Account weiterleitet

OAUTH_SOCIAL_LOGIN_REDIRECTURI=/login/oauth2/code/custom-client -> Hier hab ich die Doku so verstanden, dass dies die Subdomain ist, unter der der Docker öffentlich erreichbar ist? Und wieder: Wo trage ich das dann ein? Bei CT, bei Entra?

Ja das ist die URL unter der der Docker Container erreichbar ist. Die gleiche Url wie bei der ersten Frage (https://sociallogin-to-oidc.deinedomain.de/login/oauth2/code/custom-client)

OPENID_SUB=email -> das verstehe ich so, dass hier das Mapping zwischen ChurchTools und Entra stattfindet und Email eine gute Wahl wäre?

Das ist der Nutzername der am Ende in "sub" bei OpenID Connect steht. Mit diesem Nutzernamen matched man dann zwischen Church Tool sud zb. Entra.
Man kann hier wählen zwischen e-mail, nutzernamen oder der church tools id

OPENID_ISSUER= -> Hier hätte ich die gleiche Subdomain wie oben genommen, wo der Docker drauf läuft?

Genau, nur die Domain, in meinem Beispiel jetzt
https://sociallogin-to-oidc.deinedomain.de

OPENID_CLIENT_ID= hier erfindet ich was und trage es dann bei Add Open ID bei MS ein?
ja genau

OPENID_CLIENT_SECRET=das gleich auch hier?
ja genau

OPENID_REDIRECT_URI= Was kommt hier rein? Und wo muss ich das wieder eintragen?
Da wirst du hingeleitet, wenn der Login erfolgreich war.

zu 3:

well-known: https://sociallogin-to-oidc.deinedomain.de/.well-known/openid-configuration

Issuer URI: https://sociallogin-to-oidc.deinedomain.de

Client ID: Die ID die du selbst vergeben hast
secret: was du selsbt vergeben hast

scope: openid profile email

Hab es hier mal veröffentlicht

https://github.com/canchanchara/sociallogin-to-openidconnect/

Vielen Dank!

Ich würde das gerne mit EntraID nutzen (spricht nur OpenID).

Könntest du mir helfen, wo ich was eintragen muss?

1. Welche Redirect URI muss ich bei CT eintragen, wenn der Proxy dazwischen ist?

2. Mir ist noch nicht ganz klar, was in deiner Config an diese Stellen muss:

   • OAUTH_SOCIAL_LOGIN_SECRET= -> hier denke ich mir was aus, aber an welcher Stelle kommt das zum Einsatz? Bei Add OpenID von MS?
   • OAUTH_SOCIAL_LOGIN_REDIRECTURI=/login/oauth2/code/custom-client -> Hier hab ich die Doku so verstanden, dass dies die Subdomain ist, unter der der Docker öffentlich erreichbar ist? Und wieder: Wo trage ich das dann ein? Bei CT, bei Entra?
   • OPENID_SUB=email -> das verstehe ich so, dass hier das Mapping zwischen ChurchTools und Entra stattfindet und Email eine gute Wahl wäre?
   • OPENID_ISSUER= -> Hier hätte ich die gleiche Subdomain wie oben genommen, wo der Docker drauf läuft?
   • OPENID_CLIENT_ID= hier erfindet ich was und trage es dann bei Add Open ID bei MS ein?
   • OPENID_CLIENT_SECRET=das gleich auch hier?
   • OPENID_REDIRECT_URI= Was kommt hier rein? Und wo muss ich das wieder eintragen?

3. Was kommt in die einzelnen Felder beim Bild rein? Also bei der Anlage von OpenID auf MS Seite?

/Users/mgoth/Documents/CleanShot/CleanShot 2025-07-24 at 13.04.31.png

Vielen Dank für jede Hilfe.

https://github.com/canchanchara/sociallogin-to-openidconnect/

Der Code muss auch nicht perfekt sein. Wenn er erst einmal auf GitLab/GitHub/... ist, können andere auch mithelfen und PRs einsteuern.

Muss das noch etwas bereinigen. Hab das für unsere Gemeinde intern entwickelt.

Wenn es für Church Tools hilft, dass dadurch schneller OIDC nativ kommt, kann ich das evtl beschleunigen :-).

https://hub.docker.com/r/zendem/sociallogin-to-openidconnect

Die App verbindet sich dann gegen diesen Docker Container mit OIDC, der sich dann wieder zu Church Tools verbindet.

Beispiel Docker Compose

services:
  sociallogintoopenid:
    image: zendem/sociallogin-to-openidconnect:latest
    environment:
      - OAUTH_SOCIAL_LOGIN_CLIENT_ID=secretFromOauthSociaLogin
      - OAUTH_SOCIAL_LOGIN_SECRET=randomString123
      - OAUTH_SOCIAL_LOGIN_REDIRECTURI=https://openid-church.example.org/login/oauth2/code/custom-client
      - OAUTH_SOCIAL_LOGIN_AUTHORIZATION_URI=https://yourchurch.church.tools/oauth/authorize
      - OAUTH_SOCIAL_LOGIN_TOKEN_URI=https://yourchurch.church.tools/oauth/access_token
      - OAUTH_SOCIAL_LOGIN_USER_INFO_URI=https://yourchurch.church.tools/oauth/userinfo
      - OPENID_ISSUER=https://openid-church.example.org
      - OPENID_CLIENT_ID=oidc-client
      - OPENID_CLIENT_SECRET=topSecret123
      - OPENID_REDIRECT_URI=https://yourapp.example.org/oauth2/callback
    ports:
      - "8080:8080"
    restart: unless-stopped

Bei der Landeskirche Würrtemberg funktioniert das über SAML. Die Anbindung ist bisher spezifisch für die Landeskirche, wenn es dafür von anderen noch Bedarf gibt kann man darüber aber sicher nachdenken.

@simsa sagte in Authentifizierung mittels OAuth2:

Daher wünsche ich mir auch für Church Tools ein OpenID Support.

Ich würde mir auch sehr wünschen, dass CT noch SAML und OIDC unterstützt... Das würde vieles einfacher machen & dem Account-Dschungel bei mehreren Diensten ein endgültiges Ende bereiten.

Gibt es eine Hoffnung ob und wann das kommen könnte?

Erhofft hatte ich mir trotzdem, dass man mit OAuth auf andere Ressourcen zugreifen kann. Bisher geht es nicht, den User-Token zur Authorisierung der API zu verwenden – das wäre in meinen Augen großartig (natürlich mit entsprechenden Scopes etc.). Ist hier noch mehr geplant?

Aktuell sieht meine Lösung für eigene Integrationen so aus, dass ich dank der neuen OAuth Schnittstelle die CT-User sauber authentifizieren kann und dann wie bisher mit einem API-User die tatsächliche Interaktion mit CT erledige. Wenn ich aber die API mit dem jeweiligen CT-User nutzen möchte (z.B. /api/persons), muss ich weiterhin einem API-User die Admin-Rechte geben, mit denen dieser dann die API-Tokens aller CT-Benutzer organisieren kann. Technisch wäre es viel sauberer, wenn ich ohne einen solchen Admin-API-User an die API-Tokens der CT-User kommen könnte. Oder übersehe ich hier eine Funktion der OAuth Schnittstelle?

Die Social Login App von Nextcloud funktioniert grundsätzlich. Allerdings habe ich Bedenken bzgl. des langfristigen Supports. Das Plugin wird nicht direkt von Nextcloud gewartet. Die OIDC App allerdings schon.

Dh. es könnte sein, dass das Social Plugin von dem externen Entwickler eingestellt wird und man dann schwierigkeiten bekommen kann, Nextcloud zu aktualisieren bzw. die User auf ein anderes Plugin zu migrieren.

Das ist aber ein ganz anderes Thema. Wie gesagt akzeptieren viele Dienste nur einen Meta-Endpoint (well-known), bzw. selbst wenn direkt die OAuth-Endpoint-URLs angegeben werden können, macht ein Meta-Endpoint die Konfiguration deutlich einfacher.

Würde ... Für die Praxis ist diese Variante m. E. komplett untauglich.

Das kann man so sehen, muss es aber nicht. Es geht darum dass der Benutzer im Drittsystem in die Rechte eintritt, die in CT dokumentiert sind. Das ist gegebn.

Wen ich wissen will,in welchen Gruppen er ist, schaue ich in CT nach. Es ist ja nicht so dass er im Drittsystem CT-Gruppen hat, die eer in CT nicht mehr hat.

Darum CT ist das Leitsystem.

Würde man nur LDAP nutzen, hätte man kein SSO. Würde man nur OAuth nutzen, werden immer nur beim Login die Gruppenzugehörigkeiten des jeweiligen Users synchronisiert. Wenn es viele User gibt, die sich nur selten anmelden, dann hat man im entsprechenden Dienst ständig inkonsistente Daten. In ChurchTools wurden z. B. User-Profildaten und Gruppenzugehörigkeiten geändert, aber das kommt im Dienst erst an, wenn sich alle User die von den Änderungen betroffen sind einmal neu angemeldet haben. Für die Praxis ist diese Variante m. E. komplett untauglich.

In diesem Thread geht vieles durcheinander, deshalb versuche ich mal ein paar Grundsätze darzulegen, um dann meine Empfehlung/Wünsche an den CT Product-Owner zu formulieren...

CIAM steht für "Customer Identity & Access Management". CIAM ist also ein organisationsweites System, mit dem jegliche Benutzerkonten und Zugangsdaten und Berechtigungen für jegliche Applikationen einer Organisation verwaltet werden können. Damit verbunden sind dann auch Themen wie "SSO - Single Sign On" (einmalige Anmeldung gilt für alle angebundenen und berechtigten Applikationen), ("MFA - Multi Factor Authentication" - erhöhte Sicherheit zur Vermeidung von Identitäts-Diebstahl), oder eben auch die organisationsweite DSGVO konforme Erfassung von Benutzerdaten, samt Einwilligungserklärung etc.
CIAM Tools stellen für anzuschliessende Anwendungen wie z.B. Church-Tools standardisierte Authentifizierungsdienste zur Verfügung (authentication service provider). Die gängigen Standards dafür sind u.a. "OpenID Connect", "SAML" oder eben "OAuth2" (mit dem dieser Thread ja gestartet ist). Church-Tools wäre in einem solchen Szenario also der "authentication client", der die Authentifikations-Anfragen dann z.B. per OAuth2 an den Identity Provider (das organisationsweite CIAM-Tool) weiterleitet.

In diesem Thread wird vielmehr aber diskutiert, dass Church Tools die Funktion des Identity Providers (also dem CIAM-Tool) übernehmen sollte. Eine Solche CIAM Funktionalität zu implementieren, die allen Sicherheitsanforderungen genügt, ist ganz sicher komplex und entspricht nicht der fachlichen Domäne von Church-Tools. Es gibt bereits eine Vielzahl professioneller CIAM Tools, sowohl kommerziell (z.B. das in diesem Thread immer wieder zitierte Microsoft AD (Acrive Directory) oder noch umfassender dem Microsoft ENTRA External ID oder ...) als auch OpenSource Produkte wie dem im Thread schon benannten Keycloak (siehe keycloak.org). Es bleibt also jeder Organisation überlassen, welche CIAM-Software am besten zur bestehenden Infrastruktur passt...
Aus meiner Sicht, macht es keinen Sinn, dass Church-Tools die Funktion eines Identity Providers (CIAM) implementiert, weil andere das Thema schon sehr professionell abliefern...

Mein Wunsch an den ChurchTools Product Owner

Stattdessen ist die sicherlich einfacher zu implementierende und standardisierte Authentifikations-Schnittstelle zur Anbindung an ein bestehendes Identity Access Managements seit langem überfällig. Das würde eben die Integration eines Authentifizierungsdienstes, auf der Grundlage von wahlweise OAuth2 oder SAML oder OpenID-Connect bedeuten - also genau das, was im Titel dieses Threads steht "Authentifizierung mittels OAuth2".

Ich würde mich sehr freuen, wenn es seitens CT hier Fortschritte oder zumindest konkrete Aussagen für eine Roadmap gäbe, da es gerade in Gemeinden zunehmend schwieriger wird, dezentrale Benutzerkonten zu managen und dies den ehrenamtlichen Mitarbeiter*innen (oftmals IT-Laien) zuzumuten...

Besten Dank schon mal im Namen der Kirche Lindenwiese (Überlingen)
Wolfgang Merkel

@wolfgang-merkel du sprichst mir auf der Seele. Als ich mitbekommen habe dass CT jetzt eine Identity Provider Funktion mitbringt hatte ich genau die Gedanken du gut formuliert hast - außer das Gendersterchen
Liebe CT Team, CT als Auth Client in bestehende CIAM Systeme zu hängen ist der Weg.

Leider bleibt es noch ein bisschen hinter meinen Erwartungen zurück. Die Konfiguration eines Clients stellt entsprechende Endpoint-URLs zur Verfügung. Im Beispiel werden diese für Nextcloud mit der Erweiterung "Sociallogin" verwendet. Das funktioniert prinzipiell.

Viele andere Dienste erwarten jedoch, dass der Provider eine "well-known" URL gemäß OIDC Spezifikation bereitstellt unter der dann die Metadaten (Endpoints, Attribute, etc.) abgerufen werden können und erlauben es nicht direkt die Enpoint-URLs anzugeben. Wir nutzen aktuell folgende Dienste, die somit nicht funktionieren und deshalb momentan weiterhin über Keycloak (mit dem CT User Provider) bedient werden müssen.

• Nextcloud mit oidc-login Erweiterung, die es erlaubt LDAP und OAuth bequem zu kombinieren
• OwnCloud Infinite Scale (oCIS)

Daher wäre mein Wunsch diese Möglichkeit in Zukunft vorzusehen um damit auch die breite Masse an Diensten, die es so gibt an CT anbinden zu können. Danke!

https://blog.church.tools/blog/v3-116-registrieren-oauth-provider-camt-053-und-paypal/

Auf einer Testinstallation hat es bei mir schon funktioniert

Hier gibts die Anleitung von Church Tools

https://churchtools.academy/de/help/verwaltung/oauth/login-bei-drittsystem-nextcloud-einrichten-oauth/

Wenn CT als Leitsystem verstanden wird, in der alle Personenbezogenen Daten gepflegt werden, liegt es nahe das auch zur Authentifizierung zu verwenden. Sonst musst du die Personendaten synchronisieren, das ist auch nicht sooo einfach

Aus meiner Sicht, macht es keinen Sinn, dass Church-Tools die Funktion eines Identity Providers (CIAM) implementiert, weil andere das Thema schon sehr professionell abliefern...

Das Argument ist schwierig, weil es für fast alle Funktionen von CT sicher irgendeinen gibt, der das "professionell abliefert" . Am Ende hast du x Systeme die irgendwas "professionell abliefern" und keine Integration mehr.