عرضت AWS كيفية توصيل خوادم MCP المحمية بـ OAuth إلى Bedrock AgentCore Gateway

أظهرت أمازون ويب سيرفيسز كيفية ربط خوادم MCP محمية بـ OAuth بـ Amazon Bedrock AgentCore Gateway من خلال تدفق Authorization Code. السيناريو مصمم للفرق التي تحتاج إلى تسجيل دخول موحد لوكلاء الذكاء الاصطناعي في الأدوات المؤسسية بدون رموز مضمنة وبدون إعداد يدوي لكل تكامل.

لماذا يكون بوابة Amazon Bedrock AgentCore Gateway ضرورياً

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

هذا مهم بشكل خاص للشركات التي تتضاعف فيها خوادم MCP: الخدمات الداخلية الخاصة وGitHub وSalesforce وDatabricks والأنظمة الخارجية الأخرى. يتم حماية العديد من هذه الخوادم بـ OAuth 2.0 ويتطلب أن يعمل الوكيل نيابة عن مستخدم معين.

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

أسلوبان للاتصال

في المقالة، تعرض أمازون ويب سيرفيسز طريقتين لربط خادم MCP محمي بـ OAuth بالبوابة. الأول هو المزامنة الضمنية عند إنشاء هدف: يمر المسؤول عبر تدفق Authorization Code أثناء CreateGatewayTarget أو UpdateGatewayTarget أو SynchronizeGatewayTargets، وبعد ذلك تقرأ البوابة قائمة الأدوات وتخزنها مؤقتاً. الثاني هو توفير مخطط الأداة مسبقاً دون انتظار طلب مباشر للخادم أثناء إنشاء الهدف. تسمي أمازون ويب سيرفيسز مباشرة الخيار الثاني بأنه مفضل حيث لا يكون التدخل البشري في الإنشاء أو التحديث ممكناً.

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

كمثال، تستخدم أمازون ويب سيرفيسز خادم MCP الخاص بـ GitHub. لمثل هذا السيناريو، تحتاج إلى بوابة على إصدار MCP 2025-11-25 أو أحدث، وإلا فإن خيار Authorization code grant 3LO لن يكون متاحاً. يحدد الإعداد أيضاً عنوان URL الراجع: هذا هو المكان الذي يعود إليه المستخدم أو المسؤول بعد شاشة الموافقة، ثم تكمل التطبيق التبادل عبر CompleteResourceTokenAuth.

كيف يعمل التفويض

الجزء الرئيسي من النمط هو ربط AgentCore Gateway و AgentCore Identity. أولاً، تحصل البوابة على رمز وصول عبء العمل، مما يؤكد أن لها الحق في طلب بيانات الاعتماد نيابة عن عبء عملها. ثم، من خلال موفر بيانات الاعتماد، تتلقى إما رمز وصول جاهز أو عنوان URL التفويض وعنوان URI للجلسة إذا لم يتم إصدار رمز بعد لمستخدم معين. في مرحلة الإعداد الأولي للهدف، قد ينتهي الأمر به في حالة Needs authorization، وبعد إكمال الموافقة، ينتقل إلى Ready بعلامة Authorized.

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

بالنسبة للمستخدم النهائي، المنطق أبسط. يتم خدمة طلب tools/list من ذاكرة البوابة المؤقتة ولا يفرض عليك تسجيل الدخول إلى جميع الأنظمة المتصلة مسبقاً. لكن tools/call بالفعل يبدأ تدفق Authorization Code فقط لخادم MCP هذا الذي يتم استدعاء أداته فعلاً. بعد تسجيل الدخول الناجح، يتم تخزين الرمز مؤقتاً في Token Vault في ربط هوية عبء العمل وهوية المستخدم، لذا فإن استدعاءات لاحقة تمر بدون تفويض جديد طالما الرمز صالحاً.

ماذا يعني هذا

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