If you ever wanted to use Discourse as your authentication provider - now you can!
Over the last week I’ve written a small service which can be used to act as an OpenID connect/OAuth provider with discourse as a backend.
You can check out the code here:
Note that my primary use case was to authenticate to Nextcloud using Discourse, so it might not be working for your use case.
If something is not working as expected, or it is missing that certain feature to make it work for you, feel free to create an issue in the GitHub repository.
Awesome initiative! I always wanted Discourse to be usable as an OAuth provider, so it can easily be integrated with more tools. Making it an external small service makes a lot of sense too!
I like the sound of this and hope some communities decide to try it out!
I’d love to see OIDC supported by Discourse officially in addition to our bespoke Discourse Connect functionality, so we can offer a turnkey solution to our customers on standard and teams without having to rely on okta or the like.
Distrust is a separate service, so you need to deploy it as such. You can run it in a container as described in the README file. Note that for secure operation, you will also need a reverse proxy handling SSL Termination (I might implement this directly sometime in the future).
آمل في الحصول على بعض الآراء الخبيرة حول المشكلات التي أواجهها أثناء محاولة استخدام Discourse كموفر SSO.
هدفي: أقوم بإعداد Discourse للتعامل مع المصادقة لتطبيق آخر (LibreChat). أستخدم وظيفة موفر DiscourseConnect القياسية، مع خدمة جسر OIDC distrust التي تعمل كعميل يتواصل مع Discourse.
المشكلة: يتدفق SSO بشكل مثالي حتى الخطوة الأخيرة. يتم إعادة توجيه المستخدم بشكل صحيح من تطبيقي إلى Discourse، ويمكنهم تسجيل الدخول بنجاح باستخدام بيانات اعتماد Discourse الخاصة بهم. ومع ذلك، بعد تسجيل الدخول، يتم إعادة توجيههم إلى الصفحة الرئيسية لمنتدى Discourse الخاص بي (/) بدلاً من return_sso_url الذي تم توفيره.
أين أنا عالق (ما استبعدته): لقد قمت باستكشاف هذه المشكلة لفترة طويلة وتأكدت من أنها ليست خطأ تكوين بسيطًا. لقد استبعدت بشكل قاطع ما يلي:
الأسرار: تم تكوين discourse connect provider secrets بشكل صحيح. أستخدم النطاق العادي (مثل auth.my-site.com) بدون أي بروتوكول، ويتطابق مفتاح السر تمامًا مع المفتاح الموجود في خدمة العميل الخاصة بي.
وضع SSO: لقد تأكدت من تحديد enable discourse connect provider، وتم تعطيل إعدادات “SSO Client” غير الصحيحة.
سياسات المستخدم: لقد تأكدت من تعطيل must_approve_users، وأن مستخدم الاختبار الخاص بي هو مسؤول لديه بريد إلكتروني تم التحقق منه بالكامل.
الإضافات: لقد قمت بتعطيل جميع الإضافات الخارجية غير الرسمية وأعدت بناء الحاوية، ولكن المشكلة لا تزال قائمة.
الدليل الرئيسي: لدي دليلان قاطعان جعلااني في حيرة من أمري:
تحليل ملف HAR: قمت بتسجيل تدفق الشبكة بالكامل في ملف HAR. يُظهر طلب POST إلى /session لتسجيل الدخول بنجاح. يستجيب الخادم فورًا بإعادة توجيه 302 Found، ولكن رأس Location هو دائمًا /. هذا يثبت أن Discourse يقوم بإلغاء إعادة توجيه SSO عمدًا.
سجل Rails فارغ: ثم قمت بتتبع ملف production.log داخل الحاوية أثناء محاولة تسجيل الدخول. لا يتم كتابة أي شيء على الإطلاق في السجل أثناء هذه العملية. هذا يخبرني أن Discourse لا يعتبر هذا خطأ؛ إنه إجراء متعمد وصامت.
سؤالي: نظرًا لأن تسجيل الدخول ناجح، ولكن إعادة التوجيه غير صحيحة ولا توجد أخطاء في السجلات، ما هي سياسة Discourse الداخلية أو فحص مسبق أو إعداد مخفي يمكن أن يتسبب في تجاهل return_sso_url وإعادة التوجيه إلى الصفحة الرئيسية بدلاً من ذلك؟ أشعر أنني استنفدت جميع الإعدادات القياسية.
