Discourse OpenID Connect (OIDC)

[Discourse]

	Zusammenfassung	Discourse OpenID Connect ermöglicht die Nutzung eines OpenID Connect-Anbieters als Authentifizierungsanbieter für Discourse.
	Installationsanleitung	Dieses Plugin ist im Discourse-Kern enthalten. Eine separate Installation des Plugins ist nicht erforderlich.

Da es sich um ein official Plugin handelt, das vom Discourse-Team gepflegt wird, können #contribute:bug-, #contribute:ux- und #contribute:feature-Anfragen in den jeweiligen Kategorien hier auf Meta gestellt und mit dem entsprechenden Plugin-Tag versehen werden. Support wird in Support > SSO angeboten. Klicken Sie auf einen der untenstehenden Links, um einen neuen Beitrag zu erstellen.

Support Fehler UX Funktion

Funktionen

Das Plugin zielt darauf ab, eine minimale Implementierung der Spezifikation bereitzustellen. Insbesondere wird der „Authorization Code Flow“ unterstützt. Um zu beginnen, folgen Sie den Installationsanweisungen für das Plugin oder kontaktieren Sie Ihren Hosting-Anbieter.

Unser oauth2-basic-Plugin kann für die Verbindung mit einigen OpenID-Connect-Anbietern verwendet werden (OpenID Connect basiert auf OAuth2). Dieses Plugin erfordert jedoch deutlich weniger manuelle Konfiguration und kann das JWT-„ID Token“ nutzen, falls keine JSON-API verfügbar ist.

Die Konfiguration erfolgt automatisch mithilfe eines OpenID Connect Discovery Documents. Laut Spezifikation sollte dies unter <issuer domain>/.well-known/openid-configuration zu finden sein, aber Discourse unterstützt jeden Pfad, um nicht-konforme Implementierungen zu ermöglichen (z. B. Azure B2C). Das Discovery-Dokument wird für 10 Minuten zwischengespeichert, um die Leistung auf Seiten mit hohem Verkehrsaufkommen zu verbessern.

Enthält das Discovery-Dokument einen userinfo_endpoint-Parameter, verwendet das Plugin diesen zur Erfassung von Benutzermetadaten. Andernfalls extrahiert das Plugin die Metadaten aus dem vom Token-Endpunkt bereitgestellten id_token (ein JWT). Das Plugin überprüft nicht die Authentizität der JWT-Signatur, da dies die Komplexität erheblich erhöhen würde. Diese Entscheidung wird von der Spezifikation unterstützt:

Wird das ID-Token über eine direkte Kommunikation zwischen dem Client und dem Token-Endpunkt empfangen (was in diesem Flow der Fall ist), kann die TLS-Server-Validierung verwendet werden, um den Aussteller anstelle der Überprüfung der Tokensignatur zu validieren.

Für Identitätsanbieter, die eine autorisierungsfreie Autorisierung mit dem „Authorization Code Flow mit Proof Key for Code Exchange“ unterstützen, sollte PKCE aktiviert sein, und die Konfiguration client_secret kann weggelassen werden.

Konfiguration

Grundlegende Konfigurationsoptionen

• openid_connect_enabled: OpenID Connect-Authentifizierung aktivieren

• openid_connect_discovery_document: URL des OpenID Connect Discovery-Dokuments. Normalerweise unter https://your.domain/.well-known/openid-configuration zu finden

• openid_connect_client_id: OpenID Connect Client-ID

• openid_connect_client_secret: OpenID Connect Client-Secret

• openid connect rp initiated logout: Den Benutzer nach dem Abmelden zum end_session_endpoint umleiten. Muss von Ihrem Identitätsanbieter unterstützt und im Discovery-Dokument enthalten sein.

• openid connect rp initiated logout redirect: (optional) Die post_logout_redirect_uri, die an den Abmelde-Endpunkt übergeben wird. Falls angegeben, muss sie beim Identitätsanbieter registriert sein.

• openid_connect_authorize_scope: Die Scopes, die an den Autorisierungs-Endpunkt gesendet werden. Dies muss ‘openid’ enthalten.

• openid_connect_use_pkce: Proof Key for Code Exchange (PKCE) für die OpenID Connect-Authentifizierung aktivieren.

• openid_connect_verbose_logging: Detaillierte OpenID-Connect-Authentifizierungsinformationen in /logs protokollieren. Dies sollte im normalen Betrieb deaktiviert bleiben.

Erweiterte Konfigurationsoptionen

• openid_connect_token_scope: Die Scopes, die beim Anfordern des Token-Endpunkts gesendet werden. Die offizielle Spezifikation verlangt dies nicht.

• openid_connect_error_redirects: Wenn der callback error_reason den ersten Parameter enthält, wird der Benutzer zur URL im zweiten Parameter umgeleitet. Wird für ungewöhnliche Implementierungen verwendet, die Fehler als Antwort auf Benutzereingaben senden (z. B. Azure B2C).

• openid_connect_allow_association_change: Benutzern erlauben, ihre Discourse-Konten vom OpenID Connect-Anbieter zu trennen und erneut zu verbinden.

• openid_connect_groups_claim: Der Name des Claims in der OIDC-Antwort^[1], der die Benutzergruppen als Array von Strings enthält. Leer lassen, um die Gruppensynchronisierung zu deaktivieren. Siehe Gruppensynchronisierung unten.

• openid_connect_user_field_mappings: Zuordnungen von OIDC-Claims^[2], die in Discourse-Benutzerfeldern gespeichert werden. Benutzerfelder werden durch ihre numerische ID identifiziert, die in der URL beim Bearbeiten über das Admin-Panel zu finden ist.

Gruppensynchronisierung

Das Plugin kann Gruppennmitgliedschaften automatisch von Ihrem OpenID Connect-Anbieter zu Discourse-Gruppen synchronisieren. Bei jedem Login liest das Plugin den konfigurierten Claim aus dem OIDC-Token und aktualisiert die Gruppennmitgliedschaften des Benutzers entsprechend. Um die Gruppensynchronisierung zu aktivieren:

1. Konfigurieren Sie Ihren Identitätsanbieter so, dass er ein Array von Gruppen in einem der Claims zurückgibt. Dies muss ein Array von Strings sein.

2. Setzen Sie openid_connect_groups_claim auf den Namen des Claims im OIDC-Token, der die Benutzergruppen enthält (z. B. cognito:groups). Sobald dies gesetzt ist, beginnt die Synchronisierung der Informationen mit dem „Associated Groups“-System von Discourse.

3. Suchen Sie die Discourse-Gruppe, die Sie verknüpfen möchten. Gehen Sie zu „Einstellungen“ → „Mitgliedschaft“ → „Automatisch“ und wählen Sie dann die zu verknüpfenden Associated Groups aus. Diese Dropdown-Liste wird mit Informationen vom Identitätsanbieter gefüllt, sodass mindestens ein Gruppenmitglied eingeloggt sein muss, damit eine Option erscheint.

Beispielkonfiguration

Hier richten wir das OpenID-Connect-Plugin ein, um eine Verbindung zum OpenID-Connect-Anbieter von Google herzustellen. Dies repliziert Funktionen, die bereits im Kern von Discourse vorhanden sind, dient jedoch als zugängliches Beispiel.

1. Gehen Sie zu OpenID Connect  |  Sign in with Google  |  Google for Developers und folgen Sie den Anweisungen, um OAuth-Anmeldedaten zu erhalten.

2. Auf derselben Seite folgen Sie den Anweisungen, um eine Redirect-URI hinzuzufügen. Diese sollte https://<your_forum>/auth/oidc/callback lauten (ohne abschließenden Schrägstrich).

3. Gehen Sie zu den Einstellungen Ihrer Discourse-Website und suchen Sie nach „openid_connect“.

   • openid connect enabled: [x]

   • 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 (mit einem Leerzeichen dazwischen)

4. Sie sind fertig. Der Button „Login with OpenID Connect“ meldet sich nun mit Google an . Diese Schritte können mit minimalen Änderungen auch auf andere Anbieter angewendet werden.

Fehlerbehebung

Zusätzlich zur oben beschriebenen Einstellung verbose_logging können Sie mit dem Data-Explorer-Plugin Daten über OIDC-Assoziationen abrufen:

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

Oder in der Rails-Konsole:

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

Anbieter-spezifische Hinweise

Falls Sie anbieter-spezifische Eigenheiten im Zusammenhang mit dieser Integration entdecken, können Sie diese gerne aktualisieren:

Entra ID (ehemals Azure AD)

Fügen Sie den email-Scope hinzu und stellen Sie sicher, dass Sie das Konfigurationsdokument der Version 2 verwenden. Zum Beispiel:

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

@andy.czerwonka

• Stellen Sie sicher, dass Sie v2.0 des Konfigurationsendpunkts verwenden, wie in den obigen Hinweisen beschrieben. Der Standard-v1.0-Endpunkt unterstützt keine email- oder profile-Scopes.
• Falls Probleme mit dem Client-Secret auftreten, versuchen Sie, ein neues zu generieren. Wir hatten einige Probleme, aber nach dem Generieren mehrerer schien alles in Ordnung zu sein.
• Stellen Sie sicher, dass Sie beim Erstellen des Eintrags für Ihre Website in Azure AD „Sign in and read user profile“ als „Delegated Permission“ aktivieren.
• Stellen Sie sicher, dass Sie den korrekten Callback hinzufügen, der ‘https://your-site/auth/oidc/callback’ lautet.

Azure B2C

Die Details zur URL des Discovery-Dokuments finden Sie hier: Web sign in with OpenID Connect - Azure AD B2C | Microsoft Learn

Zum Beispiel befindet sich das Metadokument für den Benutzerfluss b2c_1_sign_in in fabrikamb2c.onmicrosoft.com unter:

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

Damit E-Mails funktionieren:

@Umer_Nawab

Um E-Mails in Claims zu erhalten, müssen Sie benutzerdefinierte Richtlinien verwenden. Dafür habe ich das hier erwähnte Starter-Paket für Richtlinien verwendet:

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

Nach der Umsetzung der in dem oben genannten Artikel beschriebenen Schritte erschien der E-Mail-Claim beim Registrieren eines neuen Benutzers, fehlte jedoch im Token beim Anmelden eines bestehenden Benutzers. Anschließend musste ich einige Änderungen an der benutzerdefinierten XML-Richtlinie vornehmen, indem ich die Schritte in diesem Beitrag befolgte:

https://stackoverflow.com/questions/59669666/email-claims-not-populated-with-custom-policies-in-azure-b2c

Nach diesen Änderungen erscheint der E-Mail-Claim nun sowohl beim Registrieren als auch beim Anmelden des Benutzers.

Yahoo

1. Gehen Sie zu https://developer.yahoo.com/apps und erstellen Sie eine neue App.

2. Geben Sie den Anwendungsnamen ein und setzen Sie die Callback-Domain auf Ihre Forum-Domain (z. B. meta.discourse.org).

3. Wählen Sie unter API-Berechtigungen Profiles: Read/Write Public and Private. Dies ist der einzige mir bekannte Weg, um die E-Mail-Adresse des Benutzers zu erhalten.

4. Speichern Sie die App.

5. Stellen Sie in den Discourse-OIDC-Einstellungen das Discovery-Dokument auf:

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

6. Geben Sie die Client-ID und das Secret von Yahoo ein.

7. Aktivieren Sie das OIDC-Plugin.

AWS Cognito

1. Gehen Sie zu Cognito und wählen Sie einen neuen Benutzerpool aus oder erstellen Sie einen.
2. Definieren Sie eine App unter App-Clients.
3. Lassen Sie alles auf den Standardwerten, ändern Sie jedoch die Konfiguration der Auth-Flows, sodass nur ALLOW_REFRESH_TOKEN_AUTH ausgewählt ist.
4. Gehen Sie zu den App-Client-Einstellungen und wählen Sie die neue App aus.
5. Ändern Sie die Callback-URL zu https://yoursite.example.com/auth/oidc/callback.
6. Aktivieren Sie nur den Authorization Code Grant Flow unter „Allowed OAuth Flows“.
7. Aktivieren Sie alle benötigten Scopes (ich habe alle aktiviert).

Okta

1. Konfigurieren Sie Discourse mit Ihrer Okta-App-Client-ID und dem Secret.

2. Setzen Sie die URL des Discovery-Dokuments auf:

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

3. Setzen Sie in Discourse den openid connect authorize scope auf openid email.

Von uns gehostet? Dieses Plugin ist in unseren Business- und Enterprise-Plänen verfügbar. OAuth 2.0 & OpenID Connect Support | Discourse - Civilized Discussion

Benötigen Sie eine Automatisierung der Benutzerregistrierung? Siehe Auto-provisioning user accounts when SSO is enabled

---

1. Token oder Userinfo-Payload ↩︎

2. aus Token oder Userinfo-Payload ↩︎