الخلاصة

  • قدم Justin Richer في 28 سبتمبر مسودة Internet-Draft فردية تنقل رمز تفويض OAuth من صفحة في المتصفح إلى عميل بعيد عبر قيمة واحدة قابلة للنسخ.
  • الصياغة المختصرة لا تمنح ضمانًا أمنيًا جديدًا: تتلقى صفحة المساعدة code وstate، ويبقى على العميل ربط ما أُلصق بطلبه وبخادم التفويض المقصود.

قد يبدأ عميل يعمل في طرفية بعيدة طلب التفويض، بينما لا يستطيع تشغيل عنوان إعادة توجيه يبلغه متصفح المستخدم. هنا تقع المشكلة التي تعالجها draft-richer-oauth-oob-authcode-00: عنوان مسجل لصفحة مساعدة يستقبل نتيجة المتصفح، ثم ينقل المستخدم قيمة معروضة إلى الطرفية. قُدمت الوثيقة في 28 سبتمبر 2026 بوصفها مسودة فردية ذات غرض معلوماتي. ويعرض Datatracker الحالة I-D Exists؛ فلا يعني ذلك اعتماد مجموعة عمل لها، ولا موافقة IETF، ولا صدور RFC.

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

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

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

هناك كذلك حقل لا يجوز إخفاؤه في المراجعة: iss. تحمل القيمة المقترحة code وstate دون سائر معاملات الرد بصورتها المستقلة. وتذكر الفقرة 3.4 احتمال إدخال iss في خانة INFO الخاصة بـHKDF إذا عرف العميل أن الخادم يرسله. يحدد RFC 9207 أصلًا إشارة للجهة المصدرة للحد من الخلط بين خوادم تفويض متعددة. لا يعني غياب الحقل من القيمة المركبة أن كل تنفيذ عرضة لهجوم، لكنه يوجب على العميل متعدد الخوادم بيان كيف سيحافظ على الربط القائم مع الجهة المصدرة.

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

المصادر