Misstrauen: Discourse als OpenID Connect-Anbieter

If you ever wanted to use Discourse as your authentication provider - now you can!

Over the last week I’ve written a small service which can be used to act as an OpenID connect/OAuth provider with discourse as a backend.

You can check out the code here:

Note that my primary use case was to authenticate to Nextcloud using Discourse, so it might not be working for your use case.

If something is not working as expected, or it is missing that certain feature to make it work for you, feel free to create an issue in the GitHub repository.

18 „Gefällt mir“

Awesome initiative! I always wanted Discourse to be usable as an OAuth provider, so it can easily be integrated with more tools. Making it an external small service makes a lot of sense too!

6 „Gefällt mir“

I like the sound of this and hope some communities decide to try it out!

I’d love to see OIDC supported by Discourse officially in addition to our bespoke Discourse Connect functionality, so we can offer a turnkey solution to our customers on standard and teams without having to rely on okta or the like.

7 „Gefällt mir“

This is super cool! Thanks for doing this!

I would really like to see this built in to Discourse so that it could be its own OIDC provider!

5 „Gefällt mir“

Awesome, I love that it allows access by group.

1 „Gefällt mir“

@theSuess I am using discourse as stand alone then how Can I configure it?
image


Distrust is a separate service, so you need to deploy it as such. You can run it in a container as described in the README file. Note that for secure operation, you will also need a reverse proxy handling SSL Termination (I might implement this directly sometime in the future).

2 „Gefällt mir“

Ich hoffe, einige Expertenaugen auf die Probleme zu werfen, mit denen ich konfrontiert bin, während ich versuche, Discourse als SSO-Anbieter zu verwenden.

Mein Ziel: Ich richte Discourse ein, um die Authentifizierung für eine andere Anwendung (LibreChat) zu handhaben. Ich verwende die Standardfunktionalität des DiscourseConnect-Anbieters, wobei der OIDC-Bridge-Dienst distrust als Client fungiert, der mit Discourse kommuniziert.

Das Problem: Der SSO-Flow funktioniert perfekt bis zum allerletzten Schritt. Der Benutzer wird korrekt von meiner App zu Discourse weitergeleitet und kann sich erfolgreich mit seinen Discourse-Anmeldeinformationen anmelden. Nach der Anmeldung wird er jedoch zu meiner Discourse-Forum-Homepage (/) weitergeleitet und nicht zur angegebenen return_sso_url.

Wo ich feststecke (Was ich ausgeschlossen habe): Ich habe dies eine Weile lang behoben und bestätigt, dass es sich nicht um einen einfachen Konfigurationsfehler handelt. Ich habe Folgendes definitiv ausgeschlossen:

  • Secrets: Die discourse connect provider secrets sind korrekt konfiguriert. Ich verwende die reine Domain (z. B. auth.my-site.com) ohne Protokoll, und der geheime Schlüssel stimmt perfekt mit dem in meinem Client-Dienst überein.
  • SSO-Modus: Ich habe bestätigt, dass enable discourse connect provider aktiviert ist und die falschen “SSO Client”-Einstellungen deaktiviert sind.
  • Benutzerrichtlinien: Ich habe sichergestellt, dass must_approve_users deaktiviert ist, und mein Testbenutzer ist ein Administrator mit einer vollständig verifizierten E-Mail-Adresse.
  • Plugins: Ich habe alle nicht-offiziellen Plugins von Drittanbietern deaktiviert und den Container neu erstellt, aber das Problem besteht weiterhin.

Die wichtigsten Beweise: Ich habe zwei definitive Beweise, die mich ratlos machen:

  1. HAR-Datei-Analyse: Ich habe den gesamten Netzwerkfluss in einer HAR-Datei erfasst. Sie zeigt, dass die POST-Anfrage an /session für die Anmeldung erfolgreich ist. Der Server antwortet sofort mit einem 302 Found-Redirect, aber der Location-Header ist durchweg /. Dies beweist, dass Discourse den SSO-Redirect absichtlich abbricht.
  2. Leeres Rails-Log: Ich habe dann die Datei production.log im Container verfolgt, während ich einen Login versucht habe. Während dieses Vorgangs wird absolut nichts in das Log geschrieben. Das sagt mir, dass Discourse dies nicht als Fehler betrachtet; es ist eine bewusste, stille Aktion.

Meine Frage: Angesichts der Tatsache, dass die Anmeldung erfolgreich ist, aber der Redirect falsch ist und keine Fehler in den Logs vorhanden sind, welche interne Discourse-Richtlinie, Vorabprüfung oder versteckte Einstellung könnte dazu führen, dass die return_sso_url ignoriert und stattdessen zur Homepage weitergeleitet wird? Ich habe das Gefühl, dass ich alle Standardeinstellungen ausgeschöpft habe.

Vielen Dank im Voraus für alle Ideen!