مصادقة وتفويض MCP: OAuth 2.1، تفويض الرموز، ومشكلة النائب المرتبك

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

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

تحدي المصادقة في MCP

تواجه خوادم MCP مشهد مصادقة أكثر تعقيداً من الخدمات التقليدية لأنها تتوسط بين عدة أطراف رئيسية:

• المستخدم الذي تقود تعليماته مساعد الذكاء الاصطناعي
• نموذج الذكاء الاصطناعي الذي يفسر التعليمات ويستدعي الأدوات
• عميل MCP (التطبيق الذي يستضيف الذكاء الاصطناعي)
• خادم MCP الذي ينفذ استدعاءات الأدوات
• الخدمات النهائية التي يستدعيها خادم MCP نيابة عن المستخدم

تتطلب كل من هذه العلاقات ضوابط المصادقة والتفويض الخاصة بها. يمكن استغلال الضعف في أي رابط لتجاوز الآخرين.

إلزامي: OAuth 2.1 و OIDC للخوادم البعيدة

بالنسبة لخوادم MCP البعيدة — تلك التي يتم الوصول إليها عبر شبكة بدلاً من STDIO المحلي أو مقابس Unix — دليل OWASP GenAI واضح: OAuth 2.1 مع OIDC إلزامي، وليس اختيارياً.

هذا المتطلب موجود لأن:

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

يوفر OIDC هوية تشفيرية. يضيف OpenID Connect تأكيدات الهوية (رمز المعرف) التي يمكن لخادم MCP التحقق منها دون رحلة ذهاب وإياب إلى مزود الهوية. يتحقق الخادم من iss (المُصدر)، وaud (الجمهور)، وexp (انتهاء الصلاحية)، والتوقيع على كل طلب.

رموز OAuth 2.1 قصيرة العمر بالتصميم. تؤكد مواصفات OAuth الحديثة (التي توحد وتحل محل أفضل ممارسات OAuth 2.0) على رموز الوصول قصيرة العمر التي يجب تحديثها بانتظام. هذا يحد من نافذة الضرر إذا تم اختراق رمز.

ما يجب التحقق منه في كل طلب

لا تتحقق من الرموز فقط عند إنشاء الجلسة. تحقق من كل استدعاء أداة:

def validate_token(token: str, required_scope: str) -> TokenClaims:
    claims = jwt.decode(
        token,
        key=get_public_key(claims_preview['kid']),
        algorithms=["RS256", "ES256"]
    )

    assert claims['iss'] == EXPECTED_ISSUER
    assert EXPECTED_AUDIENCE in claims['aud']
    assert claims['exp'] > time.time()
    assert required_scope in claims['scope'].split()

    return claims

لا تخزن نتائج التحقق مؤقتاً عبر الطلبات. قد يتم إلغاء رمز كان صالحاً عند بداية الجلسة في منتصف الجلسة.

بيئات العملاء الديناميكية

في البيئات التي تتغير فيها عملاء MCP بشكل متكرر (على سبيل المثال، مساعدي ذكاء اصطناعي مختلفين يتصلون بنفس الخادم)، فإن مفاتيح API الثابتة أو الأسرار المشتركة مسبقاً غير كافية. استخدم تسجيل العميل الديناميكي مع OAuth 2.1 أو OIDC للتحقق من هوية العميل في وقت الاتصال. قوائم السماح أو سياسات الاتصال المشفرة أو TLS المتبادل (mTLS) مناسبة للعلاقات الثابتة المعروفة بين عملاء وخوادم محددة.

هل أنت مستعد لتنمية عملك؟

ابدأ تجربتك المجانية اليوم وشاهد النتائج في غضون أيام.

طلب عرض توضيحي تسجيل الدخول

مشكلة النائب المرتبك

فهم الهجوم

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

ضع في اعتبارك هذا السيناريو:

• المستخدمة أليس مصادق عليها لخادم MCP بأذونات محدودة — يمكنها قراءة ملفاتها الخاصة فقط وليس ملفات الآخرين
• لدى خادم MCP أذونات حساب خدمة واسعة لقراءة جميع الملفات في المؤسسة
• يستخدم خادم MCP تمرير الرموز: يعيد توجيه رمز أليس إلى الخدمات النهائية

عندما تطلب أليس من مساعد الذكاء الاصطناعي “تلخيص مجلد مشروعي”، يستخدم الخادم رمز أليس للوصول إلى ملفاتها — سلوك صحيح. ولكن إذا خدع مهاجم الخادم لإجراء طلب باستخدام بيانات اعتماد الخدمة الخاصة به (ربما من خلال هجوم تسميم الأداة أو حقن موجه غير مباشر)، يتم استخدام أذونات الخادم المرتفعة للوصول إلى الملفات التي لا يُصرح لأليس برؤيتها.

الخادم هو “النائب المرتبك” — لقد تم خداعه لاستخدام سلطته نيابة عن شخص ليس لديه تلك السلطة، ويعمل كوكيل لتصعيد الامتيازات.

لماذا يخلق تمرير الرموز هذه الثغرة

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

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

يؤدي إعادة توجيه رموز المستخدم أيضاً إلى:

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

الحل: تفويض رموز صريح مع تدفقات نيابة عن

بدلاً من إعادة توجيه رموز العميل، يجب على خادم MCP الحصول على رموزه الخاصة للوصول إلى الخدمة النهائية باستخدام تدفق نيابة عن (OBO) لـ OAuth:

يصادق المستخدم على عميل MCP → يحصل العميل على رمز وصول المستخدم
يقدم عميل MCP رمز المستخدم إلى خادم MCP
يستبدل خادم MCP رمز المستخدم برمز خادم عبر تدفق OBO:
  POST /token
  grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
  assertion=<user_access_token>
  scope=<minimum_required_scope>
يستخدم خادم MCP رمز OBO الخاص به للمكالمات النهائية

رمز OBO:

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

رموز قصيرة العمر ومحددة النطاق

يقدم دليل OWASP GenAI توصية محددة: إصدار رموز وصول بأعمار تُقاس بالدقائق، وليس بالساعات. ينطبق هذا على كل من الرموز التي يقبلها خادم MCP من العملاء والرموز التي يحصل عليها للوصول إلى الخدمة النهائية.

لماذا تهم الأعمار القصيرة

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

تفرض الرموز قصيرة العمر أيضاً أحداث إعادة مصادقة منتظمة، والتي توفر فرصاً لـ:

• إعادة التحقق مما إذا كان حساب المستخدم قد تم تعليقه أو تغيرت أذوناته
• اكتشاف أنماط مصادقة شاذة (أوقات أو مواقع أو تكرار غير عادي)
• تطبيق مصادقة متقدمة للعمليات الحساسة

تقليل نطاق الرمز

يجب أن يحمل كل رمز فقط النطاقات المطلوبة للعملية المحددة التي يتم تنفيذها. لا تصدر رمزاً بنطاق read:files write:files delete:files عندما يحتاج استدعاء الأداة الحالي فقط إلى read:files. هذا يحد من الضرر إذا تم اعتراض الرمز أو تم التلاعب بالنموذج لإجراء استدعاءات أدوات غير متوقعة.

def get_tool_token(user_id: str, tool_name: str) -> str:
    # ربط الأداة بالحد الأدنى من النطاقات المطلوبة
    required_scopes = TOOL_SCOPE_MAP[tool_name]

    return oauth_client.get_token(
        subject=user_id,
        scopes=required_scopes,
        lifetime_seconds=300  # عمر 5 دقائق
    )

انضم إلى نشرتنا الإخبارية

احصل على أحدث النصائح والاتجاهات والعروض مجانًا.

عنوان البريد الإلكتروني

اشترك

معاملة الجلسات كحالة، وليس هوية

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

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

هذا مهم لأن معرفات الجلسة يمكن سرقتها أو تخمينها أو إعادة تشغيلها بطرق لا تستطيع رموز OAuth — التي تحمل ضمانات سلامة تشفيرية — القيام بها.

إنفاذ السياسة المركزية

بدلاً من تنفيذ فحوصات التفويض المتناثرة في جميع معالجات الأدوات الفردية، يوصي دليل OWASP GenAI ببوابة سياسة مركزية تقوم بـ:

• اعتراض جميع طلبات استدعاء الأدوات قبل وصولها إلى كود خاص بالأداة
• التحقق من المصادقة (توقيع الرمز، المُصدر، الجمهور، انتهاء الصلاحية)
• فرض التفويض (النطاق المطلوب لهذه الأداة المحددة)
• تطبيق التحقق من الموافقة (هل صرح المستخدم صراحةً بهذا النوع من الإجراءات؟)
• تنفيذ تصفية الأدوات (هل هذه الأداة مسموح بها في سياق النشر هذا؟)
• تسجيل جميع القرارات مع السياق الكامل للتدقيق

يضمن المركزية تطبيق السياسات بشكل متسق عبر جميع الأدوات والوكلاء. يمكن نسيان أو تجاوز فحص التفويض الخاص بالأداة أثناء التطوير؛ لا يمكن تجاوز فحص البوابة.

الملخص: قائمة التحقق من المصادقة

بالنسبة لخوادم MCP البعيدة، فإن الحد الأدنى من شريط أمان المصادقة هو:

• فرض OAuth 2.1 / OIDC لجميع الاتصالات
• التحقق من توقيع الرمز والمُصدر والجمهور وانتهاء الصلاحية في كل استدعاء أداة
• عدم تمرير الرموز إلى واجهات برمجة التطبيقات النهائية — استخدم رموز OBO أو الرموز الصادرة عن الخادم
• نطاق رموز الوصول للحد الأدنى من الأذونات المطلوبة لكل أداة
• أعمار الرموز تُقاس بالدقائق مع تحديث إلزامي
• عدم استخدام معرفات الجلسة كوكلاء تفويض
• وجود بوابة إنفاذ سياسة مركزية
• تسجيل جميع أحداث المصادقة وقرارات التفويض بشكل غير قابل للتغيير

موارد ذات صلة

• أمان خادم MCP: 6 ثغرات أمنية حرجة
• قائمة التحقق من أمان MCP: الحد الأدنى للنشر الآمن
• أمان API LLM: تحديد المعدل والمصادقة ومنع إساءة الاستخدام
• تأمين وكلاء الذكاء الاصطناعي: منع الهجمات متعددة الخطوات
• تدقيق أمان chatbot الذكاء الاصطناعي: ما يمكن توقعه