احراز هویت MCP در سال ۲۰۲۶

پروتکل بافت مدل (MCP) نحوه تعامل عامل‌ها (agents) با سرورها را تغییر داد. این مسیر با ابزارهای محلی مانند ماشین‌حساب‌ها شروع شد و اکنون روی سرورهای از راه دور اجرا می‌شود. این تغییر، احراز هویت را به یک ضرورت تبدیل کرده است.

اگر می‌خواهید OAuth را به سرور MCP خود اضافه کنید، باید خود را برای یک هدف متغیر آماده کنید. مشخصات فنی (spec) هر چند ماه یک بار تغییر می‌کند. عامل‌های مختلف از نسخه‌های متفاوتی از قوانین استفاده می‌کنند.

در اینجا وضعیت فعلی احراز هویت MCP آمده است.

تغییر اصلی

سرور MCP شما یک سرور مجوزدهی (authorization server) نیست؛ بلکه یک سرور منابع (resource server) است.

در گذشته، مشخصات فنی سرورها را مجبور می‌کرد تا توکن‌ها و ورودها را مدیریت کنند. این امر باعث سنگین شدن سرورها و دشواری در مقیاس‌پذیری می‌شد. کارشناسانی مانند Aaron Parecki و Christian Posta به این موضوع اشاره کردند و استدلال کردند که سرورهای MCP فقط باید توکن‌ها را اعتبارسنجی کنند.

امروزه، استاندارد از این جریان پیروی می‌کند:

• یک درخواست احراز هویت نشده، خطای 401 دریافت می‌کند. • خطا به کلاینت می‌گوید که متادیتای منابع را کجا پیدا کند. • کلاینت سرور مجوزدهی صحیح (مانند Okta یا Keycloak) را پیدا می‌کند. • کلاینت یک توکن دریافت کرده و آن را به سرور MCP شما ارائه می‌دهد. • سرور شما توکن را اعتبارسنجی کرده و ابزار را اجرا می‌کند.

مشکل پراکندگی

با وجود وجود یک استاندارد، هر عامل آن را به شکلی متفاوت پیاده‌سازی می‌کند.

• Claude Desktop: جریان کامل OAuth را اجرا می‌کند. • Claude API: از شما می‌خواهد که bearer token خود را ارسال کنید. • ChatGPT: از CIMD برای ثبت‌نام استفاده می‌کند و از آخرین مشخصات فنی پشتیبانی می‌کند. • Gemini: از Google Cloud IAM و API keys استفاده می‌کند. • VS Code: از ارائه‌دهندگان GitHub و Entra پشتیبانی می‌کند.

این بدان معناست که سروری که برای یک عامل ساخته شده، ممکن است در عامل دیگری با شکست مواجه شود. یک فروشنده ممکن است جریان کامل ورود را الزامی کند، در حالی که دیگری انتظار دارد خودتان توکن را مدیریت کنید.

سه درس برای توسعه‌دهندگان

۱. مدل Resource Server را هدف قرار دهید. سعی نکنید به یک ارائه‌دهنده هویت (identity provider) تبدیل شوید. از RFC 9728 برای ارائه متادیتا و اعتبارسنجی audience استفاده کنید.

۲. از هر دو جهان پشتیبانی کنید. سرور خود را به گونه‌ای بسازید که هم فراخوانی‌های API با مدل "bring your own token" و هم جریان‌های کامل OAuth را مدیریت کند.

۳. انتظار به‌روزرسانی‌های مداوم را داشته باشید. مشخصات فنی همچنان در حال تکامل است. OAuth 2.1 هنوز در مرحله پیش‌نویس است و پروتکل MCP هنوز در حال تثبیت جایگاه خود است.

ساخت سرورهای MCP در حال حاضر دشوار است. قوانین به سرعت تغییر می‌کنند. اگر منعطف بمانید و به مدل resource server پایبند باشید، از این تغییرات جان سالم به در خواهید برد.

Source: https://dev.to/0ndreu/mcp-authentication-in-2026-how-oauth-flipped-the-servers-role-and-why-every-agent-differs-11fm

Optional learning community: https://t.me/GyaanSetuAi