معالجة OAuth تحتاج إلى سجل لفارق الصلاحية

الخلاصة

يتيح draft-ietf-oauth-rar-metadata-remediation-00 لخادم المورد أن يجيب عن طلب OAuth صالح لكنه غير كافٍ بخطأ قابل للتنفيذ يحمل كائنات Rich Authorization Requests يمكن للعميل استخدامها في تدفق تفويض جديد.
خادم المورد لا يمنح الصلاحية. إنه يصف ما يعتبره كافياً، بينما يبقى التحقق والسياسة والموافقة والتضييق أو الرفض لدى خادم التفويض ومالك المورد، ثم يعيد خادم المورد إنفاذ القرار عند المحاولة الجديدة.
يقترح Daniel Kade سجل «فارق الصلاحية» لحفظ الطلب الفاشل والصلاحية القائمة والتفاصيل المقترحة ومصدر المخطط ونتيجة الموافقة وما مُنح وما حدث للمورد. هذا اقتراح حوكمة تشغيلية وليس جزءاً من المشروع.

عندما يحتوي الرفض على طلب الصلاحية التالي

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

يقترح أول إصدار لمجموعة عمل OAuth من مشروع بيانات RAR الوصفية ومعالجة الأخطاء مساراً أدق. يستطيع خادم المورد إعادة HTTP 401 مع الخطأ insufficient_authorization. ويمكن للمعامل authorization_remediation أن يحمل authorization_details مبنية على الطلب الذي فشل، إلى جانب authorization_reference اختياري. بعدها يبحث العميل عن رمز وصول موجود أو يضع التفاصيل في طلب تفويض OAuth جديد.

يعالج ذلك فجوة فعلية. فقد أعطى RFC 9396 لـOAuth لغة منظمة للصلاحيات الدقيقة، لكنه لم يحدد كيف يكتشف العميل كل أنواع التفاصيل ولا كيف يتعافى عندما يقول المورد إن الرمز لا يحمل التفويض اللازم. يضيف الإصدار 00 نقطة بيانات وصفية للمخططات والأمثلة، وإشارة فشل، وقواعد لمعالجة الاقتراح.

المشروع عمل نشط لمجموعة العمل بتاريخ 23 أغسطس 2026. وقد حل محل مشروع فردي بعدما أظهرت محاضر جلسة OAuth في IETF 126 تأييداً للمشكلة ونقاشاً للحل واتجاهاً إلى طلب التبنّي. لكنه ليس RFC، ولا يملك موعداً في IESG، ولا يقدم نتائج نشر ميداني. كما أن أسماء السجل المقترحة ليست تعيينات IANA مكتملة.

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

المورد يحدد شرط الكفاية ولا يصدر المنحة

يقول المشروع إن التفاصيل القابلة للتنفيذ تُبنى من طلب المورد الفاشل، وإن إدراجها في منحة ناجحة ينبغي أن يلبي متطلبات المورد. لذلك يملك خادم المورد سلطة صياغة الاقتراح: يحدد البنية التي يريد رؤيتها قبل تنفيذ العملية.

لكن الاقتراح يمر عبر حدود تحكم متعددة. يقرر العميل هل يتعامل مع التحدي. ويتحقق خادم التفويض من النوع ويطبق سياساته ويدير التدفق المناسب. ويتطلب RFC 9396 عرض الصلاحيات المطلوبة للموافقة، ويمكن لمالك المورد منح جزء فقط أو الرفض. وتعرض استجابة الرمز تفاصيل التفويض التي مُنحت فعلاً. ثم يفحص خادم المورد الرمز والعملية من جديد.

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

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

لا يحسم حجم JSON هذا السؤال. ينص RFC 9396 على غياب آلية عامة لمقارنة طلبين اعتباطيين من تفاصيل التفويض، لأن معنى الحقول تحدده واجهة البرمجة. قلة الحقول لا تعني دائماً سلطة أقل؛ فقد يؤدي غياب حد إلى تشغيل قيمة افتراضية، أو تمثل مصفوفة اتحاداً، أو يغيّر معرف المورد الجهة المحمية كلها.

المرجع المبهم يساعد على البحث ولا يحكم بالسياسة

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

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

كما أن اختلاف المرجعين لا يثبت زيادة الصلاحية. يذكر المشروع أن رمزاً يسمح بخصم دوري حتى 100 قد يغطي طلباً بقيمة 80 رغم اختلاف المرجع. علاقة الاحتواء دلالية، وليست مقارنة نصين مبهمين. المرجع يسرّع اختيار رمز مرشح؛ ويبقى الحكم لخادم المورد.

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

المخطط يثبت البنية لا الغرض

يقترح الإصدار 00 نقطة بيانات وصفية لأنواع تفاصيل التفويض. يمكن لكل نوع نشر إصدار معلوماتي ووصف ورابط وثائق وأمثلة وJSON Schema مضمناً أو عبر schema_uri. يجب أن يصف المخطط كائناً واحداً وأن يقيد حقل type بمعرف النوع.

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

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

قد تغيّر البيانات الوصفية مسار الثقة أيضاً. فإذا لم يدعم خادم التفويض الحالي النوع المطلوب، يتيح المشروع اكتشاف خوادم بديلة عبر Protected Resource Metadata. هذه قابلية تشغيل مهمة، لكن المُصدر الجديد ليس وجهة إعادة محاولة شفافة؛ فقد تختلف لديه قواعد تسجيل العميل والمصادقة والموافقة والاحتفاظ والرقابة.

سجل لفارق الصلاحية

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

يبدأ السجل بالرفض: جلسة المستخدم ومنشأ خادم المورد، والتزام مشفر بالطلب الفاشل وفئة العملية، والنطاقات أو تفاصيل التفويض الفعالة في الرمز المقدم. لا تُنسخ أرقام الحسابات أو البيانات الطبية أو شروط المعاملة الحساسة إلى السجل؛ تستخدم مراجع ضيقة أو التزامات مملحة قصيرة العمر.

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

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

وفي النهاية يتبع السجل إعادة المحاولة: يربط المرجع داخل الجلسة والمنشأ فقط، ويعد محاولة الرمز المخزن وجولة التفويض الجديدة، ويسجل قرار المورد النهائي وأثر العملية أو مرجع التراجع. ولا يخزن الرمز أو السر أو كائن RAR الحساس كاملاً لمجرد سهولة التدقيق.

بهذا يقدم كل طرف تصريحاً محدوداً. يثبت خادم المورد ما اقترحه. ويثبت العميل كيف تعامل معه. ويثبت خادم التفويض ما عرضه وأصدره. وترتبط موافقة المالك بالقرار الفعلي. أما نجاح تبادل OAuth فلا يُسوّق بوصفه دليلاً على اكتمال العملية التجارية نفسها.

الخصوصية قيد تصميم وليست إعفاءً من التوثيق

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

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

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

قد تتحول استعادة الخطأ إلى أتمتة للسياسة

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

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

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

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

تحدي المعالجة في OAuth يقترح صلاحية جديدة لا مجرد إعادة محاولة

لماذا هذا مهم

الخلاصة

عندما يحتوي الرفض على طلب الصلاحية التالي

المورد يحدد شرط الكفاية ولا يصدر المنحة

المرجع المبهم يساعد على البحث ولا يحكم بالسياسة

المخطط يثبت البنية لا الغرض

سجل لفارق الصلاحية

الخصوصية قيد تصميم وليست إعفاءً من التوثيق

قد تتحول استعادة الخطأ إلى أتمتة للسياسة

المصادر

سياق أعمق للملف الشخصي

الدائرة الاستراتيجية

تحالف القيادات

إحاطة الدائرة الاستراتيجية

إحاطة تحالف القيادات