الخلاصة

  • يتيح RFC 9728 للمورد المحمي نشر معلومات لازمة للتفاعل معه؛ ولا تجعل الوثيقة نفسها العميل مخولاً لاستخدام المورد.
  • لا تُستخدم الميتاداتا إلا بعد تطابق resource تطابقاً دقيقاً، ثم تبقى إصدار الرموز وقبولها وأثر الفعل وقائع منفصلة.

قول إن المورد «أخبرنا بأي خادم تفويض نستعمل» لا يعني أن التفويض وقع. قد يكون العميل حصل على وثيقة JSON وعلى اسم issuer محتمل فقط. لا يزال خادم التفويض قادراً على رفض العميل، وقد لا يتجه الرمز الناتج إلى هذا المورد، وقد يرفضه خادم المورد، وقد يمنع شرط تشغيلي حالي تنفيذ الطلب حتى بعد قبول الرمز.

RFC 9728 ينظّم هذه البداية ولا يحمّلها أكثر مما تحتمل. ينشر المورد وثيقة في موقع .well-known مشتق من معرّفه، ويمكن أن يذكر خوادم التفويض وscopes وطرق تقديم bearer. تلك خريطة للتوافق، لا تفويض للوثيقة كي تحكم باسم المورد أو باسم العملية التجارية.

الضابط الحاسم هو المطابقة الحرفية. في الاكتشاف المعتاد، يجب أن تساوي قيمة resource الإلزامية معرّف المورد الذي اشتُق منه عنوان الميتاداتا. وإذا جاء العنوان في تحدي WWW-Authenticate، فيجب أن تساوي URL الذي طلبه العميل من خادم المورد. عند الاختلاف لا يجوز استخدام البيانات. تشابه المضيف أو المسار لا ينشئ سلطة.

تظهر قيمة ذلك في المضيف ذي المسارات أو المستأجرين المتعددين. يوضع لاحق well-known قبل مسار المورد، فيسمح لموارد مختلفة على المضيف نفسه بنشر وثائق مختلفة. ولا تعني الوثيقة معرفة عامة عن المضيف. من يحولها إلى جدول صلاحيات شامل يتجاوز حد السياسة قبل أن يطلب رمزاً.

ولا تمثل القوائم المنشورة سجلاً كاملاً للحقوق. يمكن أن تحذف authorization_servers خوادم مدعومة، ويمكن أن تحذف scopes_supported نطاقات متاحة. تضيف الميتاداتا الموقعة فقط معرفة بمن زكّى حزمة معلومات الاكتشاف؛ لا تثبت هوية العميل ولا موافقته ولا صلاحية الرمز. تظل أدوار ميتاداتا خادم التفويض في RFC 8414، ومؤشر المورد في RFC 8707، وتقديم bearer في RFC 6750 منفصلة.

Sources