الخلاصة

  • في 24 أغسطس 2026 أقر IESG المراجعة العاشرة من draft-ietf-oauth-rfc8725bis بصفتها Best Current Practice. عند تثبيت حزمة الأدلة بقي النص Internet-Draft في طابور RFC Editor؛ وعند نشره سيجعل RFC 8725 متقادماً ويحدّث RFC 7519.
  • القاعدة التشغيلية الحاسمة هي أن تكون شروط التحقق الخاصة بأنواع JWT المختلفة متبادلة الاستبعاد. نجاح التوقيع لا يكفي؛ فلا بد من تطابق النوع والمُصدر والجمهور والمطالبات والرؤوس المحمية والخوارزمية والمفتاح وسياق التطبيق.

إنذار أمني أمام بوابة الدفع

لنتصور منصة تستقبل Security Event Tokens للإبلاغ عن تغيرات الحساب، ولها واجهة مدفوعات تقبل رموز وصول. يثق النظامان بالمُصدر نفسه ويستخدمان مجموعة المفاتيح نفسها. يصل رمز حدث أصلي إلى واجهة المدفوعات، فتتحقق مكتبة JWT العامة من توقيعه وتعلن النجاح.

لم يفشل التشفير. الذي فشل هو حد السلطة.

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

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

قرار معياري لم يكتمل نشره بعد

يسجل إعلان IESG أن المراجعة العاشرة من «JSON Web Token Best Current Practices»، وهي من عمل مجموعة OAuth، أُقرت في 24 أغسطس عند 18:02 بالتوقيت العالمي بهدف نشرها كـ BCP.

في 28 أغسطس ظل Datatracker يعرضها كـ Internet-Draft نشط مؤرخ في 21 أغسطس، ومحدّث في 25 أغسطس، وتنتهي صلاحيته في 22 فبراير 2027. كانت حالة IESG هي RFC Ed Queue. أما RFC Editor فكان ينتظر مرجعاً لم يصله. وقالت IANA إن إجراءات تسجيل جديدة غير مطلوبة، مع بقاء حالة المعالجة جارية.

إذن توجد موافقة معيارية فعلية، ولكن لا يوجد بعد رقم RFC نهائي ولا تحرير مكتمل ولا دليل على اعتماد البرمجيات المنشورة. وعند نشر النص وفق بياناته سيحل محل RFC 8725 ويحدّث مواصفة JWT الأساسية، RFC 7519.

أربع أسئلة داخل عبارة «JWT صالح»

JWT صيغة للمطالبات وليس حالة أمنية واحدة. قد يأتي في JWS موقّع، أو JWE مشفّر، أو بنية متداخلة، أو في صورة unsecured JWT عندما يسمح التطبيق بذلك صراحة. كما أن compact serialization المعتمد على base64url والنقاط ليس مرادفاً لكل صيغ JOSE المبنية على JSON.

على المستقبِل أن يجيب بالترتيب:

  1. هل يطابق الكائن بالضبط صيغة التسلسل التي تقبلها نقطة الدخول؟
  2. هل نجح التوقيع أو التشفير الموثّق بخوارزمية مسموحة ومفتاح صحيح؟
  3. هل ينتمي الكائن إلى نوع الرمز الذي صُمم هذا المستهلك لمعالجته؟
  4. هل تفوّض مطالباته هذه العملية الآن ولهذا المُصدر والجمهور والموضوع؟

فك تشفير JWE لا يثبت تلقائياً توقيع JWT داخلي. والقدرة على تحليل الصيغة المختصرة لا تنشئ ثقة. وصحة JWS لا تجعل مطالباته صالحة لدى كل خدمة تستخدم المفتاح نفسه.

وظيفة typ هي إغلاق الفئة

توصي المراجعة بالتصريح بالنوع عندما يمكن الخلط بين الرموز. النوع الذي يحدده RFC 8417 لـ Security Event Token يمنح المستقبِل وسيلة تمييز قبل تفسير المطالبات. أما القيمة العامة JWT فلا تحدد عقد التطبيق؛ إنها تكرر فقط اسم الحاوية.

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

يعطي RFC 9068 رموز وصول OAuth ملف JWT خاصاً، ويعطي RFC 8417 أحداث الأمن ملفها الخاص. يمكن أن يكون الاثنان أصليين وموقّعين على نحو صحيح، من دون أن يقبل أحدهما مكان الآخر. يختار المستهلك الملف أولاً، ثم يمنح المطالبات معناها التنفيذي.

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

الانتماء إلى مؤسسة واحدة لا يصنع جمهوراً واحداً

يحدد iss من أصدر الادعاء، ويحدد aud من وُجه إليه. يجب فحص الاثنين بحسب نوع الرمز قبل أن تؤثر المطالبات في المسارات أو الحقوق أو البيانات.

الخدمتان A وB ليستا الجمهور نفسه لمجرد أنهما تابعتان للشركة نفسها أو تستخدمان مزود الهوية نفسه. الإدارة المشتركة لا تحوّل رمزاً موجهاً إلى A إلى اعتماد لدى B.

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

الرمز لا يختار سياسة التحقق الخاصة به

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

وتشكل رؤوس اختيار المفاتيح مثل kid وjku وx5u سطح إدخال آخر. قد تقود إلى استعلام أو جلب بعيد؛ وإذا مرت من دون قيود فقد تفتح حقناً أو طلبات خادم إلى وجهات يختارها الخصم. تبقى بيانات خصم قبل التحقق، وبعده لا تمنح المُصدر وصولاً شبكياً غير محدود.

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

ما الذي ينبغي أن يبقى من قرار التفويض

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

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

المصادر