Authentifizierung mittels OAuth2

bwl21

@fschrempf sagte in Authentifizierung mittels OAuth2:

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.

fschrempf

@bwl21 Ja, vielleicht sehe ich das kritischer als es wirklich ist. Wenn man den Timeout der Nextcloud-Session nicht zu groß wählt, so dass Nextcloud in regelmäßigen Abständen wieder einen OAuth-Request ausführt und aktuelle Daten bekommt, dann würde es wahrscheinlich sogar einigermaßen gut funktionieren. Danke für den Hinweis, ich werde mir das mal durch den Kopf gehen lassen.

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.

simsa

Mein Eindruck ist auch, dass allgemein mehr Anwendungen auf OIDC setzen als pures OAuth. Daher wünsche ich mir auch für Church Tools ein OpenID Support.

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.

Thomas Kuschan

Endlich, mich freut das OAuth2 Feature sehr. Für mich ist es endlich das Ende von vielen Bastellösungen. Auch wenn die Dokumentation nur auf die Integration von Nextcloud ausgelegt ist, konnte ich dank Standardisierung von OAuth2 ziemlich einfach einen Client programmieren: https://github.com/devdot/churchtools-oauth2-client

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?

davidschilling

@Thomas-Kuschan wie du es beschrieben hast ist es korrekt. Aktuell funktioniert der OAuth Access Token noch nicht für die CT-Api.
Das mit den Scopes ist leider etwas schwierig, weil die CT-Berechtigungen sich nicht so leicht in den Scopes abbilden lassen, zumindest habe ich noch keine gute Idee dafür.

Thomas Kuschan

@davidschilling Vielleicht übersehe ich hier auch etwas, aber mein Gedanke ist ganz einfach: der entsprechende OAuth Scope ermöglicht schlicht die gleichen CT-Berechtigungen wie der Zugriff per API (Token) – also genau mit den CT-Berechtigungen, die dem CT-Benutzer eben freigeschalten sind. Man könnte auch die einzelnen Module jeweils zu einen gesammelten Scope machen

gregorherr

@davidschilling sagte in Authentifizierung mittels OAuth2:

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?

simsa

Als Workaround hab ich mir ein Docker Image erstellt, dass ein OIDC mit Church Tools Social Login ermöglicht.

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

davidschilling

@simsa cool, hast du den Code dazu auch öffentlich?

simsa

@davidschilling aktuell ist der noch nicht öffentlich.

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 :-).

ckauhaus

@simsa Ja bitte

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

simsa

Hab es hier mal veröffentlicht

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

MichaelG

@simsa sagte in Authentifizierung mittels OAuth2:

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?

Welche Redirect URI muss ich bei CT eintragen, wenn der Proxy dazwischen ist?
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?
Was kommt in die einzelnen Felder beim Bild rein? Also bei der Anlage von OpenID auf MS Seite?

4e05cfa8-d45a-479b-9b28-cab35b6a386f-CleanShot 2025-07-24 at 13.04.31.png /Users/mgoth/Documents/CleanShot/CleanShot 2025-07-24 at 13.04.31.png

Vielen Dank für jede Hilfe.

simsa

@MichaelG

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

simsa

Hab jetzt mal noch Version 0.0.1 veröffentlicht, damit man für ein produkiven Betrieb nicht von einem latest Tag Update überrascht wird.

MichaelG

@simsa Hab vielen Dank! Wir werden es so ausprobieren.