تأمين خوادم MCP: OAuth وربط الجمهور ومشكلة النائب المرتبك

متقدّم

What you'll learn

• افهم لماذا يُعد خادم MCP البعيد (HTTP) خادم موارد OAuth 2.1، وليس مجرد نقطة نهاية بمفتاح API
• تتبع مصافحة الاكتشاف: 401 ← Protected Resource Metadata ← Authorization Server Metadata ← الرمز
• اشرح ربط جمهور الرمز (RFC 8707) ولماذا يمنع رمز خدمة ما من العمل في خدمة أخرى
• سمِّ فخ النائب المرتبك والقاعدة الوحيدة التي تغلقه: لا تمرر أبدًا رمز العميل إلى واجهة برمجة تطبيقات أعلى في السلسلة
• طبّق قائمة تحقق قصيرة للتحصين قبل أن تعرّض خادم MCP للإنترنت

MCP تحوّل من طرافة إلى الطريقة الافتراضية التي تصل بها الوكلاء إلى الأدوات — وهذا يعني أن خوادم MCP باتت الآن تقف أمام بيانات حقيقية وإجراءات حقيقية. الخادم المحلي الذي تشغّله عبر STDIO يثق ببيئته: يقرأ بيانات الاعتماد من متغيرات البيئة ولا توجد حدود شبكية للدفاع عنها. في اللحظة التي تجعل فيها هذا الخادم نفسه بعيدًا (HTTP)، يمكن لأي شخص يستطيع الوصول إلى عنوان URL أن يحاول استدعاءه. هذا يحوّله إلى مشكلة تفويض، وتجيب مواصفة MCP على ذلك بـ OAuth 2.1 — لا بمخطط مفتاح API مخصص.

هذه الصفحة تتناول الحالة البعيدة. إذا كان خادمك يعمل عبر STDIO فقط، فإن المواصفة تقول صراحةً لا تتبع تدفق OAuth — اسحب بيانات الاعتماد من البيئة وتابع عملك.

آخر تحقّق: 2026-07-07. تستشهد هذه الصفحة بحقائق تتغيّر مع الوقت — اعتبر التاريخ أعلاه دليلًا على حداثتها. تأكّد من المصدر الرسمي.

الأدوار الثلاثة

يقسّم OAuth المشكلة إلى ثلاثة أطراف. وتنطبق MCP عليها بوضوح:

من هو من في تدفق OAuth الخاص بـ MCP

اضغط Enter أو مفتاح المسافة لقلب البطاقة. استخدم مفتاحي السهمين الأيسر والأيمن للتنقل بين البطاقات.تم إظهار المصطلح.

1 / 3

النقلة الذهنية الأساسية: خادم MCP لا يتولى تسجيل الدخول بنفسه أبدًا. إنه يتحقق فقط من الرموز التي أصدرها طرف آخر. هذا الفصل هو ما يتيح لك وضع مزوّد هوية جاهز أمام خادم كتبته بنفسك.

مصافحة الاكتشاف

لا ينبغي أن يحتاج العميل إلى تهيئة مسبقة بمكان المصادقة. تجعل MCP الاكتشاف تلقائيًا، مدفوعًا بـ 401:

Guided walkthrough1 of 6

1. الطلب الأول يخرج عاريًا. يرفضه الخادم بـ HTTP 401 Unauthorized وترويسة WWW-Authenticate تشير إلى عنوان URL لبيانات موارده الوصفية.

لاحظ أنه لا يوجد أي تهيئة مصادقة مبرمجة مسبقًا على جانب العميل — الـ 401 يمهّد كل شيء. هذا هو جوهر الأمر: يستطيع الوكيل الاتصال بخادم لم يره من قبل وأن يكتشف كيفية المصادقة.

ربط الجمهور: القاعدة الحاملة

إليك وضع الفشل الذي يوجد ربط الجمهور لمنعه. لنقل إن لدى مستخدم رمزًا صادرًا لـ calendar.example.com. يخدع خادم MCP خبيث (أو مجرد مهمِل) على evil.example.com العميلَ ليرسل ذلك الرمز إليه. إذا قبله evil، فيمكنه الآن أن يستدير ويستدعي واجهة برمجة تطبيقات التقويم باسم المستخدم. رمز خدمة واحدة عمل في خدمة أخرى. لتنهار حدود أمان OAuth للتو.

الحل هو مؤشرات الموارد (RFC 8707):

Guided walkthrough1 of 3

1. في كلٍ من طلب التفويض وطلب الرمز، يجب على العميل (MUST) تضمين معامل resource مضبوطًا على الـ URI القانوني لخادم MCP الذي ينوي استدعاءه — مثل resource=https://mcp.example.com. يرسله حتى لو لم يكن متأكدًا من دعم الـ AS له.

معامل resource في طلب التفويض (مُرمّز URL)

&resource=https%3A%2F%2Fmcp.example.com

الـ URIs القانونية صارمة: https://mcp.example.com وhttps://mcp.example.com:8443/mcp صالحة؛ أما mcp.example.com (بدون مخطط) وhttps://mcp.example.com#frag (مع جزء تجزئة) فليست كذلك. فضّل الصيغة دون شرطة مائلة لاحقة من أجل قابلية التشغيل البيني.

النائب المرتبك: لا تمرر الرمز أبدًا

هذا هو الخطأ الذي يحوّل خادم MCP حسن النية إلى وكيل للمهاجم. إنها نفس مشكلة النائب المرتبك من أمان الوكلاء، مشحوذةً إلى قاعدة واحدة ملموسة.

كثيرًا ما يحتاج خادم MCP إلى استدعاء واجهة برمجة تطبيقات أعلى في السلسلة (GitHub، خدمة قاعدة بيانات، خدمة SaaS أخرى). والإغراء هو أن تأخذ الرمز الذي سلّمك إياه العميل وتمرره إلى الأعلى. لا تفعل. المواصفة صريحة: يجب ألا (MUST NOT) يمرر خادم MCP الرمز الذي تلقاه من العميل.

لماذا هذا خطير: رمز العميل صدر لخادمك أنت كجمهور له. إذا مررته، فقد تثق به واجهة البرمجة الأعلى وكأنه أتى منك، أو تفترض أنك تحققت منه بالفعل — والآن رمز محدد النطاق لقفزة واحدة يقوم بعمل على بُعد قفزتين، خارج نموذج موافقة أي أحد.

Watch out

• إذا استدعى خادم MCP واجهة برمجة تطبيقات أعلى في السلسلة، فإنه يتصرف كعميل OAuth منفصل تجاه تلك الواجهة ويحصل على رمزه الخاص من خادم التفويض الأعلى. رمزان مستقلان، جمهوران مستقلان. رمز العميل يتوقف عند بابك.

قائمة تحقق للتحصين قبل الإقلاع

قبل أن يلامس خادم MCP بعيد الإنترنت العام:

Guided walkthrough1 of 7

1. يجب أن تكون كل نقاط نهاية الـ AS بـ HTTPS. ويجب أن تكون عناوين URIs لإعادة التوجيه HTTPS أو localhost — لا شيء غير ذلك.

اختبر نفسك

اختبر نفسك

0/4

1. 1يتلقى خادم MCP بعيد طلبًا دون رمز وصول. ما الذي تطلب منه المواصفة فعله أولًا؟
2. 2مِمَّ يحمي ربط جمهور الرمز (RFC 8707)؟
3. 3يحتاج خادم MCP الخاص بك إلى استدعاء واجهة برمجة تطبيقات GitHub أعلى في السلسلة. ماذا ينبغي أن يفعل برمز الوصول الذي أرسله العميل إليه؟
4. 4بالنسبة لخادم MCP يعمل عبر STDIO (محلي)، كيف تقول المواصفة إنه ينبغي التعامل مع بيانات الاعتماد؟

المصادر وقراءات إضافية

• مواصفة تفويض MCP (2025-06-18) — التدفق المعياري والأدوار ومتطلبات MUST/SHOULD التي تلخصها هذه الصفحة.
• أفضل ممارسات أمان MCP — تمرير الرمز، والنائب المرتبك، ولماذا يُحظران.
• RFC 8707 — Resource Indicators for OAuth 2.0 — معامل resource وربط الجمهور.
• RFC 9728 — OAuth 2.0 Protected Resource Metadata — كيف يعلن خادم الموارد عن خوادم تفويضه.
• RFC 8414 — OAuth 2.0 Authorization Server Metadata وRFC 7591 — Dynamic Client Registration.
• مسودة OAuth 2.1 — PKCE، وأمان الاتصال، ومتطلبات التعامل مع الرموز.
• ذو صلة على AILmanac: تأمين الوكلاء والأدوات · حقن التعليمات · MCP في Claude Code.