التفويض في MCP: وفق المواصفة السارية، أجب أولًا «من أنت؟»

مقدمة

بروتوكول MCP (Model Context Protocol) هو التوصيلة المعيارية بين تطبيقات الذكاء الاصطناعي والأدوات الخارجية: ينشئ مضيف MCP (مثل Claude Code أو Claude Desktop أو VS Code) عميلًا لكل خادم MCP، وتكشف الخوادم عن ثلاثة بدائيات — tools وresources وprompts. يفحص هذا المقال نموذج التفويض فيه وفق مواصفة التفويض الرسمية السارية لـ MCP (إصدار 2026-07-28؛ تم التحقق في 6 أكتوبر 2026 من أن /specification/latest يعيد التوجيه إليها). (تحليل المنتجات حتى 6 أكتوبر 2026.)[1]

[1] [2]

التفويض ما زال اختياريًا

المواصفة السارية: Authorization is OPTIONAL. فالتطبيقات التي تستخدم HTTP يُستحسن أن تتبع هذه المواصفة (SHOULD)؛ أما الخوادم المحلية التي تستخدم STDIO فيُستحسن ألا تتبع تدفق OAuth هذا (SHOULD NOT)، بل تستمد بيانات الاعتماد من البيئة. لاحظ أن هذا SHOULD NOT وليس استحالة تقنية — فأمان المحلي يعتمد على عزل العمليات وحفظ بيانات الاعتماد، وتترك المواصفة ذلك للمنفذين.[2]

[2]

ثلاثة أدوار

تضع المواصفة السارية قسم «Roles» بثلاثة أطراف: خادم MCP المحمي هو خادم الموارد في OAuth 2.1؛ وعميل MCP هو عميل OAuth 2.1 الذي يقدم طلبات الموارد المحمية نيابة عن مالك المورد؛ وخادم التفويض يتفاعل مع المستخدم عند الضرورة ويصدر رموز الوصول، وقد يُستضاف مع خادم الموارد أو ككيان مستقل — وتفاصيل تنفيذه خارج نطاق هذه المواصفة. «من يصدر الرموز» و«من يستلمها» منفصلان رسميًا.[2]

[2]

ربط المورد والجمهور

تشترط المواصفة السارية على العملاء تنفيذ Resource Indicators وفق RFC 8707: فيجب أن يظهر معامل resource (MUST) في طلبات التفويض وطلبات الرموز معًا، محددًا URI المعياري لخادم MCP المقصود؛ وعلى الخادم بصفته خادم موارد أن يتحقق (MUST) من أن رموز الوصول صدرت له تحديدًا بوصفه الجمهور المقصود، فلا يقبل إلا الرموز الصادرة عن خادم التفويض الخاص به لموارده الخاصة، ويحظر عليه (MUST NOT) قبول أي رموز أخرى أو تمريرها. الرموز مربوطة بالموارد: رمز واحد، مكان واحد.[2]

[2]

إيقاف DCR

في المواصفة السارية، التسجيل الديناميكي للعملاء (DCR) موقوف ومحفوظ للتوافق الخلفي فقط؛ ويُستحسن (SHOULD) لخوادم التفويض وعملاء MCP دعم OAuth Client ID Metadata Documents. وقبل بدء تدفق التفويض، على العملاء الحصول (MUST) على معرف عميل بإحدى الآليات الثلاث — Client ID Metadata Documents أو التسجيل المسبق أو DCR — حسب ترتيب الأولوية الذي تحدده المواصفة.[2]

[2]

تحديات النطاق والتصعيد

تفصّل المواصفة السارية معالجة نقص الأذونات: فيجوز (MAY) للخوادم تضمين معامل scope في ترويسة WWW-Authenticate لاستجابة 401 إرشادًا للأذونات المطلوبة؛ وعند رفض رمز لنقص نطاقه، يُستحسن (SHOULD) أن يرد الخادم 403 مع insufficient_scope — لاحظ أن هذه حالة نقص النطاق؛ فالرموز غير الصالحة أو المنتهية ما زالت تتلقى 401. فيعيد العميل التفويض بمجموعة نطاقات أوسع عبر تدفق التصعيد ثم يعيد المحاولة.[2]

يجب التمييز بين «بشريين» مختلفين: فإعادة التفويض عبر التصعيد تسلك تدفق تفويض OAuth، الذي يُستحسن (SHOULD) للعملاء المتصرفين نيابة عن مستخدم أن يحاولوه وفق المواصفة — وقد يتطلب هذا التدفق نفسه تفاعل المستخدم؛ فبروتوكول التفويض يسمح بالتفويض التفاعلي ويشترطه في بعض الحالات. لكن هذا ليس كـ«الموافقة البشرية الإلزامية على كل استدعاء أداة». فالأول آلية داخل بروتوكول التفويض، والثاني سياسة استدعاءات المضيف. وهما ليسا الشيء نفسه.[2]

[2]

مصافحة 401

عند اشتراط التفويض وعدم إثبات العميل له بعد، يرد الخادم بـ HTTP 401 ثم يبدأ العميل تدفق OAuth 2.1؛ وتسافر الرموز في ترويسة Authorization ولا توضع أبدًا في سلسلة استعلام URI (شرط القسم 5 من OAuth 2.1 الذي تستشهد به المواصفة السارية). يطابق العملاء أي iss مُعاد مطابقةً تامةً مع issuer المسجل مسبقًا؛ ولا يجب رفض الاستجابة عند غياب iss إلا عندما يعلن خادم التفويض دعمه لهذا المعامل (RFC 9207).[2]

[2]

إجابة المؤسسات

يحوّل ملحق المؤسسات (بإصدار مستقل) موفر الهوية IdP الخاص بالمنظمة إلى صانع القرار المرجعي: يسجل الموظفون الدخول مرة واحدة، ويقرر IdP وفق سياسة المنظمة الخوادم التي يمكنهم الوصول إليها؛ ووفق وثائق الملحق، في عمليات النشر التي تنفذ الملحق وتدعمه، يتم الإلغاء مرة واحدة على مستوى IdP فيسري فورًا على جميع العملاء. ولم يُختبر أي تنفيذ عمليًا؛ ولا يُضمن أن كل عمليات نشر MCP تتصرف هكذا. والتفويض الفردي معقول للمستهلكين؛ أما في المؤسسات فيخلق احتكاكًا وثغرات.[3]

[3]

تعليق

1. يوحّد البروتوكول المصافحة فقط، لا السياسة. إذ يضع قسم «Roles» تنفيذ خادم التفويض صراحة خارج النطاق — فـ MCP لا يقرر حتى «من يصدر الرموز». وهذا تصميم صادق: فعند تقييم النشر، انظر إلى جهة خادم التفويض — لا إلى السلك نفسه.

2. يُظهر إيقاف DCR بروتوكولًا يتقارب. فالتحول من «تسجيل كل شيء ديناميكيًا» إلى «إعلان بيانات الهوية أولًا» ينقل الثقة من التفاوض أثناء التشغيل إلى الإعلان عند التسجيل. وتتنازل الراحة لصالح قابلية التدقيق: المسار المعتاد لبروتوكول ينضج.

3. «باسم من» ما زال الأصل. إذ تحافظ المواصفة السارية على التمييز في قسم التصعيد: «العملاء المتصرفون نيابة عن مستخدم» مقابل «عملاء client_credentials» يسلكون تدفقات مختلفة [2]. فالتصرف منتحلًا المستخدم مقابل التصرف كالتطبيق نفسه يستلزمان منطقًا مختلفًا تمامًا للتدقيق والإلغاء: اسأل هذا أولًا عند الاختيار، ثم اسأل عن النطاقات.

4. بروتوكول التفويض ليس الموافقة على كل إجراء. فتحديات النطاق والتصعيد آليتا أذونات داخل البروتوكول، وقد ينطوي التصعيد على تفاعل المستخدم؛ لكن «الموافقة البشرية الإلزامية على كل استدعاء» أمر آخر يخص سياسة المضيف. وعند تصميم خط نشر وكيلي، يجب فصل طبقة البروتوكول («هل يجوز استخدام هذا الرمز») عن طبقة السياسات («هل هذه المكالمة معتمدة») — كما يجب ألا تكون الصياغة والمراجعة والتوقيع الأيدي نفسها أبدًا.

5. أربعة أسئلة للممارسين (المواصفة السارية). من هو خادم التفويض (مع خادم الموارد أم مستقل)؟ وهل ربط المورد/الجمهور مطبق فعلًا؟ وما استراتيجية تحديات النطاق لدى الخادم (كيف يُستخدم 403)؟ وأي آلية من الثلاث لتسجيل العملاء مستخدمة؟ وإن لم تستطع الإجابة، فلا تربط بيانات الإنتاج بعد.

[2]

ما لا يمكن الجزم به بعد

مدى اكتمال تطبيق المضيفين والعملاء للمواصفة السارية (لم يُختبر عمليًا)؛

التقدم الفعلي لإيقاف DCR؛

الوضع الأمني الفعلي لخوادم MCP محددة (وفق وثائقها وتدقيقها الخاص).