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).
Spero di ricevere un parere esperto sui problemi che sto riscontrando nell’utilizzo di Discourse come provider SSO.
Il mio obiettivo: Sto configurando Discourse per gestire l’autenticazione per un’altra applicazione (LibreChat). Sto utilizzando la funzionalità standard del provider DiscourseConnect, con il servizio bridge OIDC distrust che funge da client che comunica con Discourse.
Il problema: Il flusso SSO funziona perfettamente fino all’ultimo passaggio. L’utente viene reindirizzato correttamente dalla mia app a Discourse e può accedere con successo utilizzando le proprie credenziali Discourse. Tuttavia, dopo l’accesso, viene reindirizzato alla homepage del mio forum Discourse (/) invece che all’return_sso_url che era stato fornito.
Dove sono bloccato (Cosa ho escluso): Ho cercato di risolvere questo problema per un po’ e ho confermato che non si tratta di un semplice errore di configurazione. Ho definitivamente escluso quanto segue:
Segreti: I segreti del provider Discourse Connect sono configurati correttamente. Sto utilizzando il dominio semplice (ad esempio, auth.my-site.com) senza alcun protocollo e la chiave segreta corrisponde perfettamente a quella nel mio servizio client.
Modalità SSO: Ho verificato che abilita provider Discourse Connect sia selezionato e che le impostazioni errate di “Client SSO” siano disabilitate.
Criteri utente: Mi sono assicurato che must_approve_users sia disabilitato e che il mio utente di test sia un amministratore con un’e-mail completamente verificata.
Plugin: Ho disabilitato tutti i plugin di terze parti non ufficiali e ricostruito il container, ma il problema persiste.
Le prove chiave: Ho due prove definitive che mi lasciano perplesso:
Analisi del file HAR: Ho catturato l’intero flusso di rete in un file HAR. Mostra che la richiesta POST a /session per l’accesso ha successo. Il server risponde immediatamente con un reindirizzamento 302 Found, ma l’intestazione Location è costantemente /. Ciò dimostra che Discourse sta intenzionalmente interrompendo il reindirizzamento SSO.
Log Rails vuoto: Ho quindi monitorato il file production.log all’interno del container durante il tentativo di accesso. Non viene scritto assolutamente nulla nel log durante questo processo. Ciò mi dice che Discourse non lo considera un errore; è un’azione deliberata e silenziosa.
La mia domanda: Dato che l’accesso ha successo, ma il reindirizzamento è errato e non ci sono errori nei log, quale criterio interno di Discourse, controllo preliminare o impostazione nascosta potrebbe causare l’ignoranza dell’return_sso_url e il reindirizzamento alla homepage? Sento di aver esaurito tutte le impostazioni standard.
