Bir yapay zeka istemcisi MCP sunucusuna bağlandığında kendini bir şekilde tanıtması gerekir. İki yaygın şablon vardır: bir basit Bearer anahtarı veya tam bir OAuth 2.1 akışı. Bu makale, bu ikisinin pratik farkını açıklar ve hangisinin ne zaman daha uygun olduğunu anlatır.
Basit Bearer anahtarı nedir?
یک رشته‌ی طولانی که در هدر Authorization: Bearer <کلید> فرستاده می‌شود. ساخت آن یک کلیک است، تنظیمش در کلاینت هم همین‌قدر ساده — کپی و پیست. مناسب کلاینت‌های دسکتاپ و CLI (Claude Code، Cursor، ابزارهای اتوماسیون مثل n8n) که کاربر مستقیم کنترلشان را دارد و یک کلید در فایل تنظیمات محلی نگه می‌دارد.
OAuth 2.1 ne ekler?
İstemcinin kendisi birden fazla kullanıcıya sahip bir uygulama olduğunda (kişisel bir araç değil), sabit anahtar sorun yaratır — her isteğin arkasında gerçekte kimin olduğunu bilemezsiniz ve herkese ait anahtarı iptal etmeden tek bir kullanıcının erişimini iptal edemezsiniz. OAuth bunu bir etkileşimli onay akışı ile çözer: kullanıcı bir kez sunucunun onay sayfasını görür, izin verir ve sunucu aynı kullanıcı için ayrı bir oturum oluşturur.
PKCE nedir ve neden zorunludur?
PKCE (Proof Key for Code Exchange), OAuth akışının ortasında «yetkilendirme kodu» çalınmasını engeller — istemci başlamadan önce rastgele bir sır oluşturur ve yalnızca karma değerini gönderir; sonunda asıl sırrın kendisini ibraz etmesi gerekir. PKCE olmadan, yetkilendirme kodu aktarım sırasında açığa çıkarsa (örneğin güvensiz bir yönlendirme aracılığıyla) saldırgan bunu kendi adına tokena dönüştürebilir. Güncel öneri, basit plain sürümünü değil yalnızca S256 sürümünü kabul etmektir.
Çok kiracılı hizmette Resource Indicator (RFC 8707) neden önemlidir?
Birden fazla çalışma alanına sahip bir bulut hizmetinde, bir OAuth token'ı «hangi kiracıya ait olduğunu» kendi içinde taşımıyorsa, bir çalışma alanı için geçerli olan token başka bir çalışma alanında da kabul edilebilir. İstekteki resource özelliği tam olarak bunu önler: token yalnızca istek anında belirlenen hedef için geçerlidir.
Özet: Hangisini seçmeliyim?
Kişisel kullanım veya CLI/masaüstü istemcili küçük bir ekip için basit bir Bearer anahtarı yeterli ve daha hızlıdır. Kendi içinde birden fazla kullanıcısı olan veya tek kişilik erişim iptali gereken bir istemci için OAuth 2.1 doğru seçimdir. Abrak MCP sunucusu ikisini de aynı anda destekler — her birini etkinleştirme ayrıntıları Bağlantı eğitimi yer almaktadır.
ماتریس انتخاب: کدام روش برای کدام موقعیت
| موقعیت | روش پیشنهادی | دلیل |
|---|---|---|
| اسکریپت داخلی روی سرور خودتان | کلید Bearer | کاربر نهایی وجود ندارد که هویتش لازم باشد |
| کلاینت دسکتاپ کاربر | OAuth 2.1 + PKCE | کلید نباید روی دستگاه کاربر ذخیره شود |
| سرویس چندمستأجره | OAuth با Resource Indicator | توکن باید فقط برای یک مستأجر معتبر باشد |
| یکپارچه‌سازی ماشین‌به‌ماشین ثابت | کلید Bearer با چرخش دوره‌ای | سادگی، با پذیرش مسئولیت نگهداری کلید |
| دسترسی موقت به پیمانکار | OAuth با انقضای کوتاه | ابطال بدون تغییر کلید بقیه |
چرخهٔ عمر کلید؛ بخشی که معمولاً فراموش می‌شود
- تولید: هر کلاینت کلید خودش را بگیرد. کلید مشترک یعنی ابطال یکی، قطع همه.
- محدودسازی: دامنهٔ دسترسی، سقف نرخ و فهرست ابزارهای مجاز روی همان کلید تعریف شود.
- چرخش: تاریخ انقضا از ابتدا ست شود؛ کلید بی‌انقضا دیر یا زود جایی لو می‌رود.
- ابطال: مسیر ابطال فوری باید از قبل تست شده باشد، نه در لحظهٔ حادثه.
- پایش: استفادهٔ غیرعادی (ساعت، حجم، ابزار غیرمنتظره) هشدار بدهد.
یک اشتباه رایج
گذاشتن کلید در URL — چه به‌عنوان پارامتر کوئری، چه داخل مسیر. کلید در URL در لاگ سرور، تاریخچهٔ مرورگر و هدر Referer ذخیره می‌شود و عملاً دیگر محرمانه نیست. کلید فقط در هدر Authorization جای دارد.
مدل تهدید کامل در MCP چقدر امن است، چک‌لیست عملیاتی در امنیت کلیدهای MCP و جداسازی مستأجرها در انزوای داده.
