01نموذج الأدوار: خادم MCP كخادم موارد
منذ المراجعة 2025-06-18، يعمل خادم MCP المحمي كخادم موارد (Resource Server) وفق OAuth 2.1: فهو يستقبل رموز الوصول (Access Tokens) ويتحقق منها، لكنه لا يُصدرها بنفسه؛ ويعمل عميل MCP كعميل OAuth نيابةً عن المستخدم. أما خادم التفويض (Authorization Server) فهو دور منفصل – يجوز استضافته مع خادم الموارد، لكن تطبيقه يقع خارج نطاق المواصفة. ولم يكن الأمر كذلك دائمًا: فقد تعاملت المراجعة 2025-03-26 فعليًا مع خادم MCP بوصفه خادم تفويض وخادم موارد في آن واحد، مع نقاط نهاية افتراضية /authorize و/token و/register مباشرةً على خادم MCP. ويخفف الفصل الرسمي العبء عن مشغّلي الخوادم ويتيح استخدام مزوّدي هوية راسخين بدلًا من إصدار الرموز بحلول ذاتية الصنع.
02سلسلة الاكتشاف: RFC 9728 وRFC 8414
يعثر العميل على خادم التفويض المختص أثناء التشغيل بدلًا من الإعدادات: فعلى طلب دون رمز صالح، يردّ خادم MCP بالرمز 401 Unauthorized ويشير في ترويسة WWW-Authenticate إلى بيانات Protected Resource Metadata الخاصة به (RFC 9728) – وهي وثيقة إلزامية يذكر حقلها authorization_servers خادم تفويض واحدًا على الأقل. ومن هناك يحمّل العميل بيانات Authorization Server Metadata وفق RFC 8414 (/.well-known/oauth-authorization-server) مع نقاط نهاية التفويض والرموز والتسجيل؛ وعندها فقط يبدأ تدفق OAuth 2.1 الفعلي. ويحلّ هذا الاكتشاف أثناء التشغيل محل الإعدادات المضمّنة في الشيفرة – وهو أمر حاسم للوكلاء الذين لا تُخصَّص لهم الأدوات إلا أثناء التشغيل. وتضيف المراجعة 2025-11-25 اكتشاف OpenID Connect ومسارًا احتياطيًا عبر .well-known دون ترويسة؛ وتضيف المراجعة 2026-07-28 التحقق من المُصدِر (Issuer) وفق RFC 9207 للحماية من هجمات Mix-up.
03تسجيل العملاء: RFC 7591 وCIMD
نظرًا لأن أيّ عملاء MCP يلتقون بأيّ خوادم، فإن التسجيل اليدوي للعملاء لا يتوسع. لذلك توصي المراجعة 2025-06-18 (SHOULD) بالتسجيل الديناميكي للعملاء (Dynamic Client Registration) وفق RFC 7591: إذ يسجّل العميل نفسه عند نقطة نهاية التسجيل ويحصل على client_id خاص به – وفي الممارسة غالبًا كعميل عام (Public Client) دون سرّ عميل؛ والبدائل هي معرّف عميل مُخزَّن مسبقًا أو الإدخال اليدوي. غير أن المراجعة 2026-07-28 تعلن DCR مُهمَلًا (deprecated) وتعتمد على وثائق Client ID Metadata Documents (CIMD) التي أُدخلت مع المراجعة 2025-11-25: أي هويات عملاء قائمة على عناوين URL. وتوضح في الوقت ذاته أن بيانات اعتماد العملاء المحفوظة مرتبطة بخادم التفويض المُصدِر ولا يجوز إعادة استخدامها عبر حدود الخوادم. ويظل DCR يعمل مؤقتًا لأسباب تتعلق بالتوافق – وينبغي للتطبيقات الجديدة أن تعرف كلا المسارين.
04القواعد الأساسية لـ OAuth 2.1: PKCE والترويسة وفترات الصلاحية القصيرة
يتخلص OAuth 2.1 من الموروثات غير الآمنة في OAuth 2.0: إذ يُلغى Implicit Grant وPassword Grant، ولا تُطابَق عناوين إعادة التوجيه إلا بدقة تامة، ويصبح PKCE إلزاميًا – إذ يجب (MUST) على عملاء MCP تطبيق PKCE، وفي الممارسة باستخدام طريقة التحدي S256 بدلًا من «plain». وتوضع رموز الوصول كرموز Bearer في ترويسة Authorization لكل طلب على حدة، ولا يجوز أبدًا أن تظهر في سلسلة الاستعلام (Query String) لعنوان URI؛ وتعمل جميع نقاط نهاية خادم التفويض عبر HTTPS، وتقتصر عناوين إعادة التوجيه على localhost أو HTTPS. ويجب أن تكون رموز التحديث (Refresh Tokens) للعملاء العامين وفق OAuth 2.1 مقيّدة بالمُرسِل (sender-constrained) أو رموزًا لمرة واحدة مع التدوير. وتضيف التوصيات العملية الشائعة رموز وصول قصيرة العمر لا تتجاوز بضع دقائق، إضافةً إلى اكتشاف إعادة الاستخدام (Reuse-Detection) الذي يُبطل عائلة الرموز بأكملها عند إعادة استخدام رمز تحديث قديم.
05ربط الجمهور (RFC 8707) وحظر تمرير الرموز (Token-Passthrough)
يجب أن يُصدَر الرمز لخادم MCP واحد بعينه: إذ يجب (MUST) على العملاء إرسال المعامل resource وفق RFC 8707 في طلب التفويض وطلب الرمز، وتحديد عنوان URI القياسي للخادم المستهدف فيه؛ ويجب (MUST) على الخادم التحقق مما إذا كان هو الجمهور المقصود (intended audience)، ورفض الرموز الأجنبية أو منتهية الصلاحية بالرمز 401. وبالقدر ذاته من الصرامة يأتي حظر التمرير: إذ لا يجوز (MUST NOT) لخادم MCP تمرير الرمز الذي تلقاه من العميل إلى واجهات API اللاحقة، بل يعمل هناك كعميل OAuth مستقل برمز خاص به. وإلا ظهرت مشكلة Confused Deputy – إذ يتصرف الخادم كوكيل مُضلَّل بصلاحيات غيره، ويصبح تحديد المعدل (Rate Limiting) والمراقبة ومسار التدقيق في واجهة API اللاحقة بلا جدوى. كما يجب (MUST) على خوادم الوكيل (Proxy) ذات معرّف العميل الثابت الحصول على موافقة مستخدم مستقلة لكل عميل مسجَّل ديناميكيًا، لأن ملفات تعريف الارتباط الخاصة بالموافقة المُعاد استخدامها قد توجّه رموز التفويض (Authorization Codes) إلى المهاجمين.
06MCP07 في الممارسة: النتائج والضوابط
تُدرج OWASP MCP Top 10 (الإصدار v0.1، Beta – ليس معيارًا نهائيًا) هذا المجال تحت MCP07 «Insufficient Authentication & Authorization». والواقع العملي مخيّب للآمال: فقد وجدت Trend Micro في 2025 ما مجموعه 492 خادم MCP مكشوفًا على الإنترنت دون مصادقة أو تشفير للنقل، وأحصى تدقيق Astrix نسبة 53 بالمئة من مفاتيح API الثابتة مقابل 8.5 بالمئة فقط لـ OAuth، وأظهرت CVE-2025-6514 في حزمة npm المسماة mcp-remote (CVSS 9.6) أن حقول اكتشاف OAuth المُتلاعَب بها وحدها قد تؤدي إلى تنفيذ شيفرة. وتنطلق الضوابط الفعالة من المواصفة: OAuth 2.1 مع PKCE وخادم تفويض منفصل، ورموز قصيرة العمر مرتبطة بالجمهور بدلًا من التمرير – ومع الاستدعاءات نحو الخدمات العليا (Upstream) تبادل الرموز وفق RFC 8693 –، وموافقة لكل عميل في خوادم الوكيل، وخوادم MCP كهوية غير بشرية (Non-Human Identity) مستقلة ضمن IAM. وسؤالا فحص للتدقيق الداخلي ومجلس الإدارة: هل يجري تمرير للرموز في أيّ موضع من السلسلة – وما مدة صلاحية رمز الوكيل؟
