وقتی یک کلاینت هوش مصنوعی به سرور 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 ابرک هر دو را همزمان پشتیبانی میکند — جزئیات فعالسازی هرکدام در آموزش اتصال آمده است.
