الخلاصة

  • يرتب RFC 10017 ثلاثة أنماط بحسب خصائصها الأمنية: BFF كامل، وخلفية تتوسط الرموز، وعميل OAuth يعمل كله في المتصفح.
  • يحتفظ BFF الكامل برموز الوصول والتجديد واعتماد العميل السري بعيداً عن JavaScript، لكنه لا يمنع كوداً خبيثاً يعمل في المصدر الصحيح من إرسال أوامر عبر Cookie الجلسة المشروعة.
  • يلزم فصل مسؤوليات مصدر التطبيق وسلسلة السكربتات وCookie وCSRF ومسارات BFF وطرقه ووجهاته، ثم تفويض المورد وتأكيد الأفعال غير القابلة للعكس وإبطال الجلسة وإثبات النتيجة النهائية.

تفتح موظفة لوحة إدارة البنية التحتية لإيقاف مفتاح قديم. لا يوجد Access Token في ذاكرة الصفحة أو التخزين المحلي. يحمل المتصفح Cookie من نوع HttpOnly، بينما يحتفظ BFF بالرموز ويستدعي خدمة المفاتيح نيابة عن المستخدم.

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

هذه ليست حجة ضد BFF. إنها الحدود التي يجعلها RFC 10017 صريحة. نُشر المستند في أغسطس 2026 بوصفه أفضل ممارسة حالية لـ IETF. إبقاء الرموز في مكوّن خادمي سري يغلق مسارات هجوم مهمة، لكنه لا يجعل الكود داخل المصدر المعتمد ممثلاً دائماً لإرادة المستخدم.

المهاجم داخل المصدر لا يحتاج إلى السرقة دائماً

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

يفصل RFC أربع قدرات. الأولى سرقة الرموز الحالية مرة واحدة. الثانية مراقبة التطبيق وسرقة كل قيمة جديدة. الثالثة تجاهل التخزين وبدء Authorization Code Flow جديد مستفيداً من جلسة المستخدم لدى Authorization Server. الرابعة إرسال الطلب مباشرة من متصفح المستخدم، بحيث يضيف Cookie أو مكوّن التوقيع أو آلية إرفاق الرمز بيانات الاعتماد من دون إخراجها.

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

يبقى PKCE إلزامياً ومفيداً؛ فهو يمنع تبادل Authorization Code معترض من جهة أخرى. لكنه لا يميز نية سطرين من الكود يعملان داخل Redirect Origin المسجل نفسه. كذلك يحد DPoP والمفتاح غير القابل للتصدير من استعمال نسخة مسروقة خارج البيئة، لكن الكود الخبيث قد يبدأ Flow جديداً بمفتاحه أو يستخدم قدرة توقيع حية.

يغلق BFF ثلاثة أبواب ويتولى الباب الرابع

في نمط BFF الكامل يصبح المكوّن الخادمي هو عميل OAuth السري. يستخدم Authorization Code مع PKCE، ويحفظ Access Token وRefresh Token، ويربطهما بجلسة Cookie، ويمرر كل اتصال إلى Resource Server. لا يستلم كود الواجهة رمز OAuth.

تظهر ثلاثة مكاسب محددة. لا يوجد رمز في المتصفح يمكن نسخه مرة أو بصورة مستمرة. وحتى إذا حصل الكود الخبيث على Authorization Code، لا يملك اعتماد BFF السري لتبادله بصفته العميل المسجل. كما يمنع HttpOnly قراءة معرف الجلسة مباشرة وتحويل اختراق مؤقت للواجهة إلى جلسة محمولة.

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

لذلك لا يجوز أن يكون BFF Proxy عاماً. يطلب RFC 10017 رقابة صارمة على الوجهات الخارجة: Hosts وPaths معتمدة، وHTTP Methods محددة لكل Endpoint. إذا سمح Parameter قادم من المتصفح باختيار URL الذي يستقبل الرمز، يتحول التخزين الجيد إلى Relay ذي صلاحية واسعة.

ولـ Cookie عقد مستقل. يشترط المستند Secure وHttpOnly، ويوصي بـ SameSite=Strict وPath يساوي / وعدم تعيين Domain واستخدام Prefix مناسب مرتبط بالمضيف. ومع ذلك تبقى حماية CSRF مطلوبة لمسارات تغيير الحالة، لأن المتصفح يستطيع إرفاق Cookie من دون أن يكشف قيمته لـ JavaScript.

يجمع BFF كذلك اعتماد العميل والرموز والجلسات والتوجيه. هذا يجعله موضعاً جيداً لاكتشاف الشذوذ وRate Limiting، ويجعله أيضاً اعتماداً مركزياً للسعة والتناسق بين المناطق والإبطال والتعافي.

وسيط الرموز يحمي الاستمرار ويعيد السلطة الفورية

في النمط الوسيط تبقى الخلفية عميلاً سرياً وتحفظ Refresh Token، لكنها تعطي Access Token للمتصفح كي يتصل مباشرة بخدمات الموارد. تقل كلفة Proxy، لكن الرمز القصير يعود إلى بيئة التنفيذ.

لا يستطيع الكود الخبيث سرقة Refresh Token أو إكمال Flow جديد منفرداً بصفته العميل السري. يستطيع سرقة Access Token. وإذا عُزل الرمز في الذاكرة، فقد يطلب من الوسيط رمزاً حديثاً باستعمال الجلسة الحالية. لا يحتاج الأثر غير القابل للعكس إلى سلطة طويلة الأمد.

ينقسم دور DPoP أيضاً: الخلفية تحصل على الرمز، والمتصفح يستعمله. لا يحدد RFC 10017 هذا التقسيم. لا تكفي علامة «PoP» في مخطط؛ يجب إثبات من يحفظ المفتاح ومن ينتج Proof ومن يتحقق منه. لذلك يوصي المستند بدراسة BFF الكامل أولاً، ثم اختيار الوسيط فقط عندما تمنع متطلبات واضحة تمرير كل الاتصالات.

عميل المتصفح يظل عميلاً عاماً

عندما يتولى كود المتصفح مسؤوليات OAuth كلها، لا يتحول Secret مضمن في الحزمة إلى اعتماد سري. يجب استعمال Authorization Code مع PKCE وRedirect URI مطابق تماماً وحماية CSRF. وإذا أُصدرت Refresh Tokens، فعلى Authorization Server تدويرها عند كل استخدام أو تقييدها بالمرسل، وفرض عمر أقصى أو انتهاء بعد الخمول.

هذه قواعد ضرورية، لكنها لا تلغي الهجمات الأربع بعد اختراق المصدر. يتكون Origin من Scheme وHost وPort، وهو حد السلطة العملي في المتصفح. يوصي RFC بتطبيق واحد لكل Origin حتى تتطابق CORS وCSP والعزل مع مالك واضح.

CORS يقرر هل يكشف المتصفح Response عبر المصادر للكود. ليس تفويضاً في الخادم ولا يفرق بين كود مشروع وخبيث داخل Origin مسموح. وفي postMessage يجب فحص Origin المرسل والمستقبل بدقة؛ وصول الرسالة عبر API المتصفح لا يصنع أصالتها.

لا يصبح Service Worker سلطة فوق المصدر

يستطيع Service Worker عزل الرموز وإضافتها إلى الطلبات، فيبدو كأنه BFF داخل المتصفح. لا يوصي RFC 10017 بأن يدير OAuth Flow، لأن الكود الخبيث يستطيع إلغاء تسجيله وفتح Browsing Context جديد لا يمر عبره، ثم بدء Flow آخر.

العزل حقيقي، لكن سلطته ليست غير قابلة للإزالة. ينطبق الحد نفسه على مفتاح Web Crypto غير قابل للتصدير: تمنع API قراءة مادته، لكنها لا تضمن TPM أو تشفير الملف الأساسي، ولا تمنع بالضرورة الكود الخطأ من طلب استعمال المفتاح داخل البيئة الصحيحة.

يجب أن تصل الأدلة إلى نتيجة العمل

يربط سجل مفيد بين Origin وإصدار الواجهة وتبعياتها وCSP، وHash آمن للجلسة، ونتيجة CSRF، ومسار BFF، وHost وPath وMethod الخارجة، وAudience وScopes، وإصدار سياسة المورد، وحالة الكائن، وIdempotency Key، ونتيجة Commit. لا ينبغي تسجيل Token أو Cookie أو Client Secret خام.

كما يجب فصل الاختبارات السلبية: قراءة رمز موجود، متابعة Rotation، بدء Flow جديد، طلب رمز من الوسيط، استعمال BFF من دون رؤية الرمز، تغيير الوجهة، وإعادة فعل غير قابل للعكس بعد ضياع Response. مؤشر واحد باسم «OAuth صالح» يمحو الفروق اللازمة للمساءلة.

تضع Running-Code Primacy الاختبار الصحيح: كلمة BFF ليست دليلاً، بل القواعد المنفذة في Cookie والمسارات ومخزن الرموز وسياسة المورد والفشل. تحفظ Minimum Initial Specification آليات OAuth المشتركة دقيقة، وتترك قرار الأثر للخدمة التي تتحمل نتيجته. الرمز المحمي حقيقة تقنية، وليس تفويضاً رمزياً لكل أمر.