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 إعجابًا

مرحباً،
نحن نستخدم إضافة المصادقة OpenID Connect مع تثبيت Discourse على AWS.
لقد قمنا بنشر حاويات Discourse و Discourse Sidekiq و Redis (بناءً على Bitnami ولكن رجاءً لا تطردوني ؛). قاعدة البيانات تعمل على AWS RDS. نستخدم KeyCloak.

الأمور تسير على ما يرام.

ولكن في بعض الأحيان بعد إعادة تشغيل مهمة Discourse AWS، يحدث أنها تعتقد أن لديها مستند الاكتشاف في ذاكرة التخزين المؤقت ولكن لا يوجد مستند هناك. ولا تحاول استعادته مرة أخرى من KeyCloak:

سجل OIDC: تم تحميل مستند الاكتشاف من ذاكرة التخزين المؤقت
سجل OIDC: مستند الاكتشاف هو
---
(oidc) بدأت مرحلة الطلب.
(oidc) فشل المصادقة! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError، مستند الاكتشاف مفقود

في تطبيق المتصفح أرى: تعذر جلب التكوين من موفر الهوية. يرجى المحاولة مرة أخرى.

ماذا يمكنك أن تنصح؟

إعجابَين (2)

مرحباً،

هل هناك طريقة لتعيين مصدر صورة ملف تعريف مستخدم Discourse إلى حقل محدد في خدمة openID؟

تعديل: نحن نستخدم Keycloak

إعجاب واحد (1)

مرحباً،

لدي متطلب مشابه لمتطلب @Tomáš_Guba: أود الحصول على قيمة من إدخال مخصص في ملف تعريف المستخدم واستخدامها في حقل مستخدم [مخصص].

في حالتي الشخصية، لدي مستند اكتشاف به userinfo_endpoint

هل هناك شيء كهذا في خارطة طريق البرنامج المساعد؟

شكراً

إعجاب واحد (1)

مرحباً، لقد تمكنت من جعل المكون الإضافي يعمل مع معرّف OpenID الخاص بتسجيل الدخول الموحد (SSO) الخاص بي، ولكنه لا يظهر مملوءًا في حقل اسم المستخدم للنظام الآخر أو البريد الإلكتروني من بين حقول أخرى…

أتخيل أنه يجب عليّ تكوين شيء ما في حقل “مطالبات اتصال OpenID”، ولكني لا أعرف كيفية تكوين هذا الحقل مباشرة. هل يمكن لأحد أن يعطيني مثالاً؟ إليك بعض لقطات الشاشة لكيفية ظهور مشروعي:
https://imgur.com/gallery/LWvkJUV

إعجاب واحد (1)

هل هناك طريقة لتجنب “فقدان” المسار الأصلي عند تسجيل الدخول إلى منشور خاص؟

إذا قمنا بزيارة صفحة خاصة وضغطنا على أحد أزرار تسجيل الدخول في تلك الصفحة، فعند إعادة توجيهنا إلى الموقع، نصل إلى صفحة الفئات.

مرحباً @david،
هل يمكنك إلقاء نظرة على المشكلة المذكورة في المنشور التالي؟ أود استخدام إضافة OIDC بدلاً من OAuth الأساسي. لكنني أواجه نفس المشكلة - لا يمكنني تمرير المعلمات إلى طلب /authorize. لقد وضعت القيمة في الإضافة بالتنسيق foo=bar.

لم أتمكن من جعل هذا يعمل في LinkedIn. هل لدى أي شخص آخر؟ أصل إلى تسجيل الدخول إلى LinkedIn بعد إعادة التوجيه إليه عند النقر على زر “تسجيل الدخول باستخدام…” ثم “السماح” لتطبيقي باستخدام بريدي الإلكتروني من LinkedIn، ثم أحصل على “عذرًا، حدث خطأ أثناء التفويض لحسابك. يرجى المحاولة مرة أخرى.”

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

ما زلت أواجه مشكلة في هذا. أحصل على الخطأ التالي:

(oidc) فشل المصادقة! invalid_credentials: OAuth2::Error, invalid_request: A required parameter "client_secret" is missing {"error":"invalid_request","error_description":"A required parameter

هذا خطأ omniauth ويبدو أنه متعلق بـ [ربما]: No longer works with oauth2 gem v2.0+ · Issue #68 · decioferreira/omniauth-linkedin-oauth2 · GitHub

المساعدة محل تقدير!

أتلقى الأخطاء التالية:

(oidc) فشل المصادقة! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError، مستند الاكتشاف مفقود

سجل OIDC: جلب مستند الاكتشاف أثار خطأ Faraday::ConnectionFailed FinalDestination: فشل البحث

لدي إعداد المكون الإضافي “وثيقة اكتشاف OpenID Connect” في إعدادات المسؤول على النحو التالي: https://<auth_provider>/.well-known/openid-configuration ويمكنني الوصول إليها بنجاح في حاوية Docker للتطبيق التي تعمل باستخدام أمر Curl وحتى في وحدة تحكم Rails.

هل لديك أي فكرة عن سبب تلقي هذه الأخطاء؟ لا يمكنني التكامل بشكل صحيح بسبب ذلك. أيضًا، أنا خلف الشبكة الداخلية وأستخدم وكيل شركة إذا كان ذلك مفيدًا. كما ذكرت، مع تمكين الوكيل في متغيرات البيئة للحاوية، يمكنني الوصول بشكل صحيح إلى عنوان URL الخاص بـ “وثيقة اكتشاف OpenID Connect”.

إعجاب واحد (1)

تم تقسيم منشورين إلى موضوع جديد: السماح بمصادر OIDC متعددة

تم تقسيم منشور إلى موضوع جديد: استبدال الصور الرمزية باستخدام OIDC

مرحباً!

سؤال جديد: هل تدعم هذه الإضافة إدارة الجلسات؟ (Final: OpenID Connect Session Management 1.0).
لا أعتقد ذلك لأنه حتى لو أرسل موفر الهوية بيانات session_state، لا أرى في أي مكان في الكود حيث يتم تخزينها كملف تعريف ارتباط أو ما شابه.

لذا هذا سؤال/طلب ميزة :slight_smile: سيكون رائعاً!

إعجابَين (2)

عند استخدام هذه الإضافة مع AWS Cognito، لتسجيل الخروج، يتطلب Cognito تمرير معلمة client_id إلى عنوان URL لتسجيل الخروج. على حد علمي، لا توجد طريقة لإضافة معلمات استعلام إضافية إلى عنوان URL لتسجيل الخروج - هل هذا صحيح؟ إذا لم يكن كذلك، فهل من الممكن إضافة هذه الإمكانية؟

أهلاً بالجميع :wave:t3:

لقد كتبت إضافة صغيرة لهذا المكون الإضافي (تقنيًا في شكل سمة/مكون) - لإخفاء الزر “تسجيل الدخول عبر OIDC” في نافذة تسجيل الدخول المنبثقة، ولكن لبدء تدفق تسجيل الدخول عبر OIDC عن طريق الوصول إلى عنوان URL خاص.

discourse-autooidc.zip (1.0 كيلوبايت)

حالة الاستخدام لهذه الميزة هي توفير تسجيل دخول آمن ومريح (تلقائي) عبر OAuth لأعضاء شركتنا، دون الكشف عن رابط عام لموفر OAuth (Authentik في حالتنا، ولكن يجب أن يعمل أيضًا مع Authelia و Keycloak و Auth0 و Okta،…) ودون إزعاج جميع المستخدمين الآخرين بزر تسجيل الدخول عبر OIDC الذي لا يمكنهم أو لا ينبغي عليهم استخدامه أبدًا.

لتسجيل الدخول عبر OIDC، ما عليك سوى استدعاء https://<your-discourse-base-url>/login#autooidc

3 إعجابات

قد تكون مهتمًا بـ https://github.com/discourse/discourse-hide-auth-method، والذي يفعل شيئًا مشابهًا

3 إعجابات

يدعم Keycloak Backchannel logout URL:\n\u003e عنوان URL الذي سيؤدي إلى تسجيل خروج العميل من نفسه عند إرسال طلب تسجيل خروج إلى هذا النطاق (عبر end_session_endpoint). إذا تم حذفه، فلن يتم إرسال أي طلب تسجيل خروج إلى العميل في هذه الحالة.\n\n سيكون من الرائع لو كشف هذا المكون الإضافي عن نقطة نهاية تقبل حمولة من Keycloak وتسجل خروج مستخدم معين فورًا من جميع الجلسات. بخلاف ذلك، عندما نقوم بتعطيل مستخدم في Keycloak، يجب علينا انتظار maximum session age (وهو كبير جدًا افتراضيًا)

يمكنك أيضًا تسجيل خروجهم من جميع الجلسات باستخدام صفحة مسؤول المستخدم (على سبيل المثال، /admin/-1/system) وانقر فوق الزر تسجيل الخروج في أعلى الصفحة.

مرحباً،

عندما يفشل جلب مستند الاكتشاف (على سبيل المثال، عند انتهاء المهلة)، يقوم المكون الإضافي بتخزين الخطأ مؤقتًا، مما يعني أن المصادقة غير متاحة لمدة 10 دقائق. هل من الممكن عدم تخزين الخطأ مؤقتًا حتى تتم إعادة محاولة الجلب في وقت أقرب؟

مع خالص التقدير

عذرًا على الإزعاج، ولكن هناك طلب سحب (PR) مفتوح لهذا الغرض والذي يجب أن يكون من السهل دمجه لإضافة دعم PKCE.

@nbianca رأيت أنك آخر من قام بالالتزام في المستودع، هل يمكنك إلقاء نظرة، ربما؟ :folded_hands:

إعجاب واحد (1)