آلية المصادقة OAuth 2.1 في بروتوكول سياق النموذج (MCP): دليل شامل

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

مراحل عملية المصادقة

تتكون عملية المصادقة في MCP من ثلاث مراحل رئيسية:

1. مرحلة الاكتشاف (Discovery Phase)

عند محاولة عميل MCP الاتصال بخادم محمي، يستجيب الخادم برمز حالة 401 (غير مصرح به) مع رأس WWW-Authenticate الذي يشير إلى خادم المصادقة الخاص به. يستخدم العميل بعد ذلك البيانات الوصفية التي يوفرها خادم المصادقة لاكتشاف إمكاناته وفهم كيفية المتابعة في عملية المصادقة.

2. مرحلة المصادقة (Authorization Phase)

بعد أن يفهم العميل كيفية تعامل الخادم مع المصادقة، يبدأ عملية التسجيل والمصادقة. إذا كان خادم المصادقة يدعم تسجيل العملاء الديناميكي (Dynamic Client Registration)، فيمكن للعميل تسجيل نفسه تلقائيًا دون الحاجة إلى إعداد يدوي. خلال هذه الخطوة، يقدم العميل تفاصيل أساسية مثل اسمه، ونوعه، و عناوين إعادة التوجيه (redirect URLs)، ونطاقات الوصول المطلوبة. في المقابل، يُصدر خادم المصادقة بيانات اعتماد العميل – عادةً معرف العميل (client_id) وسر العميل (client_secret) – والتي سيستخدمها العميل في الطلبات اللاحقة. تُسهّل هذه العملية دمج عملاء جدد بشكل أسرع وأكثر قابلية للتطوير، خاصة في البيئات الكبيرة أو الآلية.

بعد التسجيل، يبدأ العميل تدفق OAuth المناسب:

• تدفق رمز المصادقة (Authorization Code flow): يُستخدم عند العمل نيابةً عن مستخدم بشري.
• تدفق بيانات اعتماد العميل (Client Credentials flow): يُستخدم للتواصل الآمن بين الآلات.

في تدفق رمز المصادقة، يُطلب من المستخدم منح الموافقة. بمجرد الموافقة، يُصدر خادم المصادقة رمز وصول (access token) مع النطاقات المناسبة للعميل لاستخدامها.

3. مرحلة الوصول (Access Phase)

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

تحسينات الأمان في MCP OAuth 2.1

تتضمن مواصفات مصادقة MCP العديد من ترقيات الأمان المهمة لجعل العملية أكثر أمانًا وموثوقية:

• PKCE الإلزامي: يجب على جميع عملاء MCP استخدام PKCE (Proof Key for Code Exchange) كما هو مُعرّف في OAuth 2.1. يضيف PKCE طبقة حماية من خلال إنشاء زوج “مُتحقق-تحدي” سري، مما يضمن أن العميل الأصلي الذي بدأ الطلب فقط هو من يستطيع استبدال رمز المصادقة برموز الوصول. هذا يمنع الهجمات مثل اعتراض أو حقن الرموز.
• التحقق الصارم من عنوان إعادة التوجيه (Redirect URI): يجب على العملاء تسجيل عناوين إعادة التوجيه الدقيقة الخاصة بهم مسبقًا لدى خادم المصادقة. عند حدوث المصادقة، يتحقق الخادم من المطابقة الدقيقة. هذا يمنع المُهاجمين من إعادة توجيه الرموز إلى مواقع غير مصرح بها.
• الرموز قصيرة الأجل: يُشجّع خادم المصادقة على إصدار رموز وصول قصيرة الأجل. إذا تم الكشف عن رمز أو سرقته عن طريق الخطأ، فإن عمره القصير يقلل من خطر إساءة الاستخدام.
• نموذج النطاق الدقيق (Granular Scope Model): يسمح MCP OAuth 2.1 بمنح أذونات دقيقة الحبيبات باستخدام النطاقات، بحيث يحصل العملاء فقط على الوصول لما يحتاجونه. أمثلة:
  • mcp:tools:weather: الوصول إلى أدوات الطقس فقط.
  • mcp:resources:customer-data:read: الوصول للقراءة فقط إلى بيانات العملاء.
  • mcp:exec:workflows:*: إذن لتشغيل أي سير عمل.
• تسجيل العملاء الديناميكي: يمكن لعملاء وخوادم MCP دعم التسجيل التلقائي للعملاء. هذا يسمح للعملاء الجدد بالحصول على بيانات اعتمادهم (مثل معرفات العملاء) بدون إعداد يدوي، مما يجعل دمج وكلاء الذكاء الاصطناعي الجديد أسرع وأسهل.

تنفيذ OAuth 2.1 لخوادم MCP (سيتم تغطية هذا في مقال لاحق)

في قسم لاحق من المقال، سنتعمق في كيفية تنفيذ OAuth 2.1 لخوادم MCP. سننشئ خادمًا بسيطًا لتحليل مشاعر البيانات المالية ونُنفّذ المصادقة باستخدام Scalekit الذي يُبسّط العملية برمتها.

المصدر: MarkTechPost