Discourse OpenID Connect (OIDC)

[Discourse]

	Summary	Discourse OpenID Connect allows an OpenID Connect provider to be used as an authentication provider for Discourse.
	Install Guide	This plugin is bundled with Discourse core. There is no need to install the plugin separately.

As this is an official plugin maintained by the Discourse team, Bug, UX, and Feature requests can be made in the respective categories here on Meta, and tagged with the appropriate plugin tag. Support is offered in SSO. Click on a link below to get one started.

 Support  Bug  UX  Feature

Features

The plugin aims to provide a minimal implementation of the specification. Specifically, it supports the “Authorization Code Flow”. To get started, follow the plugin installation instructions, or contact your hosting provider.

Our oauth2-basic plugin can be used for connecting to some openid-connect providers (OpenID Connect is based on OAuth2). However, this plugin should require far less manual configuration, and can make use of the JWT “ID Token” if a JSON API is not available.

Configuration is automatically performed using an OpenID Connect Discovery Document. According to the specification, this should be located at <issuer domain>/.well-known/openid-configuration, but Discourse supports any path to allow for non-compliant implementations (e.g. Azure B2C). The discovery document is cached for 10 minutes, to improve performance on high-traffic sites.

If the discovery document includes a userinfo_endpoint parameter, then the plugin will use that to collect user metadata. If not, the plugin will extract metadata from the id_token (A JWT) supplied by the token endpoint. The plugin DOES NOT verify the authenticity of the JWT signature, as this would significantly increase complexity. This decision is supported by the specification:

If the ID Token is received via direct communication between the Client and the Token Endpoint (which it is in this flow), the TLS server validation MAY be used to validate the issuer in place of checking the token signature.

Configuration

Basic Configuration Options

• openid_connect_enabled: Enable OpenID Connect authentication

• openid_connect_discovery_document: OpenID Connect discovery document URL. Normally located at https://your.domain/.well-known/openid-configuration

• openid_connect_client_id: OpenID Connect client ID

• openid_connect_client_secret: OpenID Connect client secret

• openid connect rp initiated logout: Redirect the user to end_session_endpoint after logout. Must be supported by your identity provider and included in the discovery document.

• openid connect rp initiated logout redirect: (optional) The post_logout_redirect_uri which will be passed to the logout endpoint. If provided, it must be registered with the identity provider.

• openid_connect_authorize_scope: The scopes sent to the authorize endpoint. This must include ‘openid’

• openid_connect_use_pkce: Enable Proof Key for Code Exchange (PKCE) for OpenID Connect authentication.

• openid_connect_verbose_logging: Log detailed openid-connect authentication information to /logs. Keep this disabled during normal use.

Advanced Configuration Options

• openid_connect_token_scope: The scopes sent when requesting the token endpoint. The official specification does not require this.

• openid_connect_error_redirects: If the callback error_reason contains the first parameter, the user will be redirected to the URL in the second parameter. Used for unusual implementations that send errors in response to user input (e.g. Azure B2C)

• openid_connect_allow_association_change: Allow users to disconnect and reconnect their Discourse accounts from the OpenID Connect provider

Example setup

Here we will set up the openid-connect plugin to connect to Google’s OpenID Connect provider. This replicates functionality that already exists in the core of Discourse, but it serves as an accessible example.

1. Head to OpenID Connect  |  Sign in with Google  |  Google for Developers and follow the instructions to obtain OAuth Credentials.

2. On the same page, follow the instructions to add a redirect URI. This should be https://<your_forum>/auth/oidc/callback (without a trailing slash)

3. Go to your Discourse site settings and search for “openid_connect”

   • openid connect enabled:

   • openid connect discovery document: https://accounts.google.com/.well-known/openid-configuration

   • openid connect client id: <client-id>

   • openid connect client secret: <client-secret>

   • openid connect authorize scope: openid email (with a space in between)

4. You’re done. The “Login with OpenID Connect” button will now log in using Google . These same steps can be applied to other providers, with very minimal changes.

Debugging

In addition to the verbose_logging setting described above, you can access data about OIDC associations using the data-explorer plugin:

SELECT user_id, provider_name, provider_uid
FROM user_associated_accounts
WHERE provider_name = 'oidc'

Or on the rails console:

User.find_by_username("david").user_associated_accounts.where(provider_name: 'oidc')

Provider Specific Notes

Please feel free to update this if you find any provider-specific quirks relating to this integration:

Entra ID (formerly Azure AD)

Add the email scope, and make sure you’re using the version 2 endpoint configuration document. For example

https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration

@andy.czerwonka

• Make sure you use v2.0 of the configuration endpoint as per the notes above. The default v1.0 endpoint does not support email or profile scope .
• If there are issues with the client secret, try generating a new one. We had some issues, but after generating a couple it seemed just fine.
• Make sure you turn on “Sign in and read user profile” as a “Delegated Permission” in Azure AD when creating the entry for your site.
• Make sure you add the correct callback, which is ‘https://your-site/auth/oidc/callback’

Azure B2C

The discovery document URL details can be found here: Web sign in with OpenID Connect - Azure AD B2C | Microsoft Learn

For example, the metadata document for the b2c_1_sign_in user flow in fabrikamb2c.onmicrosoft.com is located at:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=b2c_1_sign_in

To make emails work:

@Umer_Nawab

To get email in claims, you will have to use custom policies. To achieve that, I used the policies starter pack mentioned here:

Tutorial - Create user flows and custom policies - Azure Active Directory B2C | Microsoft Learn

After implementing the steps mentioned in above article, email claim started appearing when user signed up but when an existing user signed in, the email claim was missing from token. Then I had to make some changes in the custom policy xml file by following the steps mentioned in this post:

Email claims not populated with custom policies in Azure B2C - Stack Overflow

After these changes, email claim is now appearing when the user signs up and also when user signs in.

Yahoo

1. Head to Login - Sign in to Yahoo and create a new app

2. Enter the Application Name, and set the callback domain to your forum domain (e.g. meta.discourse.org)

3. Under API Permissions, choose Profiles: Read/Write Public and Private. This is the only way I know of to obtain the user email address

4. Save the app

5. In the Discourse OIDC settings, set the discovery document to

   https://login.yahoo.com/.well-known/openid-configuration
   

6. Enter the client ID and secret from Yahoo

7. Enable the OIDC plugin

AWS Cognito

1. Go to Cognito and select or create a new user pool.
2. Define an app in App clients.
3. Leave everything to default, but change Auth Flows Configuration to only select ALLOW_REFRESH_TOKEN_AUTH.
4. Go to app client settings and select the new app.
5. Change the callback URL to https://yoursite.example.com/auth/oidc/callback.
6. Only check the Authorization code grant flow among “Allowed OAuth Flows”.
7. Check all scopes needed (I have all checked).

Okta

1. Configure Discourse with your Okta app client ID and secret

2. Set the discovery document URL to

   https://{your-app}.okta.com/.well-known/openid-configuration
   

3. In Discourse, set the openid connect authorize scope to openid email

Hosted by us? This plugin is available on our Business and Enterprise plans. OAuth 2.0 & OpenID Connect Support | Discourse - Civilized Discussion

Last edited by @pedro 2025-08-29T23:26:31Z

Check document

Perform check on document:

[Ramón]

Ciao,
stiamo utilizzando il plugin di autenticazione OpenID Connect con un’installazione Discourse su AWS.
Abbiamo distribuito i container Discourse, Discourse Sidekiq e Redis (basati su Bitnami, ma non cacciatemi ;)). Il DB è in esecuzione su AWS RDS. Usiamo KeyCloak.

Le cose funzionano.

Ma a volte, dopo un riavvio dell’attività AWS di Discourse, succede che pensa di avere il documento di discovery nella cache, ma poi non c’è nessun documento lì. E non tenta di recuperarlo nuovamente da KeyCloak:

OIDC Log: Discovery document loaded from cache
OIDC Log: Discovery document is
---
(oidc) Request phase initiated.
(oidc) Authentication failure! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError, Discovery document is missing

Nell’app del browser vedo: Impossibile recuperare la configurazione dall’identity provider. Riprova.

Cosa puoi consigliare?

[Tomáš_Guba]

Ciao,

C’è un modo per impostare la sorgente dell’avatar utente di Discourse su un campo specificato nel servizio openID?

Modifica: stiamo usando keycloak

[gmoirod (Guillaume Moirod)]

Ciao,

Ho un requisito simile a quello di @Tomáš_Guba: vorrei ottenere un valore da una voce personalizzata nel profilo utente e utilizzarlo in un campo utente [personalizzato].

Nel mio caso specifico, ho un documento di discovery con un userinfo_endpoint

C’è qualcosa di simile nella roadmap del plugin?

Grazie

[Rubens_Flinco]

Ciao, sono riuscito a far funzionare il plugin con il mio SSO openID ma non viene compilato nel campo nome utente dell’altro sistema o email tra gli altri campi…

Immagino che dovrei configurare qualcosa nel campo “rivendicazioni openid connect”, ma non so come configurare direttamente questo campo. Qualcuno può darmi un esempio? Ecco alcune stampe di come è il mio progetto:
https://imgur.com/gallery/LWvkJUV

[snikch (Mal Curtis)]

C’è un modo per evitare di “perdere” il percorso originale quando si accede a un post privato?

Se visitiamo una pagina privata e clicchiamo su uno dei pulsanti di accesso presenti in quella pagina, quando veniamo reindirizzati al sito, finiamo sulla pagina delle categorie.

[Hyan]

Ciao @david,

Puoi per favore dare un’occhiata al problema menzionato nel seguente post? Vorrei usare il plugin OIDC invece di OAuth basic. Ma riscontro lo stesso problema: non riesco a passare parametri alla richiesta /authorize. Ho inserito il valore nel plugin nel formato foo=bar.

Cannot add additional parameters to authorize endpoint

I switched to the Oauth2 Basic plugin. Problem solved.

[JJ_IA]

Non sono riuscito a farlo funzionare su LinkedIn. Qualcun altro ci è riuscito? Riesco ad accedere a LinkedIn dopo essere stato reindirizzato lì quando clicco sul pulsante “accedi con…” e poi “autorizzo” la mia app a usare la mia email da LinkedIn, poi ricevo “Spiacenti, si è verificato un errore durante l’autorizzazione del tuo account. Riprova.”

https:/discourse.mysite.com/auth/failure?message=invalid_credentials&origin=https%3A%2F%2Fdiscourse.mysite.com%2F&strategy=oidc

[JJ_IA]

Ho ancora problemi con questo. Ricevo il seguente errore:

(oidc) Authentication failure! invalid_credentials: OAuth2::Error, invalid_request: A required parameter "client_secret" is missing {"error":"invalid_request","error_description":"A required parameter

È un errore di omniauth e sembra essere correlato [potenzialmente] a questo: No longer works with oauth2 gem v2.0+ · Issue #68 · decioferreira/omniauth-linkedin-oauth2 · GitHub

L’aiuto è apprezzato!

[Discoder (Hector)]

Ricevo i seguenti errori:

(oidc) Authentication failure! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError, Discovery document is missing

OIDC Log: Fetching discovery document raised error Faraday::ConnectionFailed FinalDestination: lookup failed

Ho impostato il plugin “openid connect discovery document” nelle Impostazioni di amministrazione come: https://<auth_provider>/.well-known/openid-configuration e riesco a raggiungerlo con successo nel container Docker dell’app in esecuzione con un comando Curl e persino nella console Rails.

Hai qualche idea sul motivo per cui ricevo questi errori? Non riesco a integrarmi correttamente a causa di ciò. Inoltre, mi trovo dietro la intranet e utilizzo un proxy aziendale, se questo può essere d’aiuto. Come ho detto, con il proxy abilitato nell’ENV del container, posso raggiungere correttamente l’URL “openid connect discovery document”.

[weber-s (Samuël Weber/GwendalD)]

Ciao!

Nuova domanda: questo plugin gestisce la gestione delle sessioni? (Final: OpenID Connect Session Management 1.0).
Non credo perché anche se l’OP invia i dati session_state, non vedo da nessuna parte nel codice dove vengano memorizzati come cookie o altro.

Quindi questa è una domanda/richiesta di funzionalità Sarebbe fantastico!

[swt2c (Scott Talbert)]

Quando si utilizza questo plugin con AWS Cognito, per effettuare il logout, Cognito richiede il passaggio di un parametro client_id all’URL di logout. Per quanto ne so, non c’è modo di aggiungere parametri di query aggiuntivi all’URL di logout, è corretto? Se no, è possibile aggiungere questa funzionalità?

[chrisblech (Christoph Blechschmitt)]

Ehi gente

Ho scritto una piccola estensione per questo plugin (tecnicamente sotto forma di tema/componente) - per nascondere il pulsante “Accedi tramite OIDC” nel popup di accesso, ma avviare il flusso di accesso tramite OIDC accedendo a un URL speciale.

discourse-autooidc.zip (1,0 KB)

Il caso d’uso per questa funzionalità è fornire un accesso sicuro e conveniente (automatico) tramite oauth ai membri della nostra azienda, senza esporre un link pubblico al provider OAuth (Authentik nel nostro caso, ma dovrebbe funzionare anche con Authelia, Keycloak, Auth0, Okta,…) e senza infastidire tutti gli altri utenti con un pulsante di accesso tramite OIDC che non possono o non dovrebbero mai usare.

Per accedere tramite OIDC, basta chiamare https://<il-tuo-URL-base-di-Discourse>/login#autooidc

[david (David Taylor)]

Potrebbe interessarti GitHub - discourse/discourse-hide-auth-method: A theme component which allows hiding a specific login method from the UI, without fully disabling it, che fa qualcosa di simile

[kluvi (Jakub Kluvánek)]

Keycloak supporta Backchannel logout URL (URL di logout in backchannel):

URL che causerà il logout del client quando viene inviata una richiesta di logout a questo realm (tramite end_session_endpoint). Se omesso, in questo caso non verrà inviata alcuna richiesta di logout al client.

Sarebbe fantastico se questo plugin esponesse un endpoint che accetta un payload da Keycloak ed effettua immediatamente il logout di un utente da tutte le sessioni. Altrimenti, quando disabilitiamo un utente in Keycloak, dobbiamo attendere maximum session age (che per impostazione predefinita è piuttosto elevato).

[Firepup650 (Firepup Sixfifty)]

@kluvi

dobbiamo attendere maximum session age

Potresti anche disconnetterli da tutte le sessioni utilizzando la pagina di amministrazione dell’utente (ad esempio, /admin/-1/system) e fare clic sul pulsante Log Out nella parte superiore della pagina.

[nfrog (Nicolas)]

Ciao,

Quando il recupero del documento di discovery fallisce (ad esempio in caso di timeout), il plugin memorizza nella cache l’errore, il che significa che l’autenticazione non è disponibile per 10 minuti. È possibile non memorizzare nella cache l’errore in modo che il recupero venga ritentato prima?

Saluti

[balazsorban44 (Balázs Orbán)]

Mi scuso per il ping, ma c’è una PR aperta per questo che dovrebbe essere banale da unire per aggiungere il supporto PKCE.

@nbianca Ti ho visto essere l’ultimo committer al repository, potresti dare un’occhiata, forse?

Enable PKCE Support