أرى ما إذا كان هناك شيء فاتني. أعرف أن download_avatar_url استنادًا إلى السمة userinfo/picture ستفشل نظرًا لعدم تضمين رمز الوصول في هذا الاستدعاء (بالنسبة لـ Entra، هذا هو نقطة نهاية graph/me). إضافة منطق المصادقة إلى المستورد يبدو أنه سيكون فوضى من الشروط الهشة.
لدي نقطة نهاية أفاتار مجهولة ويمكن أن تعمل (تم اختبارها باستخدام عنوان URL خارجي واستبدال قائم على اسم المستخدم).
عادةً ما كنت سأتعامل مع هذا النوع من الأشياء باستخدام مطالبات اختيارية في Entra وسيقوم التطبيق بتعيين تلك المطالبات إلى الحقول الصحيحة من جانبه. يمكنني القيام بذلك بنجاح ورؤية JWT المنسق بشكل صحيح مع المطالبات في سجل OIDC المفصل. لكن التدفق الافتراضي هو استخدام access_token للحصول على userinfo وهو ليس شيئًا يمكنني إضافته/تعديله ويتم تجاهل المطالبات الأخرى.
لاحظت أنه إذا كانت userinfo_endpoint غير معرفة غير معرفة، فسيتم استخدام المطالبات من JWT. المشكلة الآن هي أن هذا يتم تشغيله من محتوى مستند الاكتشاف الذي لا يمكنني تعديله لأنه جزء من .wellknown. اختراق Ruby لاستخدام JWT دائمًا هو حل مؤقت. كنا نفكر حتى في عمل “تفرع” لمستند الاكتشاف وتقديمه من العام في نشرنا، ولكن مرة أخرى حل مؤقت للغاية.
هل أفتقد فقط آلية لتعيين المتغيرات (أو تنسيقها) بدلاً من العبث بمستند الاكتشاف؟ لا أمانع في تكرارها بدلاً من استخدام الاكتشاف، ولكن لا يمكنني رؤية طريقة للقيام بذلك دون تعديل الكود.