وقتی یک کلاینت هوش مصنوعی به سرور 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، اگر کد مجوز در مسیر افشا شود (مثلاً از طریق یک redirect ناامن)، مهاجم می‌تواند آن را برای خودش تبدیل به توکن کند. توصیه‌ی فعلی این است که فقط نسخه‌ی S256 پذیرفته شود، نه نسخه‌ی ساده‌ی plain.
Resource Indicator (RFC 8707) روی سرویس چندمستأجره چرا مهم است؟
روی یک سرویس ابری با چند فضای کاری، اگر توکن OAuth «مخصوص کدام مستأجر» را در خودش حمل نکند، یک توکن معتبر برای یک فضای کاری ممکن است روی فضای کاری دیگر هم پذیرفته شود. مشخصه‌ی resource در درخواست دقیقاً همین را می‌بندد: توکن فقط برای همان مقصدی که در لحظه‌ی درخواست تعیین شده معتبر است.
جمع‌بندی: کدام را انتخاب کنم؟
برای استفاده‌ی شخصی یا تیمی کوچک با کلاینت CLI/دسکتاپ، کلید Bearer ساده کافی و سریع‌تر است. برای کلاینتی که خودش چند کاربر دارد یا نیاز به لغو دسترسی تک‌نفره دارید، OAuth 2.1 گزینه‌ی درست است. سرور MCP ابرک هر دو را همزمان پشتیبانی می‌کند — جزئیات فعال‌سازی هرکدام در آموزش اتصال آمده است.
ماتریس انتخاب: کدام روش برای کدام موقعیت
| موقعیت | روش پیشنهادی | دلیل |
|---|---|---|
| اسکریپت داخلی روی سرور خودتان | کلید Bearer | کاربر نهایی وجود ندارد که هویتش لازم باشد |
| کلاینت دسکتاپ کاربر | OAuth 2.1 + PKCE | کلید نباید روی دستگاه کاربر ذخیره شود |
| سرویس چندمستأجره | OAuth با Resource Indicator | توکن باید فقط برای یک مستأجر معتبر باشد |
| یکپارچه‌سازی ماشین‌به‌ماشین ثابت | کلید Bearer با چرخش دوره‌ای | سادگی، با پذیرش مسئولیت نگهداری کلید |
| دسترسی موقت به پیمانکار | OAuth با انقضای کوتاه | ابطال بدون تغییر کلید بقیه |
چرخهٔ عمر کلید؛ بخشی که معمولاً فراموش می‌شود
- تولید: هر کلاینت کلید خودش را بگیرد. کلید مشترک یعنی ابطال یکی، قطع همه.
- محدودسازی: دامنهٔ دسترسی، سقف نرخ و فهرست ابزارهای مجاز روی همان کلید تعریف شود.
- چرخش: تاریخ انقضا از ابتدا ست شود؛ کلید بی‌انقضا دیر یا زود جایی لو می‌رود.
- ابطال: مسیر ابطال فوری باید از قبل تست شده باشد، نه در لحظهٔ حادثه.
- پایش: استفادهٔ غیرعادی (ساعت، حجم، ابزار غیرمنتظره) هشدار بدهد.
یک اشتباه رایج
گذاشتن کلید در URL — چه به‌عنوان پارامتر کوئری، چه داخل مسیر. کلید در URL در لاگ سرور، تاریخچهٔ مرورگر و هدر Referer ذخیره می‌شود و عملاً دیگر محرمانه نیست. کلید فقط در هدر Authorization جای دارد.
مدل تهدید کامل در MCP چقدر امن است، چک‌لیست عملیاتی در امنیت کلیدهای MCP و جداسازی مستأجرها در انزوای داده.
