الخلاصة

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

«صحيح» لا تعني أن كل الأسئلة أجيبت

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

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

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

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

واجهة Richer تصل بين سلطتين ولا تدمجهما

يظهر Justin Richer مؤلفاً لـ RFC 7662، وهي وثيقة ضمن مسار المعايير في IETF عن استبطان رموز OAuth 2.0. وينبغي ضبط النسبة بدقة: الوثيقة نتاج عملية معيارية جماعية، ولا تعني أن Richer يتحكم شخصياً في تطبيقات المؤسسات أو أنه اخترع وحده جميع آليات OAuth.

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

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

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

هوية السائل جزء من معنى الإجابة

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

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

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

كما لا ينبغي تحميل الحقول الاختيارية وظائف جديدة. يضع exp وnbf الحدود الزمنية، ويساعد aud وiss على معرفة الجمهور والمصدر، وقد يشير sub وusername وclient_id إلى أطراف مختلفة. أما jti فهو معرّف للرمز. ولأن الرمز الواحد يستخدم عادة في طلبات كثيرة، فمعرّفه ليس رقم طلب أو تحويل أو تنفيذ.

الحاضر في الذاكرة المؤقتة يصبح ماضياً

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

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

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

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

بعد قرار الوصول تبقى حقيقة التنفيذ

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

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

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

القراءة الصارمة لـ RFC 7662 لا تقلل من قيمة الاستبطان. بل تحفظ قوة إجابة معيارية عن سؤال ضيق وصعب. وحين لا يُطلب من تلك الإجابة أن تشهد على أحداث لم ترها، يظهر بوضوح موضع كل مسؤولية أخرى.

المصادر