2026 میں MCP Authentication

Model Context Protocol (MCP) نے ایجنٹس کے سرورز سے بات کرنے کے طریقے کو بدل دیا ہے۔ اس کا آغاز کیلکولیٹرز جیسے مقامی ٹولز سے ہوا تھا۔ اب یہ ریموٹ سرورز پر چلتا ہے۔ اس تبدیلی نے authentication کو ایک ضرورت بنا دیا ہے۔

اگر آپ اپنے MCP سرور میں OAuth شامل کرنا چاہتے ہیں، تو ایک بدلتے ہوئے ہدف کے لیے تیار رہیں۔ اس کا spec ہر چند ماہ بعد بدل جاتا ہے۔ مختلف ایجنٹس قوانین کے مختلف ورژن استعمال کرتے ہیں۔

MCP authentication کی موجودہ صورتحال یہ ہے:

بنیادی تبدیلی

آپ کا MCP سرور ایک authorization server نہیں ہے۔ یہ ایک resource server ہے۔

ماضی میں، spec سرورز کو tokens اور logins سنبھالنے پر مجبور کرتا تھا۔ اس سے سرورز بھاری ہو جاتے تھے اور انہیں scale کرنا مشکل ہو جاتا تھا۔ Aaron Parecki اور Christian Posta جیسے ماہرین نے اس کی نشاندہی کی۔ ان کا استدلال تھا کہ MCP سرورز کو صرف tokens کو validate کرنا چاہیے۔

آج، معیار (standard) اس بہاؤ (flow) پر عمل کرتا ہے:

• ایک غیر تصدیق شدہ (unauthenticated) درخواست کو 401 error ملتا ہے۔ • ایرر کلائنٹ کو بتاتا ہے کہ resource metadata کہاں سے حاصل کرنا ہے۔ • کلائنٹ صحیح authorization server (جیسے Okta یا Keycloak) تلاش کرتا ہے۔ • کلائنٹ ایک token حاصل کرتا ہے اور اسے آپ کے MCP سرور کو پیش کرتا ہے۔ • آپ کا سرور token کو validate کرتا ہے اور ٹول چلا دیتا ہے۔

تقسیم (Fragmentation) کا مسئلہ

اگرچہ ایک معیار موجود ہے، لیکن ہر ایجنٹ اسے مختلف طریقے سے نافذ (implement) کرتا ہے۔

• Claude Desktop: مکمل OAuth flow چلاتا ہے۔ • Claude API: آپ سے اپنا bearer token پاس کرنے کا تقاضا کرتا ہے۔ • ChatGPT: رجسٹریشن کے لیے CIMD استعمال کرتا ہے اور تازہ ترین spec کو سپورٹ کرتا ہے۔ • Gemini: Google Cloud IAM اور API keys استعمال کرتا ہے۔ • VS Code: GitHub اور Entra providers کو سپورٹ کرتا ہے۔

اس کا مطلب ہے کہ ایک ایجنٹ کے لیے بنایا گیا سرور دوسرے پر ناکام ہو سکتا ہے۔ ایک وینڈر مکمل login flow کا تقاضا کر سکتا ہے، جبکہ دوسرا آپ سے خود token مینیج کرنے کی توقع رکھتا ہے۔

ڈویلپرز کے لیے تین اسباق

  1. Resource Server ماڈل کو ہدف بنائیں۔ identity provider بننے کی کوشش نہ کریں۔ metadata فراہم کرنے اور audience کو validate کرنے کے لیے RFC 9728 استعمال کریں۔

  2. دو دنیاؤں کو سپورٹ کریں۔ اپنے سرور کو اس طرح بنائیں کہ وہ "bring your own token" API کالز اور مکمل OAuth flows دونوں کو سنبھال سکے۔

  3. مسلسل اپ ڈیٹس کی توقع رکھیں۔ spec ابھی بھی ارتقاء پذیر ہے۔ OAuth 2.1 ابھی بھی ایک ڈرافٹ ہے، اور MCP پروٹوکول ابھی اپنی جگہ بنا رہا ہے۔

اس وقت MCP سرورز بنانا مشکل ہے۔ قوانین تیزی سے بدلتے ہیں۔ اگر آپ لچکدار رہیں گے اور resource server ماڈل پر قائم رہیں گے، تو آپ ان تبدیلیوں کا مقابلہ کر سکیں گے۔

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

اختیاری لرننگ کمیونٹی: https://t.me/GyaanSetuAi