الخلاصة

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

ما الذي تثبته شاشة التجديد؟

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

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

صدر RFC9470 في سبتمبر 2023 ليصف بروتوكول تحدّي المصادقة الإضافية في سياق OAuth. يستطيع المورد أن يبلّغ أن قوة الحدث المرتبط بالرمز أو عمره لا يفيان بمتطلباته. لا يحدد النص آليات مصادقة الشخص نفسها. يعتمد على طبقة منفصلة، ويحظر استخدام الوثيقة لتقديم OAuth بوصفه بروتوكول مصادقة. يمكن أن تدخل معلومات المصادقة في قرار التفويض من دون أن يصبح التفويض هو المصادقة.

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

يوضح حقل iat في JWT إحدى الساعتين. يعرّفه RFC7519 باعتباره وقت إصدار JWT، ويمكن استخدامه لمعرفة عمره. لا يحدد آخر وقت خضع فيه المستخدم لمصادقة نشطة. وجوده في القاعدة العامة اختياري، من دون إلغاء متطلبات ملف استخدام معين. وحتى تاريخ إصدار جرى التحقق منه لا يحل محلّ وقت مصادقة غير موجود في الأدلة.

يجيز RFC9068 معلومات مثل auth_time وacr وamr في سياقات التفويض المعنية. تبقى قيمها ثابتة بين الرموز المشتقة من استجابة تفويض واحدة، بما في ذلك التجديد والتبادل. ويوضح RFC9470 الفرق بالنسبة إلى auth_time وacr. يجب الاحتفاظ بقيد المصدر المشترك: إذا وقع حدث مصادقة جديد فعلًا، فهو دليل آخر. لا تزعم الدراسة أن أي مسار تجديد ممكن يستحيل أن يتضمن مصادقة.

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

طلب المورد ينظر إلى المصادقة

يشير insufficient_user_authentication إلى عدم استيفاء متطلبات المصادقة لدى المورد. لا يساوي دائمًا انتهاء الرمز أو نقص الصلاحيات. يمكن أن يتضمن التحدّي acr_values، قائمة فئات سياق مقبولة بحسب الأفضلية، وmax_age، الزمن المنقضي المسموح منذ المصادقة النشطة. ويمكن أن يرد الاثنان معًا. وإذا كان scope ناقصًا أيضًا، فيمكن إظهاره وفق قواعد Bearer المشار إليها.

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

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

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

قد يكون الفشل الصريح هو النتيجة الأدق

يعامل OpenID Connect Core طلب acr_values بوصفه طلب سمة اختيارية. لا تضمن قواعد السياق في ID Token تحقيق كل مستوى مرغوب بصورة مطلقة. وتتطلب قواعد max_age محاولة إعادة مصادقة نشطة إذا تجاوز الوقت المدة المسموحة، وإدراج auth_time في رمز الهوية المعاد. لا تثبت قواعد رمز الهوية، مع ذلك، محتوى أي رمز وصول يُقدَّم إلى مورد لاحقًا.

يتناول RFC9470 رموز الوصول لدى الخوادم الملتزمة بإضافته. يصف إدراج acr وauth_time استجابة للمعلمات المقابلة. والأهم أنه يحث على اعتبار قيمة acr المطلوبة ضرورية لتلبية الطلب: تحقيقها، أو الفشل مع unmet_authentication_requirements، بدل تقديم رمز آخر لا يزال غير مناسب لما يطلبه المورد.

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

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

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

لا توجد طريقة دليل واحدة لكل الموارد

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

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

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

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

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

استيفاء المصادقة لا يمنح نطاقًا جديدًا

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

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

قد تظل السياسة المستحيلة مستحيلة بعد شرحها

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

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

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

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

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

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

المصادر