أتطلع إلى تحسين وضعنا الأمني، وجزء من ذلك يعني أننا بحاجة إلى تجنب استخدام بيانات اعتماد سرية كلما أمكننا ذلك.
للأسف، كان المكون الإضافي OIDC يتطلب بيانات اعتماد سرية للعميل للوصول إلى نقطة النهاية /userinfo، ولم أتمكن من إعداد منتداي مع تمكينه.
لحسن الحظ، تم تحديد مواصفات OIDC بالفعل بطريقة لا تتطلب استخدام أي رموز سرية.
إذا التزمنا بـ id_token flow، فإن موفر الهوية (IdP) سيرسل لنا جميع المعلومات التي نحتاجها للمصادقة على مستخدم دون الحاجة إلى العودة إلى موفر الهوية.
هذا آمن لأن إعادة التوجيه تم تكوينها في موفر الهوية، ولا داعي للقلق بشأن إعادة توجيه رمز الحامل إلى وجهة خاطئة.
لقد قمت بإنشاء تصحيح للمكون الإضافي OIDC لدعم تدفق id_token وقدمت طلب سحب هنا:
الطلب ليس مكتملًا تمامًا لأنه لا يزال بحاجة إلى اختبارات وحدات، ولكنه شبه جاهز وقد أكدت أن هذا يعمل بشكل صحيح مع Azure AD (Entra ID).
أعتقد أن ما تصفه هنا هو تدفق OpenID Connect “التدفق الضمني”، والذي يعمل دون أي اتصال من خادم إلى خادم، وبالتالي لا يحتاج إلى سر مشترك. بدلاً من ذلك، يتم نقل جميع المعلومات عبر عمليات إعادة التوجيه HTTP، ويتم التحقق من صحة رمز المعرف بشكل تشفيري باستخدام المفاتيح العامة من مستند الاكتشاف.
هذا جيد، وأعتقد أنه طلب ميزة صالح. ولكنه نظام مختلف جدًا عن المكون الإضافي الحالي لدينا، والذي يستخدم تدفق رمز التفويض. يستخدم هذا التدفق الاتصال من خادم إلى خادم مع سر مشترك، وبالتالي لا يلزم التحقق التشفيري من id_token. هذا أبسط في بعض النواحي، ولكنه أكثر تعقيدًا في نواحٍ أخرى.
هام: لا يمكننا تغيير التنفيذ الافتراضي في المكون الإضافي. تحتاج المواقع التي تستخدم تدفق رمز التفويض إلى الاستمرار في استخدامه. على حد علمي، لا تدعم العديد من موفري الهوية تدفق التدفق الضمني.
لذلك أعتقد أن هناك مسارين للمضي قدمًا هنا:
نضيف دعمًا لـ “التدفق الضمني” في المكون الإضافي OIDC، ولكن نجعلها شيئًا اختياريًا. أعتقد أنه من غير المرجح أن نقبل طلب سحب (PR) يقدم gem openid-connect كاعتمادية لـ Discourse core، لذلك سيتعين تنفيذه ضمن استراتيجيتنا الحالية.
قد يكون المكون الإضافي discourse-lti (تكامل أدوات التعلم) مصدر إلهام مفيد، لأن بروتوكول LTI يعتمد على التدفق الضمني لـ OIDC. منطق فك تشفير id_token موجود هنا
أو بدلاً من ذلك
تقوم ببناء التدفق الضمني كمكون إضافي جديد تمامًا. في هذه الحالة، ستكون حرًا في فعل ما تشاء فيما يتعلق بالتنفيذ (ولكن سيتعين عليك صيانته بنفسك أيضًا)
تجدر الإشارة أيضًا إلى أن تدفق OIDC “الضمني” يزيد من مساحة الهجوم لهجمات CSRF وتعرض الرموز المميزة:
أعتقد أنه لا يزال منطقيًا لبعض المواقف. ولكن يبدو أن تدفق رمز التفويض (الافتراضي في Discourse) مع PKCE (اختياري في Discourse) هو الطريقة الأكثر توصية لاستخدام OIDC.
أعتقد أنه لا يزال من الممكن أن يكون منطقياً في بعض المواقف. ولكن يبدو أن تدفق رمز التفويض (الافتراضي في Discourse) مع PKCE (اختياري في Discourse) هو الطريقة الأكثر توصية لاستخدام OIDC.
هذا مثير للاهتمام للغاية - لم أفهم PKCE بالكامل حتى الآن. بناءً على قراءتي لـ وثائق Auth0، يبدو أن هذا التدفق (في تكوينات معينة) له مزايا التدفق الضمني (لا يوجد سر عميل) دون أي من سلبياته.
هل هذا شيء يمكن القيام به بدلاً من ذلك؟ يبدو أنه بسيط مثل إزالة معلمة سر العميل من نقطة النهاية /token.
وفي النهاية، فإن شاغلي الرئيسي هو مجرد التخلص من متطلب سر العميل
diff --git a/plugins/discourse-openid-connect/lib/omniauth_open_id_connect.rb b/plugins/discourse-openid-connect/lib/omniauth_open_id_connect.rb
index 410a88f46dc..e74ee360aae 100644
--- a/plugins/discourse-openid-connect/lib/omniauth_open_id_connect.rb
+++ b/plugins/discourse-openid-connect/lib/omniauth_open_id_connect.rb
@@ -73,6 +73,11 @@ module OmniAuth
)
options[:client_options][:auth_scheme] = :request_body
end
+
+ # If we're using PKCE _and_ there is no client_secret, use the request_body auth_scheme.
+ if options[:pkce] && options[:client_secret].empty?
+ options[:client_options][:auth_scheme] = :request_body
+ end
end
def request_phase
تم تكوين عنوان URI لإعادة التوجيه في لوحة تحكم Azure على النحو التالي:
