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.
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!
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.
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).
J’espère avoir quelques avis d’experts sur les problèmes que je rencontre en essayant d’utiliser Discourse comme fournisseur SSO.
Mon objectif : Je configure Discourse pour gérer l’authentification d’une autre application (LibreChat). J’utilise la fonctionnalité standard du fournisseur DiscourseConnect, avec le service de pont OIDC distrust agissant comme client qui communique avec Discourse.
Le problème : Le flux SSO fonctionne parfaitement jusqu’à la toute dernière étape. L’utilisateur est correctement redirigé de mon application vers Discourse, et il peut se connecter avec succès à ses identifiants Discourse. Cependant, après la connexion, il est redirigé vers la page d’accueil de mon forum Discourse (/) au lieu de l’return_sso_url qui avait été fournie.
Là où je bloque (Ce que j’ai écarté) : J’ai passé beaucoup de temps à résoudre ce problème et j’ai confirmé qu’il ne s’agissait pas d’une simple erreur de configuration. J’ai définitivement écarté les points suivants :
Secrets : Les secrets du fournisseur Discourse Connect sont correctement configurés. J’utilise le domaine brut (par exemple, auth.my-site.com) sans aucun protocole, et la clé secrète correspond parfaitement à celle de mon service client.
Mode SSO : J’ai vérifié que activer le fournisseur Discourse Connect est coché, et que les paramètres incorrects de « Client SSO » sont désactivés.
Politiques utilisateur : Je me suis assuré que must_approve_users est désactivé, et que mon utilisateur de test est un administrateur avec un e-mail entièrement vérifié.
Plugins : J’ai désactivé tous les plugins tiers non officiels et reconstruit le conteneur, mais le problème persiste.
Les preuves clés : J’ai deux preuves définitives qui me laissent perplexe :
Analyse du fichier HAR : J’ai capturé l’intégralité du flux réseau dans un fichier HAR. Il montre que la requête POST vers /session pour la connexion réussit. Le serveur répond immédiatement avec une redirection 302 Found, mais l’en-tête Location est systématiquement /. Cela prouve que Discourse abandonne intentionnellement la redirection SSO.
Journal Rails vide : J’ai ensuite suivi le fichier production.log à l’intérieur du conteneur lors d’une tentative de connexion. Absolument rien n’est écrit dans le journal pendant ce processus. Cela me dit que Discourse ne considère pas cela comme une erreur ; c’est une action délibérée et silencieuse.
Ma question : Étant donné que la connexion réussit, mais que la redirection est incorrecte et qu’il n’y a aucune erreur dans les journaux, quelle politique interne de Discourse, vérification préalable ou paramètre caché pourrait l’amener à ignorer le return_sso_url et à rediriger vers la page d’accueil à la place ? J’ai l’impression d’avoir épuisé tous les paramètres standards.
