# Fiducia: Discourse come provider OpenID Connect

**URL:** https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385
**Category:** Extras
**Created:** [29 Giugno 2021, 5:24pm UTC](https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385 "2021-06-29T17:24:42Z")
**Posts on this page:** 8
**Page:** 1

<div class="post-metadata">

### Author: ![theSuess](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/thesuess/32/214128_2.png) [@theSuess](https://meta.discourse.org/u/theSuess)
#### Post date: [29 Giugno 2021, 5:24pm UTC](https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385/1 "2021-06-29T17:24:42Z")

</div>

Se volevi sempre usare Discourse come provider di autenticazione, ora puoi!

Nell’ultima settimana ho scritto un piccolo servizio che può fungere da provider OpenID Connect/OAuth con Discourse come backend.

Puoi consultare il codice qui:

> **[GitHub - Parkour-Vienna/distrust: Use discourse as an OIDC (OAuth 2.0) provider](https://github.com/Parkour-Vienna/distrust)**
>
> Use discourse as an OIDC (OAuth 2.0) provider

Tieni presente che il mio caso d’uso principale era l’autenticazione su Nextcloud tramite Discourse, quindi potrebbe non funzionare per il tuo caso specifico.

Se qualcosa non funziona come previsto o manca quella determinata funzionalità per farlo funzionare per te, sentiti libero di aprire un issue nel repository GitHub.

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [29 Giugno 2021, 6:27pm UTC](https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385/3 "2021-06-29T18:27:52Z")

</div>

Iniziativa fantastica! Ho sempre voluto che Discourse fosse utilizzabile come provider OAuth, in modo da poter essere integrato facilmente con più strumenti. Renderlo un servizio esterno di piccole dimensioni ha molto senso anche!

---

<div class="post-metadata">

### Author: ![tobiaseigen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tobiaseigen/32/539204_2.png) [@tobiaseigen](https://meta.discourse.org/u/tobiaseigen)
#### Post date: [29 Giugno 2021, 10:19pm UTC](https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385/4 "2021-06-29T22:19:45Z")

</div>

Mi piace come suona e spero che alcune comunità decidano di provarlo!

Mi piacerebbe vedere OIDC supportato ufficialmente da Discourse, oltre alla nostra funzionalità personalizzata [Discourse Connect](https://meta.discourse.org/t/13045?silent=true), in modo da poter offrire una soluzione pronta all’uso ai nostri clienti sui piani Standard e Teams, senza dover fare affidamento su Okta o simili.

---

<div class="post-metadata">

### Author: ![aaronpk](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/aaronpk/32/149994_2.png) [@aaronpk](https://meta.discourse.org/u/aaronpk)
#### Post date: [26 Agosto 2021, 11:17pm UTC](https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385/8 "2021-08-26T23:17:00Z")

</div>

È super figo! Grazie per averlo fatto!

Mi piacerebbe davvero vederlo integrato in Discourse in modo che possa diventare un proprio provider OIDC!

---

<div class="post-metadata">

### Author: ![sunjam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sunjam/32/175682_2.png) [@sunjam](https://meta.discourse.org/u/sunjam)
#### Post date: [28 Agosto 2021, 2:27pm UTC](https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385/9 "2021-08-28T14:27:59Z")

</div>

Fantastico, adoro che permetta l’accesso per gruppo.

---

<div class="post-metadata">

### Author: ![Rajeev](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rajeev/32/231379_2.png) [@Rajeev](https://meta.discourse.org/u/Rajeev)
#### Post date: [6 Settembre 2021, 12:54pm UTC](https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385/10 "2021-09-06T12:54:57Z")

</div>

@theSuess Sto usando Discourse come applicazione standalone, quindi come posso configurarlo?

 ![image](https://global.discourse-cdn.com/meta/original/3X/d/2/d20e8ed9eed622132817c876e8ec5f9fea69b9b5.png)  
 ![image](https://global.discourse-cdn.com/meta/original/3X/3/4/341fc2785a789e458b3700aa12ac676405895dcc.png)  
 ![image](https://global.discourse-cdn.com/meta/original/3X/2/5/25cb90c110a5d9bb7a9d98fdf7a7a234d5714ab4.png)

---

<div class="post-metadata">

### Author: ![theSuess](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/thesuess/32/214128_2.png) [@theSuess](https://meta.discourse.org/u/theSuess)
#### Post date: [6 Settembre 2021, 3:18pm UTC](https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385/11 "2021-09-06T15:18:13Z")

</div>

Distrust è un servizio separato, quindi devi distribuirlo come tale. Puoi eseguirlo in un contenitore come descritto nel file README. Tieni presente che, per un’operazione sicura, avrai anche bisogno di un reverse proxy che gestisca la terminazione SSL (potrei implementarlo direttamente in un futuro).

---

<div class="post-metadata">

### Author: ![BrianC](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/brianc/32/487568_2.png) [@BrianC](https://meta.discourse.org/u/BrianC)
#### Post date: [1 Settembre 2025, 3:35am UTC](https://meta.discourse.org/t/distrust-discourse-as-an-openid-connect-provider/195385/12 "2025-09-01T03:35:15Z")

</div>

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:

1. **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.
2. **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.

Grazie in anticipo per qualsiasi idea!
