حل مشكلة مصادقة MCP عند التوسع
لقد قمت ببناء خادم MCP. إنه يعمل على جهاز الكمبيوتر الخاص بك. يمكن لمساعد الذكاء الاصطناعي الخاص بك إنشاء تذاكر Jira والاستعلام عن قواعد البيانات. كل شيء يسير على ما يرام حتى يطلب أحد زملائك استخدامه.
إذا كنت ترغب في بيع الـ MCP الخاص بك كمنتج، فستواجه مشكلة جديدة. يجب عليك دعم مستخدمين متعددين. يحتاج كل مستخدم إلى مفاتيح API الخاصة به ووصول آمن.
يفشل معظم المطورين هنا. إنهم يحاولون اتباع نهجين سيئين.
الأول هو الإعداد اليدوي. تطلب من المستخدمين استنساخ المستودع (repo)، وتثبيت التبعيات (dependencies)، وإعداد مفاتيح البيئة المحلية. يستغرق هذا ساعات، وسيتوقف معظم المستخدمين قبل أن ينتهوا.
الثاني هو كابوس الـ serverless. تقوم بالنشر على Cloud Run أو Vercel. ولأن منصات الـ serverless لا تخزن الجلسات (sessions)، فإن كل طلب يصل إلى مثيل (instance) جديد. يقع مستخدموك في حلقة مفرغة؛ يقومون بالمصادقة، ثم تطلب منهم النقرة التالية المصادقة مرة أخرى. هذا ليس منتجاً، بل هو نموذج أولي معطل.
لقد حللنا هذه المشكلة في BrainGrid. انتقلنا من أداة محلية إلى بنية تحتية جاهزة للإنتاج. إليكم كيف فعلنا ذلك.
- استخدم مخزن جلسات Redis: تنتهي مثيلات الـ serverless وتُعاد تشغيلها. لا يمكنك تخزين الجلسات في الذاكرة. استخدم Redis للحفاظ على بيانات الجلسة حية عبر جميع المثيلات.
- تنفيذ التخزين المؤقت متعدد المستويات (Multi-Tier Caching): تحقق من الذاكرة المحلية أولاً. إذا لم تكن موجودة، تحقق من Redis. هذا يمنع عملية التحقق المكلفة من JWT في كل طلب.
- تشفير البيانات الحساسة: استخدم AES-256-GCM لتشفير بيانات الجلسة قبل وضعها في Redis. هذا يحافظ على أمان معلومات المستخدم.
- استخدام أنماط OAuth الصحيحة: تتوقع عملاء MCP تدفقات اكتشاف (discovery flows) محددة. يجب عليك تنسيق رؤوس WWW-Authenticate بشكل صحيح لتجنب الأخطاء.
- التحسين من أجل السرعة: تزيد عملية التحقق من JWT من زمن الاستجابة (latency). من خلال تخزين الجلسات التي تم التحقق منها مؤقتاً، قمنا بتقليل أوقات الاستجابة بشكل كبير.
النتيجة هي نظام يتوسع من مستخدم واحد إلى ألف مستخدم. تكلفة تشغيله ضئيلة جداً ويتكامل مع مزودين مثل WorkOS أو Auth0.
توقف عن بناء أدوات لنفسك. ابدأ في بناء بنية تحتية لعملائك.