سلسلة OAuth تقيّد الصلاحية ولا تثبت القصد

Summary

تقترح draft-li-oauth-delegated-authorization-03 رمزاً جذرياً يوقعه خادم التفويض، ثم رموزاً أبناء يوقعها محلياً حامل مفتاح الأب، ويثبت العميل الأخير حيازته لمفتاح الورقة بواسطة DPoP.
يستطيع التحقق إثبات اتصال المفاتيح وتناقص الصلاحيات والجمهور وفترة الصلاحية وعمق إعادة التفويض؛ لكنه لا يثبت سبب اختيار المفوَّض، ولا قصد المهمة البشرية، ولا أن خادم مورد يعمل دون اتصال عرف بحالة الإبطال.
يقترح Daniel Kade إيصالاً منفصلاً لقصد التفويض يربط الولاية الجذرية، وحراسة كل قفزة، وحد المهمة وأثرها، وحداثة الإبطال، وقرار المورد والإغلاق، من دون حفظ الرموز أو الأسرار.

بديل عن تسليم الرمز الأصلي

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

تعرّف المراجعة 03 Delegated Authorization Token مرتبطاً بمفتاح. يوقع authorization server الرمز الجذري، ويضع في cnf.jkt بصمة المفتاح العام للعميل الأول. وحين يبقى عمق متاح، يوقع ذلك العميل رمزاً ابناً بالمفتاح الذي ربطه الأب، ثم يربط الابن بمفتاح العميل التالي.

يتسلم resource server السلسلة كاملة وبترتيبها. يأخذ مفتاح التحقق من الجذر من إعداد موثوق أو metadata موثقة، لا من ادعاء داخل الرمز. وفي كل ابن يجب أن تطابق بصمة RFC 7638 للمفتاح العام في الترويسة المحمية قيمة cnf.jkt لدى الأب. ثم يوقع مفتاح الورقة DPoP proof يربط طريقة HTTP والوجهة والتسلسل الدقيق للسلسلة وعناصر الحداثة.

لهذا لا تكفي سرقة السلسلة النصية. يجب إثبات حيازة المفتاح الأخير. وتقترح المسودة مخطط المصادقة DA وتحظر استقبال هذه الرموز كرموز Bearer.

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

تضييق الصلاحية يحتاج معنى مشتركاً

لا يجوز للابن توسيع permissions أو audience أو مدة النفاذ أو عمق التفويض المتبقي. يمكن التعامل مع scope كمجموعة؛ فلا يظهر في الابن عنصر ليس ضمن النطاق الفعال للأب. وحذف claim النطاق يسقط هذا الجزء من الصلاحية ولا يعيد منحه ضمناً.

المقارنة أصعب مع authorization_details. قد يعتمد المعنى على مبلغ أو مورد أو فعل أو array أو wildcard أو قيمة افتراضية. وقد يكون JSON الأقصر أوسع إذا أدى حذف قيد إلى default متساهل.

لذلك تشترط المسودة أن تعرّف مواصفة كل نوع قاعدة containment حتمية. لا تكفي مطابقة النص الخام أو اسم type. وإذا لم يستطع verifier إثبات أن قيمة الابن مشمولة في القيمة الفعالة للأب، فعليه رفض السلسلة.

وينطبق المبدأ نفسه على extension claims المؤثرة في التفويض. لا يجوز الاعتماد على قيد لا يفهمه كل verifier مقصود. فالقيد الموقع الذي يتجاهله خادم المورد ليس تضييقاً، بل مظهر تضييق.

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

العمق عدد قفزات لا مقياس خطورة

يحمل كل جذر max_delegation_depth محدوداً. إذا كانت القيمة الفعالة صفراً فلا يصح ابن. وإذا كانت m موجبة، جاز للابن أن يحدد قيمة بين صفر وm-1، ويؤدي الحذف إلى m-1. كما يضع authorization server سقفاً محلياً، وتضع التطبيقات حدوداً مستقلة لعدد الرموز وحجمها وكلفة التحقق.

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

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

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

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

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

هذه هي نقاط الوصل بين صلاحية عامة وقرار عملي.

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

وتقول المسودة بوضوح إن نجاح chain validation لا يأذن بطلب المورد وحده. فما زال الخادم يراجع DPoP وrequest binding وaudience والصلاحيات الخاصة بالتطبيق. وحتى قرار allow لا يثبت نجاح التنفيذ؛ فقد يفشل الفعل أو ينتج أثراً لاحقاً خارج رؤية الخادم.

الولاية الجذرية، وحراسة القفزات، وقصد المهمة، والصلاحية الراهنة، والأثر المرصود خمسة أسئلة منفصلة.

للإبطال زمن كتابة وزمن وصول

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

نجاح طلب الإبطال يسجل حالة لدى authorization server. لا يرسلها تلقائياً إلى resource server يتحقق بلا اتصال. ولا تعرّف المراجعة 03 آلية توزيع. تقلل الرموز القصيرة مدة الجهل، لكنها لا تثبت متى وصلت المعلومة إلى كل verifier.

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

ولا يلغي cache هذا الفرق. يجوز حفظ التواقيع والقيود الفعالة وفق digest السلسلة، لكن يجب إبطال المدخل بحسب انتهاء الصلاحية وحالة مفاتيح الخادم والسياسة المحلية وما وصل فعلاً من الإبطال. تبقى حداثة DPoP ومنع replay لكل طلب.

الخصوصية تنقل نقطة المراقبة

يقلل التفويض المحلي رؤية authorization server؛ فلا يلزمه أن يعرف كل delegate أو resource أو وقت وصول أو مسار متعدد القفزات. هذه فائدة حقيقية ضد مركزية بيانات العمل.

في المقابل يرى resource server السلسلة المرتبة كاملة. قد تكشف claims عن issuer وsubject وعلاقات العملاء والجمهور والصلاحيات وبنية workflow. وقد تتيح cnf.jkt مستقرة أو معرفات دائمة الربط بين طلبات وخدمات مختلفة.

لا تختفي audit visibility بل تنتقل. يرى الخادم إصدار الجذر، ويرى العميل الموقع التفويض المحلي، ويرى المورد نتيجة التحقق والقرار. توصي المسودة باستخدام digest أحادي الاتجاه لربط الأحداث، وبحذف Authorization وDPoP headers من السجلات الروتينية، وبحماية تفاصيل التفويض ومعرفات الأشخاص.

المطلوب ليس مخزناً مركزياً للcredentials، بل reconciliation محدود البيانات بين ملاحظات موزعة.

المفتاح الواحد يستخدم الصلاحية وينسخها

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

تقترح المسودة مفاتيح غير قابلة للتصدير وsigning APIs ضيقة تميز مدخلات token signing من proof signing، ويفضل استخدام مفتاح متميز لكل token. إعادة الاستخدام توسع قابلية الربط ونطاق الحادث.

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

بصمة المفتاح تثبت المفتاح، لا العملية التي سيطرت عليه ولا سياسة واجهة التوقيع ولا المهمة التي ظنت المؤسسة أنه يخدمها.

إيصال قصد التفويض

أقترح إيصال قصد التفويض. إنه تصميم حوكمة من Daniel Kade خارج البروتوكول، وليس claim جديداً ولا متطلباً في المسودة.

يسجل قسم الجذر digest آمناً لحدث authorization وإصدار شاشة الموافقة، والـissuer وtrusted metadata snapshot، وقدرة إعادة التفويض، والصلاحيات الفعالة، والجمهور والمدة والعمق. ولا يحفظ token أو private key أو DPoP proof أو headers خاماً أو بيانات subject غير لازمة.

يسجل كل hop digest السلسلة، وبصمتي مفتاح الأب والابن العامتين، والقيود قبل وبعد، وقاعدة containment وإصدارها، وهوية signing service، وأقل دليل على سبب اختيار العميل. ويشير إلى key reuse وإلى اشتراط parent واحد إن وجد.

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

عند المورد، يحفظ إصدار policy، وتنفيذ المقارنة، وإصدار revocation state المستلم وحداثته، ونتيجة DPoP، والصلاحية المحسوبة وقرار السماح أو الرفض. وعند الإغلاق، يسجل نوع العملية والنجاح أو الفشل والآثار الجوهرية ومرجع rollback أو incident.

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

إبقاء النتيجة ضمن حدودها

المراجعة 03 Internet-Draft فردية محدثة في 24 يوليو/تموز 2026. ليست وثيقة اعتمدتها OAuth WG، ولا إجماع IETF، ولا Last Call، ولا موافقة IESG، ولا RFC، ولا تسجيلات IANA نافذة. ولا يثبت تفصيلها وجود تطبيق أو تبنٍ.

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

القول الدقيق هو أن مفاتيح محددة امتلكت سلطة تضييق منحة واستعمالها وفق شروط محسوبة. ليس القول إن الإنسان أراد هذا العميل وهذه المهمة وهذا الأثر.

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

سلسلة التفويض تضيّق الصلاحية لكنها لا تحمل القصد

لماذا هذا مهم

Summary

بديل عن تسليم الرمز الأصلي

تضييق الصلاحية يحتاج معنى مشتركاً

العمق عدد قفزات لا مقياس خطورة

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

للإبطال زمن كتابة وزمن وصول

الخصوصية تنقل نقطة المراقبة

المفتاح الواحد يستخدم الصلاحية وينسخها

إيصال قصد التفويض

إبقاء النتيجة ضمن حدودها

المصادر

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

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

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

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

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