داخل منظومة التشغيل: ربط مُصدِر OAuth في MCP، ولماذا يعيش أمن البروتوكول في مقارنة السلاسل النصية

ثلاثة أرقام، ثم أشرحها. واحد: حقل المُصدِر في وثيقة بيانات OAuth الوصفية عبارة عن سلسلة نصية واحدة. اثنان: خلال هذا الصيف، قدّم كل من Atlassian وContext7 وHome Assistant بيانات تفويض وصفية لـMCP لم تتطابق فيها تلك السلسلة مع عنوان URL الذي جُلبت منه، فرفض العملاء الصارمون الاتصال. ثلاثة: الإصلاح الذي يصل الآن في مواصفة MCP هو، في جوهره، «قارن السلسلة، وارفض إذا اختلفت». هذه هي الآلية كلها، والهجوم الذي تغلقه من أكثر هجمات OAuth خبثاً: هجوم الخلط، الذي يزيده نمط نشر MCP سوءاً من الناحية البنيوية.

هذه مقالة من سلسلة «داخل منظومة التشغيل»، لذلك سندخل إلى السباكة: ما مشكلة ربط المُصدِر، وأي التدفقات تتأثر بها، وما الذي تفرضه حزمة مواصفة 2026-07-28 على كل من يبني عميل MCP أو خادماً له. تغييرات النقل بلا حالة في الإصدار نفسه حصدت العناوين؛ أما تقوية التفويض فحصلت على ستة مقترحات SEP وتقريباً بلا تغطية. هذا ترتيب معكوس، لأنك إذا كنت تشغّل خوادم MCP تحمل بيانات اعتماد حقيقية، فهذا هو الجزء الذي يقرر ما إذا كان عميل مرتبك سيسلّم رمز وصول إلى الطرف الخطأ.

أهم النقاط - تقلب MCP الشكل التقليدي لـOAuth: عميل واحد يتحدث إلى خوادم تفويض كثيرة تُكتشف وقت التشغيل. وهذا الانقلاب هو بالضبط البنية التي صُممت هجمات الخلط لاستهدافها. - حزمة مواصفة 2026-07-28 تضم ستة SEPs. الأهم اثنان: SEP-2468، للتحقق من معامل iss في استجابات التفويض وفق RFC 9207، وSEP-2352، لربط كل بيانات اعتماد عميل مسجلة بالمُصدِر الذي أنشأها. - المسألة ليست نظرية. نقاط MCP لدى Atlassian وContext7 قدمت هذا الصيف بيانات وصفية بمُصدِر غير مطابق فعلاً، فكَسرت العملاء الصارمين. المواصفة تلحق بأعطال موجودة بالفعل في الإنتاج. - التحقق من iss موصى به الآن ويتجه نحو الإلزام. ابنِه اليوم، وتعامل مع غياب iss من خادم يفترض أن يدعمه كسبب للرفض، لا كشيء يمكن تجاهله. - حتى مع اعتماد الحزمة بالكامل، فهي لا تقوي سوى المصادقة بين العميل والخادم. هوية الوكيل، والتفويض لكل طلب، وإثبات سلسلة التفويض، والتدقيق ما زالت خارج البروتوكول وتقع عليك.

ماذا حدث

في 21 مايو 2026، ثبّت مشرفو MCP مرشح الإصدار لمواصفة 2026-07-28، ووصلت المواصفة النهائية في 28 يوليو، ومنذ ذلك الحين يعمل مشرفو SDK داخل نافذة تحقق مدتها عشرة أسابيع. ركزت معظم التعليقات على التحول إلى بنية بلا حالة. وتحت ذلك، وفق قراءة Tigera الدقيقة للإصدار، توجد حزمة من ستة مقترحات لتحسين المواصفة لتقوية طبقة OAuth:

مقترحات الترتيب الثلاثة، 2207 و2350 و2351، هي توضيحات، والتوضيحات في مواصفات التفويض مهمة: اختلاف SDKين على مكان وثيقة بيانات وصفية هو انقطاع توافق بيني، لا هامشاً صغيراً. لكن الزوج الحامل للعبء هو 2468 و2352، وكلاهما يدور حول السؤال نفسه: كيف يعرف العميل أي خادم يتحدث إليه فعلاً؟

تضم حزمة مواصفة MCP 2026-07-28 ستة SEPs لتقوية OAuth: التحقق من المُصدِر (2468)، وبيانات اعتماد مرتبطة بالمُصدِر (2352)، والتصريح بنوع العميل في التسجيل الديناميكي للعملاء (837)، إضافة إلى توثيق رموز التحديث (2207)، وتراكم النطاقات (2350)، وسلوك الاكتشاف (2351)، وفق تحليل Tigera. ثُبّت مرشح الإصدار في 21 مايو، ووصلت المواصفة النهائية في 28 يوليو 2026.

نموذج الثغرة: عميل واحد، مُصدِرون كثيرون

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

MCP تشغّل المشهد بالعكس تماماً. عميل واحد، أي التطبيق المضيف، يتحدث إلى خوادم MCP كثيرة، وقد يقف أمام كل منها خادم تفويض مختلف، تُكتشف وقت التشغيل، وغالباً يُسجل العميل لديها في اللحظة نفسها عبر التسجيل الديناميكي للعملاء. يقول مؤلفو المواصفة ذلك مباشرة: يستهدف SEP الخاص بالتحقق من المُصدِر «فئة من هجمات الخلط أكثر شيوعاً في نمط نشر MCP ذي العميل الواحد والخوادم الكثيرة»، كما تنقل مقالة Tigera. عندما يحمل عميلك تسجيلات لدى اثني عشر خادم تفويض في الوقت نفسه، لا يحتاج المهاجم إلى كسر أي تشفير. يكفيه أن يجعل العميل ينسب استجابة إلى الخادم الخطأ.

وهذا هو شكل الهجوم. يكون مضيف وكيلك في منتصف تدفق مع الخادم الصادق A عندما تصل استجابة جاءت في الحقيقة من الخادم B الذي يتحكم به مهاجم. من دون فحص المُصدِر، قد يكمل العميل التبادل مع B فيسرّب رمز التفويض، أو يقبل رموزاً أصدرها B ثم يقدمها لاحقاً. أضاف RFC 9207، وهو إصلاح OAuth التقليدي الصادر في 2021، معامل iss صريحاً إلى استجابات التفويض كي يرفض العميل أي شيء صادر عن مُصدِر غير متوقع، ويسحب SEP-2468 هذا الشرط إلى MCP. يتعامل SEP-2352 مع النصف الأهدأ: بيانات الاعتماد. قبله، كان يمكن للعميل الاحتفاظ بـمعرّف عميل أصدره المُصدِر A، ثم عندما ينتقل مورد إلى المُصدِر B يقدم بيانات اعتماد A إلى B. أحياناً كان ذلك يعمل، و«أحياناً يعمل» ليست خاصية تريدها في نظام تفويض. لذلك يفرض 2352 الاحتفاظ بالتسجيلات لكل خادم تفويض على حدة، وربطها بقيمة المُصدِر، وإعادة التسجيل عند الهجرة.

وهذه ليست المحاولة الأولى لمعالجة هذه الفئة. مراجعة المواصفة بتاريخ 2025-06-18 جعلت مؤشرات الموارد وفق RFC 8707 إلزامية كي تصدر الرموز لخادم محدد واحد، كما أن مواصفة تفويض MCP تمنع بالفعل قبول رموز موجهة إلى موارد أخرى أو تمريرها إلى وجهات لاحقة. تواصل حزمة 2026-07-28 الاتجاه نفسه: ثقة أقل افتراضياً وربط أكثر صراحة. إذا قرأت مقالتي عن MCP مقابل API، فهذه هي تكلفة المرونة التي وصفتها هناك: الاكتشاف وقت التشغيل يجعل MCP قابلة للتركيب، لكنه يصنع أيضاً أسئلة الهوية هذه.

بنية MCP ذات العميل الواحد والخوادم الكثيرة هي بالضبط نمط النشر الذي تستهدفه هجمات الخلط: لا يكسر المهاجم التشفير، بل يجعل العميل ينسب استجابة أو بيانات اعتماد إلى خادم التفويض الخطأ. يربط SEP-2468 الاستجابات بالمُصدِرين عبر معامل iss في RFC 9207، ويربط SEP-2352 بيانات الاعتماد المسجلة بالخادم الذي أصدرها، وفق تحليل Tigera وRFC 9207.

المواصفة تلحق بأعطال الإنتاج

إذا بدا هذا كله تجريدياً، فهو ليس كذلك. سلسلة المُصدِر تفشل في عمليات نشر MCP حقيقية طوال الصيف، والعملاء الصارمون يصطدمون بها بالفعل.

في يوليو، وجد مستخدمو عميل opencode أن OAuth مع خادم Rovo MCP من Atlassian يفشل أثناء الاكتشاف. أعلنت بيانات المورد المحمي الوصفية بشكل صحيح عن خادم تفويض خاص بالمستأجر، لكن وثيقة البيانات الوصفية المقدمة هناك أعلنت المُصدِر المشترك المجرد https://auth.atlassian.com بدلاً من مسار المستأجر الذي جُلبت منه. ينص القسم 3.3 من RFC 8414 على أن قيمة issuer يجب أن تساوي بالضبط عنوان URL المستخدم لجلب البيانات الوصفية، بعد حذف لاحقة .well-known، لذلك رفض التحقق الصارم في opencode الاستجابة بحق وتعطل تسجيل الدخول بالكامل: خلل امتثال للمواصفة من جهة Atlassian، وتأكد على نقاط نهاية حية. وأصيبت نقطة MCP في Context7 بخلل شقيق في يونيو، حيث اختلف خادم التفويض المُعلن عن مُصدِر البيانات الوصفية على نطاق فرعي لـClerk، ورفض MCP Go SDK الرسمي التدفق. أما بيانات Home Assistant الوصفية فحذفت حقل المُصدِر بالكامل، وكسرت عملاء MCP بطريقة مختلفة.

لم تكن أي من الحالات الثلاث استغلالاً لهجوم خلط؛ كانت أعطال توافق بيني. وهذه هي النقطة. مقارنة السلسلة النصية نفسها التي تمنع خادماً مزيفاً للمهاجم تمنع أيضاً خادماً حقيقياً لكنه مهمل، لذلك سيصبح النظام البيئي أقل تسامحاً بكثير مع بيانات وصفية كانت خاطئة دائماً لكنها مرت سابقاً. تشرح مقالة WorkOS عن هجمات الخلط النقطة التشغيلية جيداً: ما زالت مكتبات OAuth كثيرة تترك فحص RFC 9207 معطلاً افتراضياً، وتشير إلى CVE-2026-59208 كحالة كان فيها قصر البحث عن الحسابات على المُصدِر المؤكد، بدلاً من مطابقة مطالبة sub عالمياً، سيوقف الخلل تماماً. سأتعامل مع الإشارة إلى CVE هذه باعتبارها معلومة أوردتها WorkOS ولم أتحقق منها مستقلاً، لكن المبدأ الدفاعي ممارسة معيارية في كل الأحوال.

فشلت عمليات نشر MCP حقيقية في التحقق من المُصدِر طوال الصيف: يقدم خادم Rovo MCP من Atlassian بيانات وصفية لا يطابق مُصدِرها عنوان المستأجر الذي جُلبت منه (المشكلة #39332 في opencode)، وأعلنت نقطة Context7 خادم تفويض بينما صرحت بياناتها الوصفية بآخر (المشكلة #2723 في Context7)، وحذف Home Assistant حقل المُصدِر بالكامل. يفرض القسم 3.3 من RFC 8414 أن تطابق قيمة المُصدِر عنوان الجلب تماماً، ولذلك رفض العملاء الصارمون الحالات الثلاث بحق.

ما الذي يجب على المنفذين فعله

إذا كنت تصون عميل MCP:

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

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

3. صرّح بـapplication_type في التسجيل الديناميكي للعملاء. يصلح SEP-837 فئة الأعطال التي يُفترض فيها أن عميل سطح مكتب أو CLI من نوع web ثم يُرفض بسبب عنوان إعادة توجيه localhost. حقل واحد، وفئة كاملة من الأخطاء تختفي.

4. اقصر البحث عن الحسابات على المُصدِر. يجب ألا تطابق مطالبة sub حسابات إلا داخل نطاق المُصدِر الذي تحققت منه فعلاً. لا تطابق عالمياً أبداً.

إذا كنت تدير خادم MCP أو خادم تفويض أمامه: قدم بيانات وصفية تساوي فيها قيمة issuer بالضبط عنوان URL الذي جُلبت منه، بما في ذلك مسار المستأجر، وطبّق بيانات المورد المحمي الوصفية وفق RFC 9728، واستمر في التحقق من أن الرموز أُصدرت لموردك تحديداً. وإذا كنت تستضيف الوكلاء بنفسك مقابل قائمة متزايدة من خوادم MCP، فحسابات الأسطول مهمة: N وكلاء في M خوادم يعني N مضروباً في M من التسجيلات المرتبطة بالمُصدِر. مع عشرة وكلاء يكفي جدول بيانات؛ مع مئة تحتاج سجلاً مركزياً، والمواصفة لا تقول شيئاً عن هذه السجلات. ذلك الجزء على منصتك.

يجب على المنفذين التحقق من iss في استجابات التفويض، ورفض عدم التطابق وكذلك الغياب عندما يكون الدعم متوقعاً، وتخزين بيانات الاعتماد مقسمة حسب المُصدِر وإعادة التسجيل عند الهجرة، والتصريح بـapplication_type أثناء التسجيل الديناميكي للعملاء، وقصر البحث عن الحسابات على المُصدِر المتحقق منه، وفق تحليل Tigera لمقترحات SEP وإرشادات WorkOS لهجمات الخلط. من المتوقع أن تضيف حزم SDK من المستوى 1 الدعم خلال نافذة التحقق ذات الأسابيع العشرة الخاصة بالمواصفة.

ما الذي لا تزال المواصفة لا تجيب عنه

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

لا أقول ذلك للتقليل من قيمة العمل. MCP بلا تحقق من المُصدِر كانت أشبه بـHTTP من دون فحص الشهادات، وهذه الفجوة تُغلق الآن. لكن الثغرات الأربع، هوية الوكيل، والتفويض لكل طلب، وإثبات سلسلة التفويض، والتدقيق، هي طبقة الحوكمة، ولن تصل لمجرد انتظار المواصفة. إنها الفجوات نفسها التي أعمل عليها مع العملاء في حوكمة الوكلاء، وتفرضها البيئة المحيطة بالوكيل أو لا يفرضها أحد.

الأسئلة الشائعة

ما مشكلة ربط مُصدِر OAuth في MCP؟

يتحدث عملاء MCP إلى خوادم تفويض كثيرة تُكتشف وقت التشغيل، ما يجعلهم عرضة لهجمات الخلط: استجابة أو بيانات اعتماد تُنسب إلى الخادم الخطأ. تصلح مواصفة 2026-07-28 ذلك بإلزام العملاء بالتحقق من معامل iss في استجابات التفويض، عبر SEP-2468 الذي يتبنى RFC 9207، وربط كل بيانات اعتماد مسجلة بمُصدِرها عبر SEP-2352.

هل هذه ثغرة في MCP نفسها؟

إنها فئة من الثغرات جعلها نمط نشر البروتوكول أكثر شيوعاً، وأُغلقت الآن على مستوى المواصفة. الأعطال التي ظهرت في الإنتاج هذا الصيف، أي تقديم Atlassian وContext7 وHome Assistant بيانات وصفية بمُصدِر غير مطابق، كانت أخطاء تنفيذ، لكنها توضح مدى هشاشة النموذج غير المتحقق منه. التحقق الصارم هو خط الأساس الآن.

أي التدفقات تتأثر؟

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

متى يصبح هذا إلزامياً؟

مواصفة 2026-07-28 نهائية، ودعم SDK يصل خلال نافذة تحقق مدتها عشرة أسابيع بدأت من تثبيت مرشح الإصدار في مايو، والمواصفة صريحة بأن رفض الاستجابات التي لا تحمل iss سيكون متوقعاً في إصدار مستقبلي. تعامل معه كإلزامي في أي شيء تبنيه الآن.

الخلاصة

أمن OAuth في معظمه مقارنة مملة بين سلاسل نصية لها عواقب، وMCP واجهت هذه الحقيقة للتو. حزمة 2026-07-28 تستورد إصلاح OAuth عمره خمس سنوات إلى بروتوكول جعل شكله، عميل واحد وخوادم كثيرة، ذلك الإصلاح عاجلاً، تماماً عندما بدأت عمليات نشر حقيقية تفشل في الفحص فعلياً. حدّث SDKs، وتحقق من iss، واربط تسجيلاتك بمُصدِريها. ثم اسأل السؤال الذي كان من الصحيح أن تتركه المواصفة بلا إجابة: عندما يُستخدم رمز أصدرته لاستدعاء أداة لم تكن لتوافق عليها، ويقدمه وكيل لا تستطيع حتى تسميته، من يلتقط ذلك، وأين السجل؟ هذه الإجابة لا تأتي من مواصفة. تأتي من منظومة التشغيل التي تبنيها حولها.

إذا كنت ترتب المصادقة والهوية في نشر MCP، فهذا نقاش أجريه بانتظام مع العملاء. تواصل معي.

المصادر

• Tigera، «تقوية مصادقة MCP: ما الذي تصلحه مقترحات OAuth SEP الستة الجديدة، وما الذي لا تزال لا تصلحه؟»: https://www.tigera.io/blog/mcps-auth-hardening-what-the-six-new-oauth-seps-fix-and-what-they-still-dont/ (نُشر 2026-07-28، واستُرجع 2026-08-29)

• WorkOS، «هجمات الخلط في OAuth وRFC 9207: فحص المُصدِر الذي لم يصل قط إلى تبادل الرموز»: https://workos.com/blog/oauth-mix-up-attacks-rfc-9207 (نُشر 2026-07-20، واستُرجع 2026-08-29)

• Model Context Protocol، مواصفة التفويض: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization (نُشرت 2025-11-25، واستُرجعت 2026-08-29)

• RFC Editor، RFC 9207، «تعريف مُصدِر خادم تفويض OAuth 2.0»: https://www.rfc-editor.org/rfc/rfc9207.html (نُشر 2021-12-16، واستُرجع 2026-08-29)

• مستودع opencode، المشكلة #39332، «MCP OAuth: فشل مصادقة Atlassian بسبب عدم تطابق المُصدِر وفق RFC 8414»: https://github.com/anomalyco/opencode/issues/39332 (نُشرت 2026-07-28، واستُرجعت 2026-08-29)

• مستودع Context7، المشكلة #2723، «عدم تطابق مُصدِر بيانات OAuth الوصفية لنقطة MCP OAuth»: https://github.com/upstash/context7/issues/2723 (نُشرت 2026-06-05، واستُرجعت 2026-08-29)

• Home Assistant Core، المشكلة #147059، غياب المُصدِر في بيانات OAuth الوصفية: https://github.com/home-assistant/core/issues/147059 (نُشرت 2025-06-17، واستُرجعت 2026-08-29)

• مستودع modelcontextprotocol/modelcontextprotocol: https://github.com/modelcontextprotocol/modelcontextprotocol (استُرجع 2026-08-29)