عندما يتصل عميل ذكاء اصطناعي بخادم MCP، عليه أن يعرّف بنفسه بطريقة ما. هناك نمطان شائعان: مفتاح Bearer بسيط أو تدفّق OAuth 2.1 كامل. توضّح هذه المقالة الفرق العملي بينهما ومتى يكون كلٌّ منهما أنسب.
ما هو مفتاح Bearer البسيط؟
یک رشته‌ی طولانی که در هدر Authorization: Bearer <کلید> فرستاده می‌شود. ساخت آن یک کلیک است، تنظیمش در کلاینت هم همین‌قدر ساده — کپی و پیست. مناسب کلاینت‌های دسکتاپ و CLI (Claude Code، Cursor، ابزارهای اتوماسیون مثل n8n) که کاربر مستقیم کنترلشان را دارد و یک کلید در فایل تنظیمات محلی نگه می‌دارد.
ماذا يضيف OAuth 2.1؟
عندما يكون العميل نفسه تطبيقًا يستخدمه مستخدمون كثر (لا أداة شخصية)، يصبح المفتاح الثابت مشكلة — فلا تعرف من يقف فعلًا وراء كل طلب، ولا يمكنك إلغاء وصول مستخدم واحد دون إلغاء مفتاح الجميع. ويحل OAuth هذا بـتدفّق موافقة تفاعلي: يرى المستخدم صفحة موافقة الخادم مرة واحدة ويمنح الإذن، فيُصدر الخادم جلسة مستقلة لهذا المستخدم.
ما هو PKCE ولماذا هو إلزامي؟
يمنع PKCE (Proof Key for Code Exchange) سرقة «كود التفويض» في منتصف تدفق OAuth — ينشئ العميل رمزاً عشوائياً قبل البدء ويرسل تجزئته فقط؛ وفي النهاية يجب أن يُظهر الرمز الأصلي نفسه. بدون PKCE، إذا تسرّب كود التفويض في المسار (مثلاً عبر إعادة توجيه غير آمنة)، يمكن للمهاجم تحويله إلى رمز لنفسه. التوصية الحالية هي قبول نسخة S256 فقط، لا النسخة البسيطة plain.
لماذا يهم Resource Indicator (RFC 8707) في خدمة متعددة المستأجرين؟
في خدمة سحابية متعددة مساحات العمل، إن لم يحمل رمز OAuth المعلومة «خاص بأي مستأجر» فقد يُقبل رمز صالح لمساحة عمل واحدة في مساحة عمل أخرى أيضًا. وهذا بالضبط ما تسدّه المعاملة resource في الطلب: الرمز صالح فقط للوجهة المحددة لحظة الطلب.
الخلاصة: أيهما أختار؟
للاستخدام الشخصي أو فريق صغير مع عميل CLI/سطح مكتب، مفتاح Bearer بسيط كافٍ وأسرع. أما العميل الذي يضم عدة مستخدمين أو تحتاجون فيه لإلغاء وصول مستخدم واحد، فإن OAuth 2.1 هو الخيار الصحيح. خادم MCP في Abrak يدعم الاثنين معاً — تفاصيل تفعيل كل منهما في دليل الاتصال وارد.
ماتریس انتخاب: کدام روش برای کدام موقعیت
| موقعیت | روش پیشنهادی | دلیل |
|---|---|---|
| اسکریپت داخلی روی سرور خودتان | کلید Bearer | کاربر نهایی وجود ندارد که هویتش لازم باشد |
| کلاینت دسکتاپ کاربر | OAuth 2.1 + PKCE | کلید نباید روی دستگاه کاربر ذخیره شود |
| سرویس چندمستأجره | OAuth با Resource Indicator | توکن باید فقط برای یک مستأجر معتبر باشد |
| یکپارچه‌سازی ماشین‌به‌ماشین ثابت | کلید Bearer با چرخش دوره‌ای | سادگی، با پذیرش مسئولیت نگهداری کلید |
| دسترسی موقت به پیمانکار | OAuth با انقضای کوتاه | ابطال بدون تغییر کلید بقیه |
چرخهٔ عمر کلید؛ بخشی که معمولاً فراموش می‌شود
- تولید: هر کلاینت کلید خودش را بگیرد. کلید مشترک یعنی ابطال یکی، قطع همه.
- محدودسازی: دامنهٔ دسترسی، سقف نرخ و فهرست ابزارهای مجاز روی همان کلید تعریف شود.
- چرخش: تاریخ انقضا از ابتدا ست شود؛ کلید بی‌انقضا دیر یا زود جایی لو می‌رود.
- ابطال: مسیر ابطال فوری باید از قبل تست شده باشد، نه در لحظهٔ حادثه.
- پایش: استفادهٔ غیرعادی (ساعت، حجم، ابزار غیرمنتظره) هشدار بدهد.
یک اشتباه رایج
گذاشتن کلید در URL — چه به‌عنوان پارامتر کوئری، چه داخل مسیر. کلید در URL در لاگ سرور، تاریخچهٔ مرورگر و هدر Referer ذخیره می‌شود و عملاً دیگر محرمانه نیست. کلید فقط در هدر Authorization جای دارد.
مدل تهدید کامل در MCP چقدر امن است، چک‌لیست عملیاتی در امنیت کلیدهای MCP و جداسازی مستأجرها در انزوای داده.
