‏وقتی MCP می‌ره رو ابر: نقش OAuth و PKCE

نویسنده تو ادامهٔ پست قبلیش دربارهٔ MCP (پروتکلی که ابزارها رو به مدل‌های زبانی وصل می‌کنه)، این‌بار سراغ نسخهٔ ابری این پروتکل رفته. به گفتهٔ نویسنده، وقتی سرور MCP دیگه یه پردازهٔ لوکال رو لپ‌تاپ نیست، بلکه یه سرویس ابریه که خیلی‌ها ازش استفاده می‌کنن (مثلاً یه سرور MCP برای گیت‌هاب یا لینیر)، باید مثل هر API دیگه‌ای احراز هویت و کنترل دسترسی داشته باشه.

مشخصات MCP دو تا transport تعریف کرده: stdio (همون نسخهٔ لوکال که با پایپ‌های سیستم‌عامل کار می‌کنه) و streamable HTTP برای نسخهٔ ریموت. تو حالت ریموت، هر درخواست یه POST معموله، و برای پاسخ‌های طولانی (مثل نمایش پیشرفت یه کار)، سرور از Server-Sent Events استفاده می‌کنه، نه وب‌سوکت. نویسنده تاکید می‌کنه این فقط تغییر لولهٔ انتقاله، نه پروتکل؛ متدها و اسکیمای ابزارها هیچ فرقی نمی‌کنن.

برای احراز هویت، هر درخواست یه هدر Authorization: Bearer با یه توکن حمل می‌کنه، و اون توکن از یه چرخهٔ OAuth 2.1 با PKCE به دست میاد. کلاینت اول یه رشتهٔ تصادفی به اسم code_verifier می‌سازه، هش SHA256ش رو به اسم code_challenge می‌فرسته، بعد کاربر تو مرورگر اجازه می‌ده، و سرور یه کد کوتاه‌عمر برمی‌گردونه. کلاینت اون کد رو همراه code_verifier اصلی به سرور می‌ده تا توکن نهایی صادر بشه؛ اگه کد وسط راه دزدیده بشه، بدون داشتن verifier اصلی هیچ فایده‌ای نداره:

code_verifier  = random_urlsafe(64)
code_challenge = BASE64URL(SHA256(code_verifier))

نویسنده به این نکته اشاره می‌کنه که این مدل، مرز اعتماد رو کامل عوض کرده: تو نسخهٔ لوکال مرز امنیتی همون پردازه بود، ولی تو نسخهٔ ریموت این توکنه که دقیقاً مشخص می‌کنه کلاینت به کدوم ابزارها دسترسی داره. اگه یه ابزار (مثلاً حذف رپازیتوری) تو دامنهٔ توکن نباشه، اصلاً تو لیست ابزارهایی که مدل می‌بینه ظاهر نمی‌شه؛ از دید مدل، اون ابزار اصلاً وجود نداره. همین باعث می‌شه تیم امنیت بتونه یه توکن رو یه‌جا لغو کنه و همهٔ کلاینت‌هایی که ازش استفاده می‌کردن رو قطع کنه.

نویسنده چند تا برداشت غلط رایج رو هم رد می‌کنه: OAuth سنگین به نظر می‌رسه ولی فقط پنج تا درخواست HTTP یه‌بار مصرفه؛ کلید API برای یه کاربر خوبه ولی به محض اضافه شدن کاربر دوم از کار می‌افته چون مقیاس‌پذیر و قابل لغو نیست؛ و از همه مهم‌تر، خود مدل هیچ‌وقت توکن رو نمی‌بینه یا مدیریت نمی‌کنه - این کار همیشه با هاست (مثل Claude Code) ئه، که برای امنیت لازمه.

به گفتهٔ نویسنده، MCP ریموت لزوماً به معنی اجرای ابزار تو ابر نیست، بلکه فقط یعنی سرور از راه دور با MCP صحبت می‌کنه؛ پشت اون سرور می‌تونه یه ایجنت لوکال یا هر جای دیگه‌ای کار رو انجام بده.

نکات کلیدی:

• نسخهٔ ریموت MCP از streamable HTTP استفاده می‌کنه: POST برای درخواست‌های معمولی و SSE برای پاسخ‌های طولانی
• احراز هویت با OAuth 2.1 و PKCE انجام می‌شه؛ هر درخواست یه هدر Authorization: Bearer داره
• PKCE با یه جفت code_verifier/code_challenge جلوی سوءاستفاده از کد دزدیده‌شده رو می‌گیره
• سرور لیست ابزارها رو بر اساس دامنهٔ (scope) توکن فیلتر می‌کنه؛ ابزارهای خارج از دامنه اصلاً دیده نمی‌شن
• کلید API فقط برای تک‌کاربره جواب می‌ده؛ به محض اضافه شدن کاربر دوم OAuth انتخاب درسته