Discourse OpenID Connect (OIDC)

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

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 :tada:. 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
Azure B2C

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

To make emails work:

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

:discourse2: 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 documentPerform check on document:
51 „Gefällt mir“

Hallo,
wir verwenden das OpenID Connect Authentication Plugin mit einer Discourse-Installation auf AWS.
Wir haben die Container Discourse, Discourse Sidekiq und Redis (basierend auf Bitnami, aber bitte werft mich nicht raus ;)). Die DB läuft auf AWS RDS. Wir verwenden KeyCloak.

Die Dinge laufen.

Aber manchmal nach einem Neustart der Discourse AWS Task passiert es, dass sie denkt, sie hätte das Discovery-Dokument im Cache, aber dann ist kein Dokument da. Und sie versucht nicht, es erneut von KeyCloak abzurufen:

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

In der Browser-App sehe ich: Konfiguration vom Identitätsanbieter konnte nicht abgerufen werden. Bitte versuchen Sie es erneut.

Was können Sie raten?

2 „Gefällt mir“

Hallo,

Gibt es eine Möglichkeit, die Discourse-Benutzer-Avatarquelle auf ein Feld zu setzen, das im OpenID-Dienst angegeben ist?

Bearbeiten: Wir verwenden Keycloak

1 „Gefällt mir“

Hallo,

Ich habe eine Anforderung, die der von @Tomáš_Guba ähnelt: Ich möchte einen Wert aus einem benutzerdefinierten Eintrag im Benutzerprofil abrufen und ihn in einem [benutzerdefinierten] Benutzerfeld verwenden.

In meinem speziellen Fall habe ich ein Discovery-Dokument mit einem userinfo_endpoint.

Gibt es so etwas in der Plugin-Roadmap?

Danke

1 „Gefällt mir“

Hallo, ich habe es geschafft, das Plugin mit meinem SSO OpenID zum Laufen zu bringen, aber der Benutzername oder die E-Mail-Adresse werden im entsprechenden Feld des anderen Systems nicht ausgefüllt, ebenso wenig wie andere Felder …

Ich stelle mir vor, dass ich etwas im Feld „OpenID Connect Claims“ konfigurieren muss, aber ich weiß nicht, wie ich dieses Feld direkt konfigurieren soll. Kann mir jemand ein Beispiel geben? Hier sind einige Screenshots, wie mein Projekt aussieht:
https://imgur.com/gallery/LWvkJUV

1 „Gefällt mir“

Gibt es eine Möglichkeit, die ursprüngliche Route beim Anmelden an einem privaten Beitrag nicht zu “verlieren”?

Wenn wir eine private Seite besuchen und auf eine der Anmeldeschaltflächen auf dieser Seite klicken, werden wir nach der Umleitung zurück zur Website auf der Kategorieseite landen.

Hallo @david,

Können Sie sich bitte das in folgendem Beitrag erwähnte Problem ansehen? Ich möchte das OIDC-Plugin gegenüber OAuth Basic verwenden. Aber ich stoße auf dasselbe Problem – ich kann keine Parameter an die /authorize-Anfrage übergeben. Ich habe den Wert im Plugin im Format foo=bar eingegeben.

Ich konnte das bei LinkedIn nicht zum Laufen bringen. Bin gespannt, ob es bei jemand anderem funktioniert? Ich komme bis zum Einloggen bei LinkedIn, nachdem ich dorthin weitergeleitet wurde, wenn ich auf die Schaltfläche „Mit… anmelden“ klicke und dann meiner App erlaube, meine E-Mail von LinkedIn zu verwenden. Dann erhalte ich die Meldung „Entschuldigung, es gab einen Fehler bei der Autorisierung Ihres Kontos. Bitte versuchen Sie es erneut.“

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

Ich habe damit immer noch Probleme. Ich erhalte folgende Fehlermeldung:

(oidc) Authentifizierungsfehler! ungültige Anmeldedaten: OAuth2::Error, ungültige Anfrage: Ein erforderlicher Parameter „client_secret“ fehlt {„Fehler“:“ungültige Anfrage“,„Fehlerbeschreibung“:“Ein erforderlicher Parameter

Dies ist ein Omniauth-Fehler und scheint [möglicherweise] damit zusammenzuhängen: No longer works with oauth2 gem v2.0+ · Issue #68 · decioferreira/omniauth-linkedin-oauth2 · GitHub

Hilfe ist willkommen!

Ich erhalte folgende Fehler:


(oidc) Authentifizierungsfehler! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError, Discovery-Dokument fehlt

OIDC-Protokoll: Abrufen des Discovery-Dokuments löste den Fehler Faraday::ConnectionFailed FinalDestination: Lookup fehlgeschlagen aus

Ich habe meine Plugin-Einstellung „openid connect discovery document“ in den Admin-Einstellungen wie folgt festgelegt: https://<auth_provider>/.well-known/openid-configuration und ich kann sie erfolgreich im App-Docker-Container, der mit einem Curl-Befehl läuft, und sogar in der Rails-Konsole aufrufen.

Haben Sie eine Idee, warum ich diese Fehler erhalte? Ich kann mich deswegen nicht richtig integrieren. Außerdem befinde ich mich hinter dem Intranet und benutze einen Firmenproxy, falls das hilfreich ist. Wie gesagt, mit dem im ENV des Containers aktivierten Proxy kann ich die URL „openid connect discovery document“ ordnungsgemäß aufrufen.

1 „Gefällt mir“

2 Beiträge wurden in ein neues Thema aufgeteilt: Allowing multiple OIDC sources

Ein Beitrag wurde in ein neues Thema aufgeteilt: Avatare mit OIDC überschreiben

Hallo!

Neue Frage: Verarbeitet dieses Plugin die Sitzungsverwaltung? (Final: OpenID Connect Session Management 1.0).
Ich glaube nicht, denn selbst wenn der OP die session_state-Daten sendet, sehe ich nirgendwo im Code, wo sie als Cookie oder Ähnliches gespeichert werden.

Das ist also eine Frage/ein Funktionswunsch :slight_smile: Das wäre fantastisch!

2 „Gefällt mir“

Wenn Sie dieses Plugin mit AWS Cognito verwenden, erfordert Cognito zum Abmelden die Übergabe eines client_id-Parameters an die Logout-URL. Soweit ich das beurteilen kann, gibt es keine Möglichkeit, zusätzliche Query-Parameter zur Logout-URL hinzuzufügen – stimmt das? Wenn nicht, ist es möglich, diese Funktion hinzuzufügen?

Hallo Leute :wave:t3:

Ich habe eine winzige Erweiterung für dieses Plugin geschrieben (technisch in Form eines Themes/Komponenten), um die Schaltfläche „Über OIDC anmelden“ im Anmelde-Popup auszublenden, aber den Anmelde-via-oidc-Flow durch Aufrufen einer speziellen URL zu initiieren.

discourse-autooidc.zip (1,0 KB)

Anwendungsfall für diese Funktion ist die Bereitstellung einer sicheren und bequemen (automatischen) Anmeldung über OAuth für die Mitglieder unseres Unternehmens, ohne einen öffentlichen Link zum OAuth-Provider (Authentik in unserem Fall, sollte aber auch mit Authelia, Keycloak, Auth0, Okta,… funktionieren) preiszugeben und ohne alle anderen Benutzer mit einer Anmelde-via-oidc-Schaltfläche zu nerven, die sie nie benutzen können oder sollten.

Um sich über OIDC anzumelden, rufen Sie einfach https://<Ihre-Discourse-Basis-URL>/login#autooidc auf.

3 „Gefällt mir“

Sie sind vielleicht an GitHub - discourse/discourse-hide-auth-method: A theme component which allows hiding a specific login method from the UI, without fully disabling it interessiert, das etwas Ähnliches tut

3 „Gefällt mir“

Keycloak unterstützt die Backchannel-Abmelde-URL:

URL, die den Client dazu veranlasst, sich selbst abzumelden, wenn eine Abmeldeanforderung an dieses Realm gesendet wird (über end_session_endpoint). Wenn dies weggelassen wird, wird in diesem Fall keine Abmeldeanforderung an den Client gesendet.

Es wäre großartig, wenn dieses Plugin einen Endpunkt bereitstellen würde, der eine Nutzlast von Keycloak akzeptiert und sofort einen Benutzer aus allen Sitzungen abmeldet. Andernfalls müssen wir, wenn wir einen Benutzer in Keycloak deaktivieren, auf das maximale Sitzungsalter warten (das standardmäßig ziemlich groß ist).

Sie könnten sie auch aus allen Sitzungen aussperren, indem Sie die Admin-Seite des Benutzers aufrufen (z. B. /admin/-1/system) und oben auf der Seite auf die Schaltfläche Abmelden klicken.

Hallo,

Wenn das Abrufen des Discovery-Dokuments fehlschlägt (z. B. bei einem Timeout), speichert das Plugin den Fehler im Cache, was bedeutet, dass die Authentifizierung 10 Minuten lang nicht verfügbar ist. Ist es möglich, den Fehler nicht im Cache zu speichern, damit das Abrufen früher wiederholt wird?

Mit freundlichen Grüßen

Entschuldigen Sie die Störung, aber es gibt einen offenen PR dafür, der trivial zu mergen sein sollte, um PKCE-Unterstützung hinzuzufügen.

@nbianca Ich habe gesehen, dass Sie der letzte Committer im Repository sind. Könnten Sie vielleicht einen Blick darauf werfen? :folded_hands:

1 „Gefällt mir“