مراجعة متعمقة لمواصفات تفويض MCP (إصدار 2025-03-26)

MCP (بروتوكول سياق النموذج) هو معيار مفتوح يسمح لنماذج الذكاء الاصطناعي بالتفاعل مع الأدوات والخدمات الخارجية. إنها معتمدة على نطاق واسع من قِبل الصناعة. بما أن MCP يدعم الطرق النقل المستندة إلى HTTP، سيلعب خادم MCP البعيد دورًا متزايد الأهمية في نظام MCP البيئي.

على عكس خادم MCP المحلي، الذي يسمح لكل مستخدم بتشغيل نسخة خاصة به من الخادم، فإن خادم MCP البعيد يتطلب من جميع المستخدمين مشاركة نفس خدمة خادم MCP. هذا يثير المشكلة الأساسية التي تهدف إليها مواصفة تفويض MCP لحلها: كيف نسمح لخادم MCP بالوصول إلى موارد المستخدم نيابة عن المستخدم.

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

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

نظرة عامة على مواصفة تفويض MCP#

MCP Authorization Spec تعرف عملية المصادقة بين خادم MCP (بعيد) وعميل MCP.

أعتقد أن بناء هذه المواصفة على OAuth 2.1 هو اختيار معقول جدًا. OAuth كإطار عمل لبروتوكول التفويض يحل مشكلة كيفية السماح للمستخدمين بتفويض التطبيقات الخارجية للوصول إلى موارد المستخدم نيابة عنهم. إذا لم تكن مألوفًا مع OAuth، يمكنك الاطلاع على AuthWiki-OAuth لمزيد من المعلومات.

في سيناريو عميل MCP وخادم MCP، يتعلق الأمر بـ "المستخدمون الذين يفوضون عميل MCP للوصول إلى موارد المستخدم على خادم MCP". تشير "موارد المستخدم على خادم MCP" حاليًا إلى الأدوات التي يقدمها خادم MCP أو الموارد التي تقدمها خدمات الخلفية لخادم MCP.

لتنفيذ عملية المصادقة OAuth 2.1، يتطلب البروتوكول من خادم MCP توفير الواجهات التالية للعمل مع عميل MCP لإكمال عملية المصادقة OAuth 2.1:

• /.well-known/oauth-authorization-server: بيانات التعريف الخاصة بخادم OAuth
• /authorize: نقطة نهاية التفويض، تستخدم لطلبات التفويض
• /token: نقطة نهاية الرمزية، تستخدم لتبادل الرموز وتحديثها
• /register: نقطة تسجيل العميل, تستخدم للتسجيل الديناميكي للعميل

عملية المصادقة كما يلي:

تحدد المواصفة أيضًا كيف يدعم خادم MCP التفويض المندوب من خلال خوادم التفويض الخاصة بالأطراف الثالثة.

تدفق المثال في المواصفة كما يلي (من محتوى المواصفة):

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

في رأيي، يبدو هذا السيناريو أكثر ملاءمة للتعامل مع المواقف التي يقوم فيها خادم MCP بتمثيل عميل MCP (المستخدم) للوصول إلى الموارد الخاصة بأطراف ثالثة (مثل مستودعات Github)، بدلاً من قيام خادم MCP بتمثيل عميل MCP (المستخدم) للوصول إلى موارد خادم MCP نفسه.

بالمجمل، وفقًا للبروتوكول، يقوم خادم MCP بدور كل من خادم التفويض وخادم الموارد في OAuth.

بعد ذلك، دعونا نناقش مسؤوليات خادم MCP كخادم للتفويض وخادم للموارد.

خادم MCP كخدمة تفويض#

عندما يعمل خادم MCP كخادم تفويض، فهذا يعني أن المستخدم النهائي لعميل MCP لديه هوية خاصة به على خادم MCP. يكون خادم MCP مسؤولاً عن المصادقة لهذا المستخدم النهائي وإصدار رمزية الوصول لهذا المستخدم النهائي للوصول إلى موارد خادم MCP.

تتطلب الواجهات المتعلقة بالتفويض التي ذُكرت في مواصفة تفويض MCP من قبل أن يوفر خادم MCP تنفيذًا لوظائف خادم التفويض.

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

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

قد تتساءل، هل يجب أن يستخدم هذا النهج طريقة التفويض المندوب الخاصة بالطرف الثالث المذكورة أعلاه؟

من وجهة نظري، هذا يعتمد بشكل أساسي على ما إذا كان مستخدمو خدمة التفويض الخاصة بالطرف الثالث التي تعتمد عليها هم نفسهم المستخدمين النهائيين لخادم MCP. هذا يعني أن رمزية الوصول التي تم إصدارها لك من قبل خدمة التفويض الخاصة بالطرف الثالث سيتم استهلاكها مباشرةً من قبل خادم MCP الخاص بك.

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

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

أعتقد أن نهج التفويض المندوب الخاص بالطرف الثالث المحددة في البروتوكول غير واضح إلى حد ما في سيناريوهات التطبيق العملية. يبدو أن البروتوكول يسمح للطرف الثالث بمساعدة خادم MCP في إتمام عملية التفويض، ولكنه لا يزال يتطلب من خادم MCP إصدار رمزية الوصول الخاصة به. هذا في الواقع يعني أن خادم MCP لا يزال يتحمل مسؤولية إصدار رمزية الوصول كخادم تفويض، وهو ليس أكثر سهولة للمطورين. أعتقد أن السبب ربما هو أن مؤلفي البروتوكول اعتبروا أن إعادة رموز الوصول الخاصة بالطرف الثالث مباشرةً إلى عميل MCP ستجلب بعض قضايا الأمان (مثل التسريب/الإساءة، إلخ).

من تجربتي، فإن السيناريو الأكثر ملاءمة لنهج التفويض المندوب الخاص بالطرف الثالث المحدد في البروتوكول يجب أن يكون سيناريو "المستخدمين يفوضون خادم MCP للوصول إلى موارد الطرف الثالث". على سبيل المثال، يحتاج خادم MCP إلى الوصول إلى مكتبة Github الخاصة بالمستخدم ونشر شفرة المكتبة على منصة نشر الشفرات. في هذه الحالة، يحتاج المستخدم إلى تفويض خادم MCP للوصول إلى مكتبة Github الخاصة به والوصول إلى منصة نشر الشفرات.

في هذا السيناريو، يكون خادم MCP هو خادم تفويض لعميل MCP، لأن المستخدمين النهائيين لديهم هوية خاصة بهم على خادم MCP. وخادم MCP هو عميل طرف ثالث للموارد الطرف الثالث (في هذه الحالة، Github). يحتاج إلى الحصول على تفويض المستخدم للوصول إلى موارد المستخدم على Github. بين عميل MCP وخادم MCP، وبين خادم MCP والموارد الطرف الثالث، تكون هويات المستخدمين منفصلة. وهذا يجعل من المهم الحفاظ على علاقة تعيين بين الرموز الوصول التي يصدرها خادم MCP نفسه والرموز الوصول التي تصدرها خدمات التفويض الخاصة بالطرف الثالث في خادم MCP.

لذلك يجب أن يحل نهج التفويض المندوب الخاص بالطرف الثالث المحدد في البروتوكول مشكلة "كيفية تفويض المستخدمين لخادم MCP للوصول إلى موارد المستخدم على خوادم الموارد الخاصة بالطرف الثالث".

خادم MCP كخادم موارد#

عندما يعمل خادم MCP كخادم موارد، يحتاج خادم MCP إلى التحقق مما إذا كانت طلبات عميل MCP تحتوي على رمز وصول صالح. سيقرر خادم MCP ما إذا كان سيسمح لعميل MCP بالوصول إلى موارد معينة بناءً على نطاق رمز الوصول.

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

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

في هذه الحالة، بدلاً من القول إن خادم MCP هو خادم موارد، يقدم الأدوات وموارد خدمته، فإنه من الأفضل القول إن خادم الموارد الحالي يصبح خادم MCP من خلال تقديم الأدوات لعميل MCP لاستخدامها.

تضمين الموارد التي يوفرها خادم الموارد الخاص بهم في الموارد التي يقدمها خادم MCP ينبع من اعتبارات سيناريوهات العالم الحقيقي. ولكن شخصيًا ما زلت أفضل أن تكون الموارد التي يقدمها خادم MCP هي فقط الأدوات التي يستخدمها عميل MCP، والموارد التي تعتمد عليها الأدوات يجب أن تكون الموارد التي يحصل عليها خادم MCP من خوادم موارد أخرى (بما في ذلك المصادر الأولى والطرف الثالث). وبهذه الطريقة، يمكن تغطية جميع سيناريوهات العالم الحقيقي.

كيف يعمل تفويض MCP#

بعد فهم مسؤوليات خادم MCP كخادم تفويض وخادم موارد، يمكننا أن نعرف كيف يعمل تفويض MCP على وجه التحديد:

تسجيل العميل الديناميكي#

تُعرف المواصفة أيضًا كيفية تحديد خادم التفويض للعملاء. يوفر OAuth 2.1 بروتوكول تسجيل العميل الديناميكي، مما يسمح بتسجيل عملاء MCP تلقائيًا للحصول على معرّف عميل OAuth بدون تدخل يدوي من المستخدم.

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

• لا يمكن للعملاء MCP معرفة جميع الخوادم الممكنة مسبقًا
• سيتسبب التسجيل اليدوي في عناء للمستخدمين
• يجعل الاتصال مع الخوادم الجديدة سلساً
• يمكن للخوادم تنفيذ سياسات التسجيل الخاصة بها

لكن من منظور عملي، لدي بعض الأفكار حول تطبيق تسجيل العميل الديناميكي في سيناريوهات MCP:

• في التطبيقات العملية لخدمات OAuth، تكون العميل عادةً واحدة إلى واحدة مطابقة لتطبيقات الأعمال التجارية المحددة. قد لا يكون إنشاء العملاء ديناميكيًا مفيدًا لإدارة الموارد ذات الصلة (المستخدمون، التطبيقات، إلخ) بشكل فعال في خدمات OAuth. عادةً ما يسعى مقدمو خدمات OAuth للحصول على تحكم واضح في العملاء المرتبطين، بدلاً من السماح لأي عميل بالتسجيل كعميل حسب الرغبة.
• لا توصي أو لا تسمح العديد من خدمات OAuth للمستخدمين بإنشاء العملاء ديناميكيًا، لأن ذلك قد يؤدي إلى إساءة استخدام الخدمة. يتطلب معظم مقدمي خدمات OAuth المهرة (مثل GitHub، Google، إلخ) من المطورين تسجيل العملاء يدويًا عبر وحدة تحكم المطورين الخاصة بهم، وقد يكون من الضروري أيضًا توفير معلومات مفصلة عن التطبيق، عنوان الردودة، إلخ.
• إن تسجيل العميل OAuth يدويًا هو في الواقع مهمة تقوم بها أثناء التطوير مرة واحدة، وليس شيئًا يحتاج كل مستخدم نهائي إلى فعله. لن يشكل عبءًا كبيرًا على المطورين.
• بالنسبة للعملاء العامة (مثل التطبيقات المحلية، التطبيقات ذات الصفحة الواحدة، إلخ.)، لدينا طرق آمنة لتنفيذ تدفق OAuth بدون التسجيل الديناميكي. يمكن لمعرّف العميل المتزامن مع PKCE (رمز التبادل للتبادل الرمزي) توفير تدفق OAuth آمن بما فيه الكفاية للعملاء العامة بدون إنشاء العملاء ديناميكيًا.
• على الرغم من أن البروتوكول أشار إلى أن استخدام تسجيل العميل الديناميكي يمكن أن يتجنب حاجة العملاء لمعرفة معرّف العميل مسبقًا، في الواقع، يحتاج عملاء MCP دائمًا إلى معرفة عنوان خادم MCP البعيد مسبقًا. إذا كان الأمر كذلك، تحديد معرّف العميل أثناء إدخال عنوان خادم MCP البعيد لن يجلب الكثير من المتاعب. أو، يمكننا أيضًا إنشاء اتفاقية لعميل MCP لطلب معرّف العميل من خادم MCP، وهو ليس مهمة صعبة.

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

الخلاصة#

يحلل هذا المقال بعمق فلسفة التصميم وتحديات تنفيذ مواصفة تفويض MCP. كبنية تفويض مستندة إلى OAuth 2.1، تهدف هذه المواصفات إلى حل المشكلة الرئيسية المتمثلة في كيفية وصول خادم MCP البعيد إلى موارد المستخدمين نيابة عنهم.

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

من الجدير بالذكر أن مواصفة تفويض MCP لا تزال تتطور. كعضو في فريق Logto، سنواصل الانتباه لأحدث التطورات في هذه المواصفة وسنواصل تحسين حلولنا التنفيذية في الممارسة للمساهمة في التفاعل الآمن بين نماذج الذكاء الاصطناعي والخدمات الخارجية.