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).
{“content”:“Ik hoop wat deskundige ogen te werpen op problemen die ik ondervind bij het gebruik van Discourse als SSO-provider.\n\nMijn Doel: Ik ben bezig met het instellen van Discourse om authenticatie af te handelen voor een andere applicatie (LibreChat). Ik gebruik de standaard DiscourseConnect-providerfunctionaliteit, waarbij de OIDC-brugservice distrust fungeert als de client die communiceert met Discourse.\n\nHet Probleem: De SSO-stroom werkt perfect tot de allerlaatste stap. De gebruiker wordt correct omgeleid van mijn app naar Discourse en kan succesvol inloggen met hun Discourse-gegevens. Echter, na het inloggen, worden ze omgeleid naar de startpagina van mijn Discourse-forum (/) in plaats van naar de return_sso_url die werd verstrekt.\n\nWaar ik vastloop (Wat ik heb uitgesloten): Ik heb dit al een tijdje onderzocht en bevestigd dat dit geen eenvoudig configuratiefout is. Ik heb definitief het volgende uitgesloten:\n\n* Geheimen: De discourse connect provider secrets zijn correct geconfigureerd. Ik gebruik het platte domein (bijv. auth.my-site.com) zonder enig protocol, en de geheime sleutel komt perfect overeen met die in mijn client-service.\n* SSO-modus: Ik heb gecontroleerd of enable discourse connect provider is aangevinkt en dat de onjuiste "SSO Client"-instellingen zijn uitgeschakeld.\n* Gebruikersbeleid: Ik heb ervoor gezorgd dat must_approve_users is uitgeschakeld en mijn testgebruiker is een beheerder met een volledig geverifieerd e-mailadres.\n* Plugins: Ik heb alle niet-officiële plug-ins van derden uitgeschakeld en de container opnieuw opgebouwd, maar het probleem blijft bestaan.\n\nHet Belangrijkste Bewijs: Ik heb twee definitieve bewijsstukken die me verbijsteren:\n\n1. HAR-bestandanalyse: Ik heb de volledige netwerkstroom vastgelegd in een HAR-bestand. Het toont aan dat het POST-verzoek naar /session voor inloggen succesvol is. De server reageert onmiddellijk met een 302 Found-omleiding, maar de Location-header is consequent /. Dit bewijst dat Discourse de SSO-omleiding opzettelijk afbreekt.\n2. Leeg Rails-logboek: Ik heb vervolgens het production.log-bestand binnen de container gevolgd tijdens een inlogpoging. Er wordt absoluut niets naar het logboek geschreven tijdens dit proces. Dit vertelt me dat Discourse dit niet als een fout beschouwt; het is een doelbewuste, stille actie.\n\nMijn Vraag: Gezien het feit dat de inlogpoging succesvol is, maar de omleiding onjuist is en er geen fouten in de logboeken staan, welk intern Discourse-beleid, pre-flight check of verborgen instelling zou er dan voor kunnen zorgen dat de return_sso_url wordt genegeerd en in plaats daarvan naar de startpagina wordt omgeleid? Ik heb het gevoel dat ik alle standaardinstellingen heb uitgeput.\n\nAlvast bedankt voor alle ideeën!”,“target_locale”:“nl”}
