من يتحمل مسؤولية طلب المصادقة مرة أخرى؟

الخلاصة

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

عائق مشروع، ومسؤولية غير محسومة

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

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

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

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

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

لا توجد سُلّم قوة عالمي داخل أسماء السياقات

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

توضح مواصفة OpenID Connect Core الفرق بين طلب قيم مفضلة وبين جعل مطالبة محددة شرطا أساسيا. فطلب acr_values المعتاد لا يساوي تلقائيا مطالبة أساسية لا يجوز تجاوزها. وعند استخدام مطالبة acr أساسية بقيم محددة، في الحالة التي يدعم فيها الخادم آلية claims ذات الصلة، تصبح مطابقة إحدى القيم المطلوبة لازمة، وإلا تعامل محاولة المصادقة على أنها فاشلة.

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

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

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

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

الساعة التي تهم ليست ساعة إصدار الرمز

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

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

يشرح RFC 9068 الخاص برموز الوصول بصيغة JWT كيف ترتبط مطالبات مثل auth_time وacr وamr بحدث المصادقة الأصلي، وتظل قيمها ثابتة في الرموز المشتقة من استجابة التفويض نفسها، بما في ذلك المسارات المرتبطة بالتجديد أو التبادل. أي إن حداثة الغلاف لا تعيد كتابة تاريخ الواقعة التي يستند إليها.

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

يمكن لخادم الموارد أن يحصل على معلومات الرمز بواسطة آلية مناسبة له، ومنها الاستعلام عن الرمز في RFC 7662. لكن كون الرمز active لا يجيب وحده عن سؤال: هل المصادقة المرتبطة به حديثة أو ذات سياق ملائم لهذا الإجراء؟ يضيف RFC 9470 استخدام معلومات acr وauth_time في هذا السياق؛ ولا ينبغي نسبة كل هذه الدلالات إلى الحقل المنطقي الذي يصف نشاط الرمز.

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

حين تتحول إعادة المحاولة إلى سياسة غير معلنة

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

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

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

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

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

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

التحدي نفسه يستهلك الثقة

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

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

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

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

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

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