الخلاصة

  • أُعلن عن المراجعة 01 من draft-zehavi-oauth-authz-req-del-chain في 10 سبتمبر 2026 بوصفها Internet-Draft فردية، وليست وثيقة متبناة من فريق OAuth ولا RFC.
  • تحمي تواقيع JWS المنفصلة، وتجزيئات العقد السابقة، والترقيم، واستمرارية الجمهور سلامة مسار الوسطاء الظاهر لخادم التفويض الأعلى.
  • يؤدي حذف الذيل أو عقدة من الوسط إلى فشل التحقق، لكن وسيطاً يستطيع إنشاء سلسلة جديدة صحيحة يبدأ فيها بنفسه عند chain[0].
  • لذلك تُلزم المسودة خادم التفويض بسياسة محلية تقرر هل يجوز لذلك المُصدر أن يكون أول مُصدر مرئي لهذا العميل والمورد والسياق.

الصفر في الحقل ليس بداية التاريخ

يصل طلب تفويض إلى الخادم ومعه عدد من إفادات الوسطاء. آخر عقدة موجهة إلى الخادم المستلم، ومُصدرها مرتبط بعميل OAuth الذي جرى توثيقه. الأرقام متتالية، والتجزيئات متطابقة، وكل جمهور يقود إلى المُصدر التالي. لا يظهر أي خلل.

هذا يثبت اتساق المادة المستلمة. ولا يثبت أن المادة بدأت عند أول حدث فعلي.

تتناول مسودة OAuth Authorization Request Delegation Chain طلبات إعادة التوجيه التي تمر عبر وسيط واحد أو أكثر. يعمل كل وسيط خادم تفويض تجاه الجهة الأدنى وعميل OAuth تجاه الجهة الأعلى. وقد لا يعرف الخادم النهائي، الذي يطلب الموافقة ويصدر الرموز، سوى الوسيط المباشر.

تقترح الوثيقة كائن authorization_details وفق RAR يحمل مصفوفة مرتبة من عقد JSON. تسمي كل عقدة الجهة التي تشهد، والجهة المقصودة، وموضعها، والعميل الذي تشهد له. يغطي توقيع JWS منفصل تمثيلاً حتمياً للعقدة، ويربط p_hash العقدة بالحدث الموقع السابق.

يبدأ التحقق من النهاية ويتحرك إلى الخلف. يفحص الخادم الجمهور النهائي، وربط المُصدر بالعميل الفعلي، ثم المفاتيح والتواقيع والأرقام ومساحات الأسماء والتجزيئات والعلاقة بين جمهور كل عقدة ومُصدر التالية. والكلمة الحاسمة هي أن هذه الاختبارات تحمي السلسلة المرئية.

موضع الحذف يحدد ما إذا بقي أثر

تميز المراجعة 01 بين ثلاث حالات. إن حُذف الذيل فلن تنتهي السلسلة بجمهور يطابق الخادم المستلم. وإن حُذفت عقدة من الوسط فسيفشل تجزيء العقدة السابقة المسجل لدى خليفتها وتنقطع استمرارية الجمهور.

أما حذف الرأس فيتيح إعادة البدء. يستطيع الوسيط ترك السياق السابق وإنشاء سلسلة يضع نفسه فيها عند الرقم صفر ويجعل التجزيء السابق null. قد تكون كل التواقيع بعد ذلك أصلية. تسمي المسودة هذا إعادة الإنشاء من منشأ جديد، وتقول إن التحقق التشفيري لا يستطيع إثبات عدم وجود سياق قبل chain[0].

ليس ذلك تقريراً عن هجوم. إنه حد معلن في التصميم. سلسلة التجزئة تشهد للاتساق بعد بداية مصرح بها، لكنها ليست شاهداً مستقلاً على اكتمال تلك البداية.

ينتقل القرار عندها إلى السياسة المحلية: هل يحق لهذا المُصدر أن يظهر أولاً مع هذا العميل والمورد وطريقة النشر؟ كما أن صحة التوقيع لا تمنح حق الوساطة. تستطيع قيمة oauth_broker في بيانات client_roles وصف دور العميل، لكن الدور الذي يعلنه صاحبه لا يثبت الثقة أو السلطة. ويبقى توثيق العميل المباشر مطلوباً.

السماح بالإسقاط اللاحق لا يكشف الماضي

تضيف المراجعة اكتشاف دعم الخادم الأعلى عبر بيانات RFC 8414. وإذا لم يدعم الخادم التالي نوع السلسلة فلا يجوز للوسيط إسقاطها بصمت.

عليه أن يرفض العملية، أو يحفظ السياق بآلية موثوقة أخرى، أو يرسل بلا سلسلة فقط إذا سمحت السياسة المحلية والسلسلة الموقعة بذلك. يأخذ الحقل الاختياري omit_chain القيمة allowed أو forbidden، ويعني غيابه المنع. ولا يصبح الإسقاط ممكناً إلا إذا سمحت به كل عقدة جرى التحقق منها.

تجعل هذه القاعدة خسارة دليل معروف قراراً صريحاً. لكنها لا تكشف ما ربما حُذف قبل إنشاء العقدة الأولى. تخفيف الدليل في القفزة المقبلة وقبول منشأ جديد حكمان منفصلان.

تطلب النسخة أيضاً تسجيل client_roles لدى IANA. يظل الطلب جزءاً من مسودة فردية، ولا يثبت تخصيصاً أو إجماعاً أو تبنياً أو تنفيذاً أو نشرًا أو حادثة.

المصادر