أعتقد أن ما تصفه هنا هو تدفق OpenID Connect “التدفق الضمني”، والذي يعمل دون أي اتصال من خادم إلى خادم، وبالتالي لا يحتاج إلى سر مشترك. بدلاً من ذلك، يتم نقل جميع المعلومات عبر عمليات إعادة التوجيه HTTP، ويتم التحقق من صحة رمز المعرف بشكل تشفيري باستخدام المفاتيح العامة من مستند الاكتشاف.
هذا جيد، وأعتقد أنه طلب ميزة صالح. ولكنه نظام مختلف جدًا عن المكون الإضافي الحالي لدينا، والذي يستخدم تدفق رمز التفويض. يستخدم هذا التدفق الاتصال من خادم إلى خادم مع سر مشترك، وبالتالي لا يلزم التحقق التشفيري من id_token. هذا أبسط في بعض النواحي، ولكنه أكثر تعقيدًا في نواحٍ أخرى.
هام: لا يمكننا تغيير التنفيذ الافتراضي في المكون الإضافي. تحتاج المواقع التي تستخدم تدفق رمز التفويض إلى الاستمرار في استخدامه. على حد علمي، لا تدعم العديد من موفري الهوية تدفق التدفق الضمني.
لذلك أعتقد أن هناك مسارين للمضي قدمًا هنا:
-
نضيف دعمًا لـ “التدفق الضمني” في المكون الإضافي OIDC، ولكن نجعلها شيئًا اختياريًا. أعتقد أنه من غير المرجح أن نقبل طلب سحب (PR) يقدم gem openid-connect كاعتمادية لـ Discourse core، لذلك سيتعين تنفيذه ضمن استراتيجيتنا الحالية.
قد يكون المكون الإضافي discourse-lti (تكامل أدوات التعلم) مصدر إلهام مفيد، لأن بروتوكول LTI يعتمد على التدفق الضمني لـ OIDC. منطق فك تشفير id_token موجود هنا
أو بدلاً من ذلك
-
تقوم ببناء التدفق الضمني كمكون إضافي جديد تمامًا. في هذه الحالة، ستكون حرًا في فعل ما تشاء فيما يتعلق بالتنفيذ (ولكن سيتعين عليك صيانته بنفسك أيضًا)