شرح مصادقة MCP: الهوية الواردة، وبيانات الاعتماد الصادرة، والتفويض

تعالج الرموز المميزة التي تحدد هوية المتصل بالبوابة وبيانات الاعتماد المستخدمة للوصول إلى الخدمات الممتدة (downstream) مشكلات مختلفة. وتحافظ أنظمة MCP الآمنة على هذا التمييز.

المصادقة ليست قفزة واحدة

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

إن استخدام كلمة "رمز مميز" (token) لكل بيانات اعتماد يؤدي إلى تلاشي هذه الحدود. فبيانات الاعتماد الواردة تجيب على سؤال: من الذي يتصل بالبوابة؟ وتجيب سياسة الوصول على سؤال: ما هي موارد البوابة التي يحق لتلك الهوية استخدامها؟ بينما تحدد المصادقة الصادرة بيانات الاعتماد والأذونات الخاصة بالجهة التي يتلقاها الخادم الممتد. ويمكن أن تكون هذه الإجابات مختلفة عن قصد.

تفصل وثائق TrueFoundry البنية التحتية إلى المصادقة الواردة، والتحكم في الوصول، والمصادقة الصادرة. وهذا الفصل هو نقطة البداية الصحيحة للتحليل والقياس فيما يتعلق بالتفويض، والإسناد، ومخاطر النائب المرتبك (confused-deputy).

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

المصادقة الواردة تحدد هوية المتصل بالبوابة

توثق TrueFoundry عدة طرق واردة: رمز الوصول الشخصي للمستخدمين الذين لديهم حسابات TrueFoundry، ورمز الحساب الافتراضي للمتصلين من خدمة إلى خدمة، ورمز موفر الهوية للعملاء أو الخدمات التي تستخدم مُصدر JWT الخاص بالمؤسسة، و TrueFoundry OAuth لعملاء بيئة التطوير المتكاملة (IDE) المتوافقين.

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

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

المصادقة الصادرة تحدد الكيان الأساسي الممتد

قد تقوم البوابة بالمصادقة على خادم MCP باستخدام رمز تفويض OAuth لكل مستخدم، أو بيانات اعتماد عميل OAuth على مستوى التطبيق، أو تكوين تبادل الرموز/OBO الموثق لـ Okta، أو مفاتيح API المشتركة أو الفردية، أو بدون مصادقة للخدمات العامة، أو تمرير الرموز المميزة (token passthrough)، أو توجيه الرموز المميزة (token forwarding)، أو AWS SigV4 لنقاط نهاية AWS المدعومة.

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

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

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

التمرير والتوجيه ليسا مترادفين

في المصطلحات الموثقة لـ TrueFoundry، يقوم تمرير الرمز المميز (token passthrough) بتوجيه نفس الرمز المميز المستخدم للمصادقة الواردة إلى خادم MCP. ويجب أن يكون الخادم قادرًا على التحقق من صحة رمز TrueFoundry أو رمز موفر الهوية. بينما يحمل توجيه الرمز المميز (token forwarding) بيانات اعتماد منفصلة خاصة بالخادم يقدمها العميل في رؤوس مخصصة (headers). وبالتالي فإن بيانات الاعتماد الصادرة ليست هي الرمز الوارد نفسه.

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

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

نمذجة الكيانات الأساسية وليس الرؤوس فقط

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

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

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

يجب أن تحافظ كل قفزة أيضًا على معرف ارتباط مراجعة الحسابات (audit correlation identifier) دون نسخ الرموز المميزة إلى السجلات. سجل وضع بيانات الاعتماد، والهوية المحسوبة، والمُصدر، والجمهور، وفئة النطاق، وإصدار السياسة، والبيانات الوصفية للاستجابة الممتدة. القيم السرية مكانها المحافظ الآمنة، وليس النصوص أو مسارات التتبع.

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

مثال عملي: الوصول إلى CRM لدعم العملاء

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

نفترض أن النشر يستخدم تكوين Okta OBO الموثق لـ TrueFoundry. تبادل البوابة رمز المستخدم الوارد برمز موجه لجمهور CRM بنطاق قراءة الحالات فقط. يتحقق CRM من صحة الرمز الجديد ويطبق الترخيص الخاص به على مستوى الصفوف. يمكن للوكيل استرداد حالات الموظف المسموح بها ولكن لا يمكنه تعديلها. تتطلب أداة التحديث المنفصلة نطاقًا ممتدًا أضيق وموافقة مستقلة.

إذا كان النشر يستخدم بدلاً من ذلك مفتاح API مشتركًا، فيجب على البنية التحتية التعويض عن ذلك. تتلقى الخدمة المواجهة لـ CRM سمة موضوع محسوبة وموثوقة من البوابة، وتتحقق من صحتها، وتصفي السجلات على جانب الخادم. إذا كانت الخدمة لا تستطيع إنفاذ سياق الموضوع، فإن المفتاح المشترك يكون غير مناسب للبيانات ذات الترخيص الخاص بالمستخدم.

اختيار المصادقة الصادرة حسب دلالات السلطة

• إستخدام الترخيص لكل مستخدم عندما تكون الموارد الممتدة مملوكة أو مرخصة لكل شخص على حدة.
• إستخدام بيانات اعتماد العميل للموارد المملوكة بحق للتطبيق، وليس كاختصار للتجاوز عن ترخيص المستخدم.
• إستخدام تبادل الرموز أو OBO عندما يحتاج النظام الممتد إلى رمز مستخدم مفوض وخاص بجمهور معين.
• إستخدام التمرير (passthrough) فقط عندما يثق النظام الممتد عمداً بالرمز الوارد ويتحقق من صحته.
• إستخدام التوجيه (forwarding) عندما يحتوي خادم MCP على مخطط بيانات اعتماد منفصل وتحمّل عبء إدارة أسرار العميل الناتج عن ذلك.
• تعامل مع الخوادم التي لا تتطلب مصادقة على أنها إمكانيات عامة؛ لا تضع بيانات حساسة أو عمليات تعديل خلفها.

اختبارات الفشل لسلسلة المصادقة

• قم بإعادة تشغيل رمز صالح يحتوي على جمهور أو مُصدر أو مستأجر أو موضوع معين خاطئ.
• قم بتثبيت المستخدم وتغيير هوية الوكيل؛ وتحقق من أن وصول الأداة الفعلي يتغير كما هو مخطط له.
• قم بتثبيت الوكيل وتغيير المستخدم؛ وتحقق من أن البيانات الممتدة تتبع الموضوع البشري حيثما كان ذلك مطلوبًا.
• استبدل بيانات اعتماد فردية من خلال تجاوز مصادقة مستخدم آخر.
• إلغِ منح البوابة ومنح OAuth العلوي بشكل مستقل؛ وتحقق من تأثيراتهما المختلفة.
• استدعِ خادم MCP من خارج البوابة؛ وتحقق من أن سياسة الشبكة والخادم تمنع التجاوز عند اللزوم.
• افحص السجلات ومسارات التتبع والأخطاء وسياق النموذج للتأكد من عدم تسرب الرموز المميزة أو الأسرار الموجهة.

دورة حياة بيانات الاعتماد هي جزء من مسار البيانات

يستمر تصميم المصادقة بعد قبول الرمز المميز. إذ تنتهي صلاحية بيانات الاعتماد وتُجدد وتُدوّر وتُلغى في أنظمة مختلفة. تشير وثائق TrueFoundry، على سبيل المثال، إلى أن إجراء "إلغاء جميع الرموز المميزة" الخاص بها يحذف بيانات الاعتماد المخزنة من AI Gateway ولكنه لا يلغي المنح عند موفر OAuth العلوي. ويحتاج المشغلون إلى إجراءات منفصلة لبيانات اعتماد البوابة، وجلسة موفر الهوية، والترخيص العلوي، وأي رمز مميز ممتد مخزن موقتًا.

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

ينشئ التدوير حد اختبار آخر. قد تحتاج مفاتيح API المشتركة إلى فترة مفاتيح مزدوجة؛ وقد تُبطل رموز OAuth الخاصة بكل مستخدم بشكل مستقل؛ وقد تُخزن رموز OBO مؤقتًا حتى انتهاء صلاحيتها بينما يجب أن يظل الرمز الوارد حاديًا لإعادة التبادل. خزن معرفات وضع بيانات الاعتماد وعائلة الرموز المميزة في بيانات وصفية تشغيلية محمية حتى يتمكن القائمون على الاستجابة من العثور على النداءات المتأثرة دون كشف الأسرار.

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

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

القاعدة التشغيلية

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

توفر بوابة TrueFoundry MCP Gateway آليات موثقة لكل طبقة مواجهة للبوابة، ويمكن لهوية الوكيل (Agent Identity)—الموثقة كإصدار تجريبي في خريطة توفر الحوكمة—التمييز بين الجهة الفاعلة البرمجية والموضوع البشري. ولا يزال التطبيق الممتد يمتلك ترخيص النطاق الخاص به وتظل المؤسسة تمتلك الحد الأدنى لبيانات الاعتماد. وهذا الحد ليس قيدًا في الشرح؛ بل هو ما يجعل نموذج الأمان قابلاً للاختبار.

المراجع

1. TrueFoundry — مصادقة وأمان بوابة MCP.
2. TrueFoundry — هوية الوكيل (Agent Identity).
3. TrueFoundry — نظرة عامة على بوابة MCP.
4. IETF RFC 8693 — تبادل رموز OAuth 2.0.

إخلاء مسؤولية التحرير. تعكس هذه المقالة التفسير الهندسي لشركة TrueFoundry للمواد العامة المذكورة اعتبارًا من 17 سبتمبر 2026. وتقتصر إمكانيات المنتج على الوثائق المرتبطة. وتعد الأمثلة والإعدادات الافتراضية التشغيلية توضيحية؛ ولا تعتبر مشورة قانونية، أو رأي مراجعة، أو معيارًا مستقلًا، أو ضمانًا للأمان أو السلامة أو الامتثال.

‍