الخلاصة

  • تمنح RFC 9207 عميل OAuth إيصالاً محدوداً: يجب أن تتطابق هوية المُصدِر في استجابة التفويض مع المُصدِر المحفوظ لهذا الطلب. عند الاختلاف يتوقف التدفق قبل إرسال الرمز إلى endpoint غير مقصود.
  • يحدد iss سياق خادم التفويض. لكنه لا يصادق على المستخدم، ولا يتحقق من رمز التفويض، ولا يثبت إصدار token أو جمهوره أو نطاقه أو قرار خادم الموارد.
  • لذلك يحتاج التشغيل القابل للتدقيق إلى سجلات منفصلة لحالة الطلب، والمُصدِر المتوقع، والبيانات الوصفية، والمُصدِر المستلم، ونتيجة المقارنة، واستبدال الرمز، والتحقق من token، وقرار المورد، والاسترداد.

لا تبدو الاستجابة الخطرة شاذة.

يعود المتصفح إلى redirect URI مسجل. وتطابق قيمة state ما أنشأه العميل. وتحمل الاستجابة رمز تفويض أصدره خادم صادق. لم تُسرق كلمة مرور ولم يُزوّر الرمز. ومع ذلك يستطيع عميل يتعامل مع أكثر من خادم تفويض أن يرتكب خطأ المسار الحاسم: يرسل الرمز الحقيقي إلى token endpoint يسيطر عليه المهاجم.

المشكلة ليست في سجل زائف بصورة ظاهرة، بل في وصل سجلين معقولين على نحو خاطئ. يسجل الأول الخادم الذي اعتقد العميل أنه اختاره عند البداية. أما الثاني فهو استجابة عادت عبر متصفح المستخدم. لم تكن استجابة OAuth 2.0 الأصلية تحمل تعريفاً صريحاً بالخادم الذي أنشأها. وإذا محا callback عام أو metadata معادية هذا الحد، فقد تنتقل credential صحيحة إلى سطح تشغيل يملكه طرف آخر.

تعالج RFC 9207 الفجوة بعنصر صغير عن قصد. نُشرت OAuth 2.0 Authorization Server Issuer Identification في مارس 2022 ضمن مسار معايير IETF، وهي عمل مشترك بين Karsten Meyer zu Selhausen وDaniel Fett. وتعرّف المعلمة iss داخل استجابة التفويض. يضع الخادم الداعم هوية مُصدِره في استجابات النجاح والخطأ. ثم يقارن العميل القيمة بالمُصدِر الذي سجله للخادم الذي أرسل إليه الطلب.

إذا لم تتطابق السلسلتان، فعلى العميل رفض الاستجابة وعدم مواصلة grant.

هذه هي سلطة الحقل كلها، ومنها تأتي قيمته.

كانت الاستجابة بلا اسم مرسلها

يفصل OAuth الأدوار قصداً. يستخدم مالك المورد user agent. ويطلب العميل grant من خادم التفويض. ثم يقدم الرمز إلى token endpoint، ويستعمل access token لاحقاً عند خادم الموارد. يتيح الفصل تركيب خدمات مستقلة، لكنه يخلق قرارات مسار لا يجيب عنها وصول المتصفح وحده.

وضعت RFC 6749 الرمز في الاستجابة، وأعادت قيمة state ذاتها إذا كانت موجودة في الطلب. وهذه القيمة أساسية لأنها تربط الاستجابة بحالة المتصفح المصادق عليها وتساعد على منع CSRF. لكنها لا تجيب سؤالاً آخر: أي خادم تفويض أصدر الاستجابة؟

عندما لا يوجد سوى خادم واحد قد يظل الفرق خفياً، إذ لا توجد مجموعة endpoints منافسة. عند إضافة خادم ثان لا يكفي أن يتذكر العميل أن هناك «تدفق OAuth معلقاً». يجب أن يتذكر إلى أي مُصدِر ينتمي. وتلزم RFC 9700، وهي ممارسة OAuth الأمنية الحالية، العملاء المتعاملين مع خادمين أو أكثر بمنع mix-up وربط المُصدِر المقصود بكل طلب.

يساعد السجل العام لـDaniel Fett في وضع المشكلة ضمن سياقها من دون تحويل معيار جماعي إلى أسطورة فردية. يعرّف موقعه الشخصي به كمستشار أمن متخصص في الهوية وأمن بروتوكولات الويب ويعمل على OAuth وOpenID Connect. وفي سبتمبر 2026 كان Datatracker يعرض أربعة RFCs باسمه، بينها RFC 9207. يبين ذلك استمرارية مجال البحث، لا ملكية منفردة للنص ولا تحكماً في أي نشر فعلي.

المُصدِر يعني حزمة endpoints

ليست هوية المُصدِر اسماً للعرض. تعرفها RFC 8414 على أنها URL يستخدم HTTPS ولا يحتوي query أو fragment. وترسو عليها وثيقة metadata يمكن أن تسمي authorization endpoint وtoken endpoint ومواقع المفاتيح وقدرات أخرى. وقد يستضيف اسم واحد مُصدِرين مختلفين تفصل بينهما المسارات.

الحزمة هي الشيء الذي يحتاج إلى حماية. يستطيع المستخدم رؤية صفحة تفويض صادقة فيما يربط تكوين العميل تلك الصفحة بـtoken endpoint للمهاجم. وتحذر RFC 9700 من أن حفظ عنوان authorization endpoint وحده غير كاف؛ فقد يعلن طرف خبيث عنوان خادم صادق كأنه عنوانه ثم يضع endpoint تحت سيطرته لاستبدال الرمز. هوية المُصدِر هي المؤشر المستقر للمجموعة كلها.

تعيد RFC 9207 وصل الاستجابة الآتية عبر المتصفح بهذه المجموعة. عند استخدام RFC 8414 يجب أن تتطابق iss في الاستجابة تماماً مع issuer في metadata، ويمكن للخادم إعلان الدعم عبر authorization_response_iss_parameter_supported. يستخرج العميل القيمة، ويفك ترميز النموذج، ثم يجري مقارنة حرفية بسيطة مع القيمة المتوقعة للطلب.

لا مكان للتشابه التقريبي. مسار مختلف، أو شرطة مائلة إضافية، أو مُصدِر آخر على المضيف نفسه ليس «قريباً بما يكفي». القرار ليس لغوياً للبشر؛ بل توجيه حتمي.

تبقى سلطة القرار محلية. يعلن الخادم هويته، وتصف metadata مجموعته، ويسجل العميل اختياره وحالة الدعم ويقارن ثم يرفض. لا تنفذ جهة عالمية المقارنة نيابة عنه. الحقل المشترك واجهة دنيا ولا ينتزع القرار المستقبلي من المشغل.

التطابق يسمح بالمتابعة ولا يثبت النتيجة

أسهل سوء استخدام لـiss هو تحميله معنى أوسع.

لا يصادق تطابق المُصدِر على مالك المورد. قد يطلب الخادم تسجيل الدخول أو يعيد خطأ. ولا يثبت أن المستخدم فهم scope المطلوب أو قصده؛ فهذا شأن تفاعل التفويض وسياسة المنتج.

ولا يتحقق التطابق من رمز التفويض. بعد اختيار token endpoint الصحيح، يبقى على ذلك endpoint فحص الرمز، ومصادقة العميل عند الحاجة، ومطابقة redirect URI وبقية الشروط. قد يكون الرمز منتهي الصلاحية أو معاد الاستخدام أو مرتبطاً بعميل آخر.

كما لا يثبت iss أن token قد صدر. فهو لا يحدد النوع أو audience أو scope أو العمر أو sender constraint أو حالة الإلغاء. يتخذ خادم الموارد قراره عند تقديم token. وحتى الرمز الصحيح لا يثبت نجاح الإجراء التطبيقي أو رؤية المستخدم للنتيجة.

تتكون سلسلة الإثبات من مراحل: إنشاء الطلب وحفظ المُصدِر مع حالة المتصفح؛ وصول الاستجابة؛ قيمة iss؛ نتيجة المقارنة والقبول أو الرفض؛ اختيار endpoints من metadata متحقق منها؛ قبول الرمز أو رفضه؛ التحقق من token وتطبيق السياسة عند المورد؛ النتيجة المرصودة وإمكان الاسترداد.

تملك RFC 9207 مرحلة المقارنة. وصفها بأنها «نجاح OAuth» يحذف كل القرارات اللاحقة.

الحقل ليس توقيعاً رقمياً

لا تتمتع iss في الاستجابة العادية بحماية تشفيرية. تقول RFC 9207 ذلك بوضوح. ولا يظهر التناقض إلا إذا عوملت المعلمة كشهادة أصالة شاملة.

نموذج التهديد أضيق. في mix-up يتلقى العميل استجابة أنشأها خادم غير مخترق، لكنه يخطئ في مجموعة endpoints التي ينبغي أن تستلم الرمز. وإذا استطاع المهاجم تعديل الاستجابة الصادقة قبل وصولها إلى العميل، فهو يستطيع أيضاً قراءة الرمز مباشرة ولا يحتاج إلى مسار mix-up. تمنع المعلمة ارتباك المسار في هذا النموذج، ولا تدعي سلامة الاستجابة أمام كل مهاجم.

حين يتطلب النظام سلامة مشفرة، يمكن لآليات أخرى نقل المُصدِر داخل غلاف محمي. يضع JARM المعلمات داخل JWT موقع. ويمكن لبعض تدفقات OpenID Connect التي تعيد ID Token من authorization endpoint أن تنقل المُصدِر إذا تحقق العميل منه. وإذا ظهرت معرفات مُصدِر متعددة ومتعارضة وجب رفض الاستجابة.

هذه صورة عملية لمبدأ الحد الأدنى من المواصفات الأولية: إضافة أصغر إشارة مشتركة تكشف الغموض، وترك الأغلفة الأقوى وسياسة التوافق وسرعة الانتقال للقرار المحلي. وتسمح RFC 9700 أيضاً بعناوين redirect URI مختلفة لكل مُصدِر إذا تحقق العميل منها.

التوافق القديم يحتاج إلى مالك وموعد نهاية

لا تُحدّث جميع الخوادم معاً. لذلك تحتفظ RFC 9207 بحالة دعم لكل خادم ولا تفترض انتشاراً عالمياً.

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

تحدد هذه المرونة المسؤولية. يحتاج العميل متعدد المُصدِرين إلى جرد للمُصدِرين وmetadata وendpoints وحالة الدعم ومصدرها وتاريخها والاستثناء القديم ومالكه وموعد إزالته. ومن دون نهاية يتحول «التوافق» إلى طريق دائم حول الدفاع.

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

الإيصال الذي يمكن اختباره فعلاً

لا تثبت قراءة metadata مرة واحدة نتيجة التشغيل. يبدأ الاختبار عند إنشاء الطلب.

يسجل معرف الطلب، وربطه بالمتصفح، والمُصدِر المختار، وإصدار metadata، وendpoints، وعلم الدعم، وredirect URI. وعند العودة يسجل وجود iss وقيمتها بعد فك الترميز والقيمة المتوقعة ونتيجة المقارنة، وهل مُنع استبدال الرمز فعلياً بعد الاختلاف. ويغطي النجاح والخطأ والغياب والتكرار والمُصدِر المجهول ومسارين مختلفين على المضيف نفسه.

الاختبار السلبي هو الحاسم. بعد الاختلاف يجب ألا يصل أي طلب يحمل الرمز أو بيانات اعتماد العميل أو token إلى endpoint غير المتوقع. ينبغي أن تتفق سجلات العميل مع سجلات endpoints اختبارية. رسالة خطأ مرئية مع طلب شبكة صادر ليست دفاعاً.

وفي التحقيق لا يجوز دمج الطبقات. يثبت اختلاف المُصدِر فشل مقارنة، لا اختراقاً بالضرورة. يثبت رفض token endpoint أنه رفض grant واحداً، لا أن الاستجابة عدائية. ولا يثبت رفض المورد بأثر رجعي أن ربط المُصدِر كان صحيحاً.

ينجح الحقل عندما يحول غموضاً خفياً إلى قرار إلزامي قبل انتقال السر. إنه يسمّي الخادم، لكنه يترك إثبات token والنتيجة لأصحاب القرار المناسبين.

المصادر