الخلاصة

  • نُشرت المراجعة 11 من draft-ietf-oauth-attestation-based-client-auth في 3 سبتمبر 2026، وفتحت مجموعة OAuth النداء الأخير في 8 سبتمبر حتى يوم 22.
  • توفير التحدي اختياري للخادم. ويقرر الخادم وحده، بسياسته المحلية، مدة صلاحيته وإمكان استخدامه في إقرار حيازة واحد أو أكثر. على العميل استعمال أحدث قيمة، ويجوز له إعادة استخدامها.
  • يرفض خادم الاستخدام الواحد المحاولة الثانية برمز use_attestation_challenge ويرسل قيمة جديدة؛ وينبغي للعميل أن يعيد الطلب مرة واحدة لا إلى ما لا نهاية. أما نمط DPoP المدمج فيستخدم nonce الخاص بـRFC 9449.
  • تضيف المراجعة بيانات وصفية للطرق والخوارزميات، لا لقاعدة الاستهلاك. يقترح Daniel Kade إعلاناً لسياسة الحداثة على مستوى profile؛ وهو تحليل تحريري لا متطلباً أقره IETF.

النداء الأخير يفتح اختبار الإجماع

يطلب إعلان مجموعة OAuth من المشاركين إعلان التأييد أو تفسير الاعتراض قبل 22 سبتمبر. ويعرض Datatracker المراجعة 11 بوصفها مسودة نشطة للمجموعة في مرحلة Working Group Last Call. لهذه الخطوة وزن مؤسسي، لكنها لا تجعل النص RFC ولا تثبت إجماع IETF بأكمله.

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

في النمط العادي يكون الدليل Client Attestation PoP JWT، ويحمل وقت الإنشاء ومعرف jti فريداً. ويمكن للخادم أن يضيف حداثة من اختياره بواسطة تحدٍّ مبهم للعميل. تصل القيمة مع خطأ، أو ضمن استجابة سابقة، أو من challenge endpoint منشور. وبعد تلقيها يجب على العميل وضع أحدث تحدٍّ في الدليل التالي.

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

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

الخطأ أصبح وسيلة للاستعلام عن السياسة

بعد وقوع التعارض، يرسم النص طريقاً واضحاً. يعيد خادم التفويض HTTP 400 مع use_attestation_challenge، ويعيد المورد المحمي HTTP 401 داخل استجابة المصادقة. ويجب أن يرفق كلاهما تحدياً جديداً في OAuth-Client-Attestation-Challenge. ينشئ العميل دليلاً جديداً وينبغي أن يحاول مرة واحدة، ويحظر عليه الاستمرار بلا نهاية.

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

يوضح قسم الأمن لماذا لا تكفي عبارة «التحدي مفعل». يستطيع الخادم حفظ قيم jti التي شاهدها في نافذة زمنية منزلقة، فيكشف إعادة إرسال PoP JWT نفسه. ويمكنه حفظ التحديات التي أصدرها endpoint أيضاً، فيحصل على كشف أقوى للإعادة بقيمة اختارها هو، مقابل ذاكرة وربما رحلة إضافية.

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

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

نمط DPoP المدمج يسلك قناة أخرى

في النمط المدمج يفي دليل DPoP في RFC 9449 بغرضين: إثبات حيازة مفتاح النسخة وتقييد رمز الوصول بالمرسل. وتوضح المراجعة 11 أن هذا النمط يستخدم حصراً آلية nonce الخاصة بـDPoP.

إذا غاب nonce المتوقع أو رُفض، يكون الخطأ use_dpop_nonce وتأتي القيمة الجديدة في DPoP-Nonce، لا في مسار use_attestation_challenge. يستطيع challenge endpoint تسليم DPoP nonce مسبقاً لتجنب رحلة فاشلة، لكن اشتراك القيمتين في منفذ لا يجعلهما شيئاً واحداً.

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

البيانات الوصفية تكشف القدرة لا عقد الحداثة

تضيف المراجعة بيانات عميل وفق النموذج العام في RFC 7591. يستطيع الطرفان نشر خوارزميات التوقيع وطرق دليل الحيازة المقبولة، مثل attestation_pop_jwt وdpop_combined. ويمكن لبيانات الخادم نشر عنوان challenge_endpoint. بذلك يستبعد العميل بعض حالات عدم التوافق قبل أن يوقع دليلاً.

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

ليس مطلوباً نشر عدد الثواني الدقيق أو بنية التخزين. قد تتغير التفاصيل مع الحمل والخطر. لكن تصنيفات مثل single-use وreusable وsession-bound تكشف السلوك الخارجي دون كشف السر. وكذلك يفصل witnessed-state عن freshness-only بين ضمانين لا ينبغي للمدقق أن يخلط بينهما.

يقترح Daniel Kade كائناً صغيراً باسم freshness-policy ضمن profile للنشر. يعلن لكل نمط ما إذا كانت حداثة الخادم مدعومة أو مطلوبة، وقنوات الإصدار، وفئة العمر، وطريقة الاستهلاك، وموقف منع الإعادة، وعدد المحاولات الآلية، ونسخة السياسة. ويمكن لوصل اكتشاف موقع أن يربط الإعلان بالبيانات التي قرأها العميل فعلاً.

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

المصادر