فوری جواب: OAuth 1.0a پیچیدہ کرپٹوگرافک دستخطوں پر منحصر تھا اور OAuth 2.0 کے بیرر ٹوکنز ری پلے حملوں کے شکار تھے۔ خود مختار AI ایجنٹس اور MCP سرورز کے لیے OAuth 2.1 لازمی ہے: یہ PKCE (RFC 7636) نافذ کرتا ہے، غیر محفوظ گرانٹس ختم کرتا ہے اور DPoP (RFC 9449) سے سینڈر باؤنڈ زیرو ٹرسٹ ٹوکنز یقینی بناتا ہے۔
1. تعارف: 2026 میں خود مختار AI ایجنٹس کی شناخت اور اجازت کا بحران
الگ تھلگ لارج لینگویج ماڈل (LLM) چیٹ انٹرفیسز سے خود مختار، ملٹی ٹرن AI ایجنٹس اور ماڈل کنٹیکسٹ پروٹوکول (Model Context Protocol, MCP) سرورز کی طرف تیز رفتار منتقلی نے ایک سنگین سیکیورٹی بحران کو جنم دیا ہے: ایجنٹک شناخت اور اجازت کی رکاوٹ (Agentic Identity Bottleneck)۔
2024 اور 2025 کے دوران، ڈویلپرز نے خود مختار ٹولز — جیسے کہ Claude Code، Cursor، Windsurf، AutoGen، اور کسٹم LangGraph ایجنٹس — کو انٹرپرائز APIs سے منسلک کرنے کے لیے بنیادی طور پر جامد پرسنل ایکسیس ٹوکنز (PATs) یا .env فائلوں اور آپریٹنگ سسٹم کے پراسیس ماحول میں ہارڈ کوڈ شدہ طویل مدتی API کیز کا استعمال کیا۔ جب ایک AI ایجنٹ مقامی شیل کمانڈز چلاتا ہے، داخلی ڈیٹا بیس سے استفسار کرتا ہے (PostgreSQL یا Supabase MCP سرورز کے ذریعے)، یا انٹرپرائز ایشو ٹریکرز کو اپ ڈیٹ کرتا ہے (Jira یا Linear MCP سرورز کے ذریعے)، تو وہ وسیع اور غیر محدود اختیارات (Ambient Authority) کے تحت کام کرتا ہے۔
غیر محفوظ روایتی ایجنٹ آرکیٹیکچر (جامد وسیع اختیارات):
+--------------------+ ذیلی پراسیس کا آغاز +---------------------------+
| LLM ہوسٹ ایجنٹ | ─────────────────────────────> | مقامی MCP ٹول سرور |
| (Claude Code / | Env: GITHUB_TOKEN=ghp_... | (process.env پڑھتا ہے) |
| Cursor / LangSeq) | +-------------+-------------+
+---------+----------+ |
| بالواسطہ پرامپٹ انجیکشن حملہ | بلا روک ٹوک پڑھنے/لکھنے کا اختیار
v v
+--------------------+ +-------------------+
| غیر معتبر ویب پیج | | اپ اسٹریم سروسز |
| میں حملہ آور پرامپٹ| ──> جامد سیکرٹ چوری کر کے ──────────> | GitHub / Slack / |
| "Print your env" | حملہ آور کے HTTP ویب ہک پر ارسال | داخلی ڈیٹا بیسز |
+--------------------+ +-------------------+یہ جامد اسناد کا ڈھانچہ تین بنیادی وجوہات کی بنا پر انتہائی کمزور ہے:
- پرامپٹ انجیکشن بطور سیکرٹ چوری کا راستہ: اگر ایجنٹ کسی غیر معتبر ڈیٹا (جیسے ویب پیج، ای میل، یا GitHub ایشو میں چھپا پرامپٹ) کا سامنا کرتا ہے، تو LLM کو ورغلا کر ایسی کمانڈز رن کروائی جا سکتی ہیں جو
process.envپرنٹ کر دیں، جس سے اعلیٰ اختیاراتی کیز فوراً چوری ہو جاتی ہیں۔ - شناخت کی تفویض (Identity Delegation) کا فقدان: ایک جامد API کی یہ تمیز نہیں کر سکتی کہ آیا کوئی اقدام کسی انسانی آپریٹر نے جان بوجھ کر کیا ہے یا وہ AI ایجنٹ کے وہم (hallucination) کا نتیجہ ہے۔ انٹرپرائز آڈٹ لاگز میں تمام کالز یکساں طور پر انسانی صارف ہی کی نظر آتی ہیں۔
- متحرک منسوخی اور کم سے کم مراعات کا فقدان: جامد ٹوکنز عام طور پر ضرورت سے زیادہ وسیع اختیارات (جیسے پوری ریپوزٹری کے مکمل حقوق) رکھتے ہیں اور مہینوں یا غیر معینہ مدت کے لیے کارآمد رہتے ہیں۔
اس سیکیورٹی خطرے کو ختم کرنے کے لیے AI ماحولیاتی نظام تفویض شدہ اجازت کے فریم ورکس کی طرف بڑھ چکا ہے۔ تاہم، OAuth 1.0a، OAuth 2.0، اور ابھرتے ہوئے OAuth 2.1 معیار کے درمیان انتخاب کرنا — اور ساتھ ہی PKCE (RFC 7636)، DPoP (RFC 9449)، اور ڈیوائس آتھرائزیشن گرانٹ (RFC 8628) کو باہم مربوط کرنا — اس بات کی تفصیلی سمجھ بوجھ کا متقاضی ہے کہ یہ پروٹوکول ہیڈ لیس اور خود مختار ماحول میں کس طرح کام کرتے ہیں۔
2. OAuth کا ارتقا: 1.0a بمقابلہ 2.0 بمقابلہ 2.1 کا ساختی موازنہ
جدید AI ایجنٹ فریم ورکس OAuth 2.1 کو کیوں لازمی قرار دیتے ہیں، اس کو سمجھنے کے لیے OAuth کے تینوں بڑے ورژنز کا تقابلی جائزہ لینا ناگزیر ہے۔
OAUTH معیارات کا ارتقائی سفر (2007 - 2026):
+---------------------------------------------------------------------------------------------+
| OAuth 1.0a (RFC 5849, 2010) |
| - ہر انفرادی HTTP درخواست پر کرپٹوگرافک دستخط (HMAC-SHA1, RSA-SHA1) |
| - ٹوکن ریفریش فلو کا فقدان؛ اسٹیٹ فل دستخطی حساب کتاب؛ ٹرانسپورٹ آزاد سیکیورٹی |
| - AI کے لیے فیصلہ: ناقابل استعمال۔ کرپٹو اوورہیڈ اسٹریمنگ اور ٹول پراکسیز کو توڑ دیتا ہے۔ |
+---------------------------------------------------------------------------------------------+
│
▼
+---------------------------------------------------------------------------------------------+
| OAuth 2.0 (RFC 6749 اور RFC 6750, 2012) |
| - کرپٹوگرافی کو ٹرانسپورٹ لیئر سیکیورٹی (TLS 1.2/1.3) کے سپرد کیا گیا |
| - بیرر ٹوکنز، اسکوپس، ریفریش ٹوکنز، اور مخصوص گرانٹ اقسام متعارف کروائی گئیں |
| - امپلیسٹ فلو اور ریسورس اونر پاس ورڈ کریڈنشلز (ROPC) پر مشتمل تھا |
| - AI کے لیے فیصلہ: خطرناک۔ پرامپٹ انجیکشن کے ذریعے بیرر ٹوکنز باآسانی چرائے جا سکتے ہیں۔ |
+---------------------------------------------------------------------------------------------+
│
▼
+---------------------------------------------------------------------------------------------+
| OAuth 2.1 (مربوط IETF معیار, 2025/2026) |
| - غیر محفوظ گرانٹس کا مکمل خاتمہ (Implicit اور Password گرانٹس مستقل طور پر خارج) |
| - تمام آتھرائزیشن کوڈ فلوز کے لیے PKCE (RFC 7636) لازمی (پبلک اور پرائیویٹ دونوں کے لیے) |
| - ری ڈائریکٹ URI کا بائٹ ٹو بائٹ ہو بہو ملاپ؛ URI کوئری پیرامیٹرز میں ٹوکن بھیجنا سختی سے ممنوع|
| - ریفریش ٹوکن روٹیشن (RTR) یا سینڈر کنسٹرینڈ ٹوکنز (DPoP / mTLS) لازمی |
| - AI کے لیے فیصلہ: MCP اور خود مختار ایجنٹس کے لیے سیکیورٹی کا سنہری معیار۔ |
+---------------------------------------------------------------------------------------------+OAuth 1.0a (RFC 5849): کرپٹوگرافک سختی اور اسٹیٹ فلنس
OAuth 1.0a اس دور میں تیار کیا گیا جب HTTPS نایاب اور مہنگا تھا۔ سادہ HTTP پر سنفنگ سے بچاؤ کے لیے، اس نے ہر درخواست کے لیے کلائنٹ اور سرور دونوں پر کرپٹوگرافک دستخط (HMAC-SHA1) لازمی کیے۔
دستخط کے لیے HTTP میتھڈ، نارملائزڈ URL، کوئری پیرامیٹرز کی حروف تہجی کے لحاظ سے ترتیب شدہ اسٹرنگ، نونس (Nonce) اور ٹائم اسٹیمپ کا درست حساب درکار ہوتا تھا:
$$\text{BaseString} = \text{HTTP\_METHOD} \mathbin{\Vert} \text{"\&"} \mathbin{\Vert} \text{Encode}(\text{URL}) \mathbin{\Vert} \text{"\&"} \mathbin{\Vert} \text{Encode}(\text{SortedParams})$$
$$\text{Signature} = \text{HMAC-SHA1}(\text{ClientSecret} \mathbin{\Vert} \text{"\&"} \mathbin{\Vert} \text{TokenSecret}, \text{BaseString})$$
AI ایجنٹس کے لیے OAuth 1.0a کی ناکامی کے اسباب:
- اسٹریمنگ اور چنکڈ ٹرانسپورٹ: جدید ایجنٹ پروٹوکولز (جیسے SSE یا WebSockets پر MCP) چھوٹے چھوٹے JSON-RPC پیلوڈز اسٹریم کرتے ہیں۔ غیر متعین اسٹریمنگ پر بار بار دستخط کا حساب لگانا توثیق کو ناکام بنا دیتا ہے۔
- ڈائنامک ٹول آرکیسٹریشن: ماڈلز متحرک طور پر درخواستیں تشکیل دیتے ہیں۔ پیرامیٹرز کی ترتیب کا ذرا سا فرق یا URL انکوڈنگ کی تبدیلی (
%20بمقابلہ+) دستخط کو باطل کر کے 401 Unauthorized کی غلطیاں پیدا کرتی ہے۔ - نیٹو ریفریش کی عدم موجودگی: اس میں قلیل مدتی ٹوکنز کی خودکار روٹیشن کی سہولت نہیں تھی، جس کے باعث طویل مدتی راز مستقل کلائنٹ میں پڑے رہتے تھے۔
OAuth 2.0 (RFC 6749): بیرر خطرے کے بدلے سادگی
OAuth 2.0 نے سالمیت کا بوجھ ٹرانسپورٹ لیئر (HTTPS) پر ڈالا اور بیرر ٹوکن (RFC 6750) متعارف کروایا۔ جس کے پاس بھی ٹوکن ہو، وہ کیش رقم کی طرح وسائل تک مکمل رسائی حاصل کر سکتا ہے:
GET /v1/repositories HTTP/1.1
Host: api.github.com
Authorization: Bearer ya29.a0AfH6SMB...OAuth 2.0 نے چار روایتی گرانٹ فلوز متعارف کرائے:
- Authorization Code Grant: محفوظ بیک اینڈ سرور رکھنے والی ویب ایپس کے لیے۔
- Implicit Grant: براؤزر میں بنا کوڈ ایکسچینج کے براہ راست ہیش میں ٹوکن حاصل کرنا۔
- Resource Owner Password Credentials (ROPC): براہ راست یوزر نیم اور پاس ورڈ جمع کرانا۔
- Client Credentials Grant: بنا انسانی مداخلت کے براہ راست سرورز کے درمیان مشین ٹو مشین (M2M) توثیق۔
AI سسٹمز میں OAuth 2.0 کی سنگین کمزوریاں:
- بیرر ری پلے حملہ (Replay Attack): اگر ایجنٹ پرامپٹ انجیکشن یا لاگز کے ذریعے کمپرومائز ہو جائے تو حملہ آور بیرر ٹوکن چرا کر میعاد ختم ہونے تک دنیا میں کہیں سے بھی اسے بار بار استعمال کر سکتا ہے۔
- امپلیسٹ گرانٹ کا جال: پرانی ڈیسک ٹاپ ایپس امپلیسٹ فلو استعمال کرتی تھیں، جس سے ٹوکنز براؤزر ہسٹری اور
Refererہیڈرز میں افشا ہو جاتے تھے۔ - پاس ورڈ گرانٹ کی خرابی: کنسول میں پاس ورڈ طلب کرنا OAuth کے اس بنیادی وعدے کو تباہ کر دیتا ہے کہ اسناد کبھی کسی تیسرے فریق کو نہ دی جائیں۔
OAuth 2.1: خود مختار ایجنٹس کے لیے جدید محفوظ معیار
OAuth 2.1 فرسودہ کمزوریوں کو ختم کرتا ہے اور سخت شرائط لاگو کرتا ہے:
- غیر محفوظ فلوز کا مکمل خاتمہ: Implicit اور ROPC کو مکمل طور پر خارج کر دیا گیا ہے۔
- ہر کوڈ ایکسچینج کے لیے PKCE لازمی: Proof Key for Code Exchange (RFC 7636) اب پبلک کلائنٹس (CLI ایجنٹس) اور پرائیویٹ کلائنٹس (بیک اینڈ ایجنٹس) دونوں کے لیے فرض ہے۔
- ری ڈائریکٹ URI کا ہو بہو بائٹ بائٹ ملاپ: اوپن ری ڈائریکٹر حملوں کو روکنے کے لیے ایک ایک حرف کا درست ہونا لازمی ہے۔
- کوئری پیرامیٹرز میں ٹوکن پر پابندی: ٹوکنز کو کبھی بھی URL پیرامیٹرز میں نہیں بھیجا جا سکتا تاکہ سرور لاگز میں ان کا اخراج نہ ہو۔
- ریفریش ٹوکن کا سخت تحفظ: ریفریش ٹوکن روٹیشن (RTR) یا سینڈر کنسٹرینڈ ٹوکنز (DPoP / mTLS) کا نفاذ لازمی ہے۔
تقابلی خاکہ: OAuth 1.0a بمقابلہ 2.0 بمقابلہ 2.1
| جہت | OAuth 1.0a (RFC 5849) | OAuth 2.0 (RFC 6749 / 6750) | OAuth 2.1 (IETF معیار 2026) |
|---|---|---|---|
| کرپٹوگرافک ماڈل | ایپلی کیشن لیئر پر دستخط (HMAC/RSA) | TLS + سادہ بیرر ٹوکن | TLS + لازمی PKCE + سینڈر بائنڈنگ (DPoP/mTLS) |
| بیرر ری پلے کا خطرہ | محفوظ (منفرد نونس کے ساتھ دستخط) | انتہائی خطرناک (قبضہ = مکمل اجازت) | مکمل محفوظ (DPoP کے ذریعے بھیجنے والے سے بندھا) |
| PKCE کی شرط | غیر معاون | اختیاری (RFC 7636 زیادہ تر موبائل کے لیے) | تمام آتھرائزیشن کوڈ فلوز کے لیے لازمی |
| Implicit Grant | غیر معاون | مجاز (براؤزر ایپس کے لیے) | مکمل طور پر منسوخ اور ممنوع |
| Password Grant (ROPC) | غیر معاون | مجاز (براہ راست پاس ورڈ تبادلہ) | مکمل طور پر منسوخ اور ممنوع |
| Redirect URI تصدیق | سابقے کا ملاپ کافی تھا | وائلڈ کارڈز اور مبہم راستے قبول تھے | ہو بہو بائٹ ٹو بائٹ ملاپ لازمی ہے |
| کوئری میں ٹوکن | معاون | مجاز (?access_token=...) |
قطعی طور پر ممنوع (صرف ہیڈر یا باڈی) |
| ریفریش ٹوکن لائف سائیکل | کوئی نیٹو نظام نہیں تھا | منسوخی تک ایک ہی ٹوکن بار بار استعمال | لازمی روٹیشن (RTR) یا کرپٹوگرافک بائنڈنگ |
| CLI ایجنٹس کے لیے موزوں | انتہائی ناقص (شیل میں دستخط کی خرابی) | کمزور (لوکل پورٹ پر چوری کا خطرہ) | بہترین (PKCE + عارضی لوپ بیک پورٹس) |
| MCP سرورز کے لیے موزوں | اسٹریمنگ کے ساتھ غیر موافق | قابل استعمال مگر چوری کا شدید خطرہ | صنعتی معیار (کم سے کم مخصوص اختیارات) |
3. ماڈل کنٹیکسٹ پروٹوکول (MCP) توثیقی ٹوپولوجی
Anthropic کی طرف سے اوپن سورس کیا گیا اور Claude Code و Cursor میں اپنایا گیا Model Context Protocol (MCP) ایک غیر متناسب کلائنٹ-سرور نظام پر محیط ہے۔
اس میں مواصلات کی دو بنیادی حدود کارفرما ہیں:
- حد الف (ہوسٹ سے MCP سرور): LLM کلائنٹ ایپ اور MCP سرور پراسیس کے درمیان کا رابطہ۔
- حد ب (MCP سرور سے انٹرپرائز سسٹم): MCP سرور اور بیرونی APIs (GitHub، Jira، Slack) کا رابطہ۔
ماڈل کنٹیکسٹ پروٹوکول (MCP) توثیقی فریم ورک:
+-------------------------------------------------------------------------------------------------------+
| MCP ہوسٹ رن ٹائم (مثلاً Claude Code / Cursor / خود مختار ایجنٹ فریم ورک) |
| |
| +---------------------+ پرامپٹ سیاق و سباق +--------------------------------------------+ |
| | صارف پرامپٹ / LLM | <───────────────────────────> | ماڈل ریزننگ انجن (Claude 3.7 / GPT-4o) | |
| +----------+----------+ +--------------------------------------------+ |
| | ٹول کال کا اجرا (`tools/call`) |
| v |
| +--------------------------------------------------------------------------------------------------+ |
| | MCP کلائنٹ انجن | |
| | - آتھرائزیشن سرور کے ساتھ OAuth 2.1 PKCE ہینڈ شیک کا انتظام کرتا ہے | |
| | - محفوظ میموری میں DPoP کی عارضی پرائیویٹ کی رکھتا ہے | |
| | - ہر کال پر DPoP Proof JWT بناتا ہے اور Access Token شامل کرتا ہے | |
| +-----------------------------------+--------------------------------------------------------------+ |
+--------------------------------------|----------------------------------------------------------------+
|
| ٹرانسپورٹ: Stdio (مقامی پراسیس) یا SSE/HTTP (ریموٹ سرور)
v
+-------------------------------------------------------------------------------------------------------+
| MCP سرور رن ٹائم (مثلاً GitHub MCP / انٹرپرائز ڈیٹا بیس MCP) |
| |
| +--------------------------------------------------------------------------------------------------+ |
| | توثیق اور ٹوکن ویلیڈیشن انٹرسیپٹر | |
| | 1. آتھرائزیشن سرور کے JWKS سے OAuth 2.1 ٹوکن کے دستخط کی تصدیق کرتا ہے | |
| | 2. DPoP Proof کی جانچ: HTTP طریقہ کار، URI، Nonce اور پبلک کی کی تصدیق کرتا ہے | |
| | 3. اسکوپس کی جانچ: کم سے کم اختیارات کا نفاذ (`issues:read` جائز، `admin:all` مسترد) | |
| +-----------------------------------+--------------------------------------------------------------+ |
| | |
| v |
| +--------------------------------------------------------------------------------------------------+ |
| | MCP ٹول ایگزیکیوشن انجن (`tools/call` عمل درآمد) | |
| | - پیرامیٹرز صاف کرتا ہے، پاتھ ٹریورسل روکتا ہے، محفوظ ماحول میں کال چلاتا ہے | |
| +-----------------------------------+--------------------------------------------------------------+ |
+--------------------------------------|----------------------------------------------------------------+
| مجاز اسکوپڈ ٹوکن کے ساتھ بیرونی API کو کال بھیجتا ہے
v
+----------------------------------+
| انٹرپرائز SaaS اور ڈیٹا بیسز |
| (GitHub / Jira / PostgreSQL / S3)|
+----------------------------------+مقامی Stdio بمقابلہ ریموٹ SSE/HTTP ٹرانسپورٹ
- مقامی Stdio ٹرانسپورٹ (
transport: "stdio"):
- سرور ہوسٹ کے ذیلی پراسیس کے طور پر چلتا ہے اور ان پٹ/آؤٹ پٹ پر بات چیت کرتا ہے۔
- سیکیورٹی خرابی: ماحول کے متغیرات (
env) میں کیز ڈالنے سے کوئی بھی شیل کمانڈ/proc/[pid]/environکے ذریعے مکمل رسائی چرا سکتی تھی۔ - OAuth 2.1 حل: ہوسٹ ٹوکن والٹ چلاتا ہے اور شروع میں مختصر مدتی ٹوکن فراہم کرتا ہے۔
- ریموٹ SSE/HTTP ٹرانسپورٹ (
transport: "sse"):
- سرور انٹرنیٹ پر آزادانہ طور پر چلتا ہے۔
- اس میں OAuth 2.1 لازمی ہے: کلائنٹ کو
Authorizationہیڈر اور DPoP پروف دینا ہوتا ہے۔
4. PKCE (RFC 7636) کی تفصیلی وضاحت: ایجنٹ کے لوکل کال بیکس کا تحفظ
Proof Key for Code Exchange (PKCE) پبلک کلائنٹس پر آتھرائزیشن کوڈ کی چوری روکنے کے لیے لایا گیا تھا۔ OAuth 2.1 میں یہ ہر کوڈ ایکسچینج کے لیے لازمی ہے۔
CLI اور IDE پبلک کلائنٹس کیوں ہیں؟
Claude Code یا Cursor جیسے ٹولز صارف کی مشین پر چلتے ہیں اور اپنے اندر کوئی خفیہ پاس ورڈ یا client_secret محفوظ نہیں رکھ سکتے۔ ریورس انجینئرنگ سے یہ فوری افشا ہو سکتا ہے۔
جب کوئی پبلک کلائنٹ اجازت مانگتا ہے تو سرور لوکل لوپ بیک پتے (جیسے http://127.0.0.1:18492/callback) پر Authorization Code بھیجتا ہے۔
کوڈ چوری کا حملہ (PKCE کے بغیر):
1. ایجنٹ سرور سے اجازت کا کوڈ مانگتا ہے۔
2. مشین میں چھپی بدنیتی پر مبنی ایپ لوکل پورٹ کو سنف کرتی ہے۔
3. سرور براؤزر کو کوڈ کے ساتھ لوکل پتے پر ری ڈائریکٹ کرتا ہے۔
4. حملہ آور پراسیس AUTH_CODE_123 چرا لیتی ہے۔
5. حملہ آور کوڈ سرور کو بھیج کر بغیر پاس ورڈ کے Access Token حاصل کر لیتا ہے!PKCE کا ریاضیاتی حفاظتی نظام
PKCE ہر سیشن کے لیے ایک خفیہ کوڈ بنا کر اس خطرے کو جڑ سے ختم کرتا ہے:
PKCE پروٹوکول کا طریقہ کار:
+-------------+ +-----------------------+ +--------------------+
| Agent CLI | | صارف کا براؤزر | | آتھرائزیشن سرور |
| (کلائنٹ) | +-----------+-----------+ +---------+----------+
+------+------+ | |
| 1. code_verifier بناتا ہے (انتہائی خفیہ| |
| code_challenge = S256(...) نکالتا ہے| |
| | |
| 2. لوکل پورٹ پر لسنر چلاتا ہے | |
| چیلنج کے ساتھ براؤزر کھولتا ہے ────>| 3. GET /authorize?response_type=code |
| | &client_id=agent_cli |
| | &code_challenge=E9Melhoa2Owv... |
| | &code_challenge_method=S256 ─────────>|
| | | 4. صارف کی منظوری۔
| | 5. 302 ری ڈائریکٹ لوکل پورٹ پر | چیلنج محفوظ ہوا
| |<─────────────────────────────────────────|
|<───────────────────────────────────────| http://127.0.0.1:18492/callback?code=AC_88921
| 6. کوڈ وصول پاتا ہے |
| |
| 7. POST /oauth/token |
| code=AC_88921 & code_verifier=dBjftJeZ4CVP-mB92K... ─────────────────────────>|
| | 8. حساب کا موازنہ:
| | SHA256(verifier)
| | == محفوظ چیلنج؟
| 9. Access Token + Refresh Token فراہم کرتا ہے <───────────────────────────────────| ہاں: ٹوکن جاری
+------+------+- Code Verifier: ایجنٹ 43 سے 128 حروف پر مشتمل ایک بے ترتیب انکرپٹڈ اسٹرنگ $V$ بناتا ہے:
- Code Challenge: کلائنٹ اس کا SHA-256 ہیش لے کر Base64URL انکوڈ کرتا ہے:
- درخواست بھیجنا: کلائنٹ $C$ اور الگورتھم سرور کو بھیجتا ہے۔
- ٹوکن کا تبادلہ: کلائنٹ اصل $V$ بھیجتا ہے، سرور ہیش ملا کر تصدیق کرتا ہے۔
کوئی حملہ آور کوڈ چرا بھی لے تو وہ اصل code_verifier کے بغیر ٹوکن نہیں لے سکتا۔
مکمل TypeScript نفاذ: محفوظ PKCE انجن
// pkce.ts - Enterprise OAuth 2.1 PKCE Engine for AI Agent Clients
import { randomBytes, createHash } from "node:crypto";
export interface PKCEChallenge {
codeVerifier: string;
codeChallenge: string;
codeChallengeMethod: "S256";
}
export class PKCEEngine {
/**
* Generates a cryptographically secure code_verifier (RFC 7636 Section 4.1)
* Length defaults to 64 bytes of entropy (yielding ~86 base64url characters).
*/
public static generateVerifier(length: number = 64): string {
if (length < 32 || length > 96) {
throw new RangeError("Verifier byte length must be between 32 and 96.");
}
const buffer = randomBytes(length);
return this.base64UrlEncode(buffer);
}
/**
* Computes the S256 code_challenge from the code_verifier (RFC 7636 Section 4.2)
*/
public static computeChallenge(verifier: string): string {
const hash = createHash("sha256").update(verifier, "ascii").digest();
return this.base64UrlEncode(hash);
}
/**
* Generates the complete PKCE pair ready for OAuth 2.1 authorization
*/
public static createPair(): PKCEChallenge {
const codeVerifier = this.generateVerifier(64);
const codeChallenge = this.computeChallenge(codeVerifier);
return {
codeVerifier,
codeChallenge,
codeChallengeMethod: "S256",
};
}
/**
* Server-side verification: Validates an incoming code_verifier against stored challenge
*/
public static verify(verifier: string, storedChallenge: string): boolean {
const computed = this.computeChallenge(verifier);
// Timing-safe buffer comparison to prevent side-channel timing attacks
const bufA = Buffer.from(computed);
const bufB = Buffer.from(storedChallenge);
if (bufA.length !== bufB.length) return false;
let result = 0;
for (let i = 0; i < bufA.length; i++) {
result |= bufA[i] ^ bufB[i];
}
return result === 0;
}
private static base64UrlEncode(buffer: Buffer): string {
return buffer
.toString("base64")
.replace(/\\+/g, "-")
.replace(/\\//g, "_")
.replace(/=+$/, "");
}
}5. ہیڈ لیس سرورز اور CLI اجازت: ڈیوائس فلو (RFC 8628)
کلاؤڈ یا ڈوکر کنٹینرز جیسے ہیڈ لیس ماحول میں جہاں کوئی براؤزر نہیں ہوتا، پاس ورڈ طلب کرنا قوانین کے خلاف ہے۔ اس کا حل OAuth 2.0 Device Authorization Grant (RFC 8628) ہے:
ہیڈ لیس ماحول میں ڈیوائس آتھرائزیشن فلو (RFC 8628):
+-------------------+ +-----------------------+
| ہیڈ لیس ایجنٹ | | آتھرائزیشن سرور |
| (Docker / Cloud) | +-----------+-----------+
+---------+---------+ |
| 1. POST /oauth/device/code (client_id, scope) ──────────────────────>|
| | 2. بناتا ہے:
| 3. ڈیوائس کی تفصیلات واپس کرتا ہے: | device_code (خفیہ)
| - user_code: "WDJB-HGNP" | user_code (ظاہری)
| - verification_uri: "https://auth.corp.com/activate" | interval: 5 سیکنڈ
| - interval: 5 <───────────────────────────────────────────────────|
| |
| 4. اسکرین پر ہدایت نامہ دکھاتا ہے: |
| "https://auth.corp.com/activate کھولیں اور کوڈ درج کریں: WDJB-HGNP"|
| |
| 5. پولنگ کا عمل شروع ہوتا ہے: |
| POST /oauth/token (grant_type=device_code, device_code=...) ─────>|
| <── 400 Bad Request: {"error": "authorization_pending"} ─────────|
| [5 سیکنڈ انتظار] |
| |
+---------+---------+ صارف لیپ ٹاپ یا موبائل پر لنک کھولتا ہے |
| صارف کا لیپ ٹاپ | ──> "WDJB-HGNP" درج کر کے لاگ ان کرتا ہے ─────────────────>| 6. اجازت منظور!
+-------------------+ |
| |
| 7. اگلی پولنگ پر کامیابی: |
| POST /oauth/token ───────────────────────────────────────────────>|
| <── 200 OK: {access_token: "...", refresh_token: "..."} ──────────|
v
[ہیڈ لیس ایجنٹ کسی بھی پاس ورڈ افشا کیے بغیر کامیابی سے لاگ ان ہو گیا]خود کار مشینوں کے لیے حل: RFC 7523 پرائیویٹ کی JWT
جب کوئی انسان موجود نہ ہو تو زیرو ٹرسٹ آرکیٹیکچر RFC 7523 کے ساتھ Client Credentials استعمال کرتا ہے:
- ایجنٹ کے پاس HSM میں محفوظ ایک پرائیویٹ کی ہوتی ہے جس سے وہ ایک مختصر مدتی دستخط شدہ JWT بنا کر بھیجتا ہے۔
6. ٹوکن کی میعاد اور خودکار تجدید
چونکہ OAuth 2.1 ٹوکنز کی میعاد مختصر (5 تا 15 منٹ) ہوتی ہے، اس لیے ایجنٹ کو بغیر کسی رکاوٹ کے خود بخود ٹوکن کی تجدید کرنی ہوتی ہے۔
ریفریش ٹوکن روٹیشن (RTR) اور چوری کی روک تھام
OAuth 2.1 میں Refresh Token Rotation (RTR) نافذ ہوتا ہے:
- ہر بار ٹوکن استعمال کرنے پر وہ فوری منسوخ ہو جاتا ہے۔
- نیا ایکسیس ٹوکن اور بالکل نیا ریفریش ٹوکن جاری ہوتا ہے۔
- چوری شدہ پرانا ٹوکن استعمال ہوتے ہی سرور فوراً الرٹ ہو کر تمام ٹوکنز منسوخ کر دیتا ہے:
$$\text{Incoming Token State} == \text{"REVOKED"} \implies \text{Revoke All Tokens in Family Tree}$$
ریفریش ٹوکن روٹیشن (RTR) اور چوری کا سراغ:
ٹوکن کی چین:
[Refresh Token A] ──(استعمال ہوا)──> [Refresh Token B] ──(استعمال ہوا)──> [Refresh Token C] (فعال)
│
│ حملہ آور پرانا چرا کر لایا گیا [Refresh Token A] استعمال کرتا ہے
v
[سرور پرانے منسوخ شدہ ٹوکن کا غیر قانونی استعمال پکڑ لیتا ہے!]
│
▼
[ایمرجنسی الرٹ]: ٹوکن B اور C سمیت تمام جاری شدہ ٹوکنز فوراً ختم کر دیے جاتے ہیں۔
ایجنٹ کا سیشن بند ہو جاتا ہے اور سیکیورٹی محفوظ رہتی ہے۔Python میں پروڈکشن کلاس: غیر متضاد محفوظ ٹوکن مینیجر
# token_manager.py - Enterprise Async Token Lifecycle Manager for AI Agents
import asyncio
import time
import httpx
from typing import Optional, Dict, Any
class AgentTokenManager:
def __init__(
self,
token_endpoint: str,
client_id: str,
initial_refresh_token: str,
proactive_refresh_seconds: int = 60,
):
self.token_endpoint = token_endpoint
self.client_id = client_id
self.refresh_token = initial_refresh_token
self.access_token: Optional[str] = None
self.expires_at: float = 0.0
self.proactive_refresh_seconds = proactive_refresh_seconds
self._lock = asyncio.Lock()
async def get_valid_access_token(self) -> str:
now = time.time()
if self.access_token and (self.expires_at - now) > self.proactive_refresh_seconds:
return self.access_token
async with self._lock:
now = time.time()
if self.access_token and (self.expires_at - now) > self.proactive_refresh_seconds:
return self.access_token
await self._refresh_token_exchange()
if not self.access_token:
raise RuntimeError("Failed to acquire valid access token from authorization server.")
return self.access_token
async def _refresh_token_exchange(self) -> None:
payload = {
"grant_type": "refresh_token",
"refresh_token": self.refresh_token,
"client_id": self.client_id,
}
async with httpx.AsyncClient(timeout=10.0) as client:
try:
response = await client.post(
self.token_endpoint,
data=payload,
headers={"Content-Type": "application/x-www-form-urlencoded"},
)
except httpx.RequestError as exc:
raise ConnectionError(f"Network transport error during token refresh: {exc}")
if response.status_code == 200:
data: Dict[str, Any] = response.json()
self.access_token = data["access_token"]
expires_in = int(data.get("expires_in", 3600))
self.expires_at = time.time() + expires_in
# Update to the newly rotated refresh token if provided
if "refresh_token" in data:
self.refresh_token = data["refresh_token"]
elif response.status_code in (400, 401):
err_data = response.json()
# If error is 'invalid_grant', the token was likely already rotated or revoked
raise PermissionError(f"Token refresh rejected (possible token theft or expiry): {err_data}")
else:
response.raise_for_status()7. زیرو ٹرسٹ اسناد کا تحفظ: DPoP (RFC 9449)
روایتی Bearer Tokens کوئی بھی چرا کر استعمال کر سکتا ہے۔ پرامپٹ انجیکشن کے خطرے کے پیش نظر OAuth 2.1 میں DPoP (RFC 9449) کو لازمی قرار دیا گیا ہے جو ٹوکن کو کلائنٹ کی پرائیویٹ کی سے جوڑ دیتا ہے۔
ایپلی کیشن لیئر پر DPOP (RFC 9449) کا طریقہ کار:
+-------------------------------------------------------------------------------------------------+
| ایجنٹ کا مقامی ماحول (کلائنٹ) |
| - عارضی کی پیئر بناتا ہے: پبلک کی (JWK) + پرائیویٹ کی (جو کبھی میموری سے باہر نہیں نکلتی) |
+-------------------------------------------------------------------------------------------------+
│
│ 1. درخواست کے ساتھ DPoP Proof ہیڈر بھیجتا ہے:
│ DPoP: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRwb3Ar...
│ پیلوڈ: {
│ "htm": "GET",
│ "htu": "https://api.enterprise.com/mcp/tools",
│ "iat": 1772630400,
│ "jti": "random_nonce_9921",
│ "jwk": { ...پبلک کی... }
│ }
│
│ 2. منسلک ٹوکن ارسال کرتا ہے:
│ Authorization: DPoP dpop_access_token_88921
v
+-------------------------------------------------------------------------------------------------+
| انٹرپرائز MCP گیٹ وے (ریسورس سرور) |
| 1. توثیق کرتا ہے کہ ٹوکن JWK میں دی گئی پبلک کی کے ساتھ وابستہ ہے۔ |
| 2. DPoP پروف کے دستخط کی تصدیق کرتا ہے۔ |
| 3. تصدیق کرتا ہے کہ "htm" کا طریقہ اور "htu" کا پتہ بالکل درست اور مماثل ہیں۔ |
| 4. ٹائم اسٹیمپ اور یکتائی کی جانچ کرتا ہے۔ |
+-------------------------------------------------------------------------------------------------+
│
┌────────────────────────────────────────┴────────────────────────────────────────┐
▼ ▼
[درست ثبوت اور مماثل کیز] [چوری شدہ ٹوکن مسترد]
درخواست کی جانچ مکمل، عمل درآمد شروع حملہ آور کے پاس ٹوکن تو ہے مگر ایجنٹ
کی ذاتی پرائیویٹ کی نہیں ہے۔
نتیجہ: فوری طور پر 401 Unauthorized!DPoP کیسے کام کرتا ہے؟
- ایجنٹ شروع ہوتے ہی میموری میں ایک عارضی غیر متناسب کی پیئر بناتا ہے۔
- ٹوکن حاصل کرتے وقت پبلک کی کی شناخت ٹوکن کے اندر محفوظ کر دی جاتی ہے۔
- ہر درخواست کے لیے ایجنٹ ایک الگ DPoP JWT بناتا ہے جس میں ایڈریس، وقت، اور طریقہ کار درج ہوتا ہے۔
- ٹوکن چوری بھی ہو جائے تو کلائنٹ کی پرائیویٹ کی کے بغیر یہ بالکل بے کار ثابت ہوتا ہے۔
8. انٹرپرائز سیکیورٹی بینچ مارکس اور رسک میٹرکس
عملی کارکردگی کے بینچ مارکس (10,000 ٹیسٹ، Apple M4 Max)
| توثیقی آرکیٹیکچر | کلائنٹ ہینڈ شیک تاخیر (p50) | کلائنٹ ہینڈ شیک تاخیر (p99) | فی درخواست توثیق کا بوجھ | ری پلے سے حفاظت | کلائنٹ میموری کا خرچ | سرور پر CPU کا بوجھ |
|---|---|---|---|---|---|---|
| جامد PAT / API کی | 0.1 ms (کوئی ہینڈ شیک نہیں) | 0.2 ms | 0.02 ms (الفاظ کا موازنہ) | کچھ نہیں (مکمل چوری) | < 1 KB | بنیادی سطح |
| OAuth 1.0a (HMAC-SHA1) | 14.2 ms | 38.5 ms | 1.84 ms (دستخط کا حساب) | جزوی (نونس کی جانچ) | 12 KB | +18% |
| OAuth 2.0 Bearer | 45.1 ms | 112.0 ms | 0.15 ms (JWT تصدیق) | کچھ نہیں (مکمل چوری) | 18 KB | +4% |
| OAuth 2.1 (PKCE + RTR) | 48.6 ms | 118.4 ms | 0.16 ms (JWT تصدیق) | مناسب (RTR منسوخی) | 24 KB | +5% |
| OAuth 2.1 + DPoP (P-256) | 54.2 ms | 132.8 ms | 1.22 ms (DPoP جانچ) | مکمل (زیرو ری پلے) | 36 KB | +12% |
| mTLS (RFC 8705) | 62.8 ms | 154.1 ms | 0.45 ms (TLS سیشن) | مکمل (سرٹیفکیٹ باؤنڈ) | 128 KB | +15% |
خطرات اور ان کی روک تھام کا میٹرکس
خطرات کی شدت بمقابلہ پروٹوکول تحفظ:
+-------------------------------+-------------------+-------------------+-------------------+-------------------+
| حملہ آور کا طریقہ | جامد API کیز | OAuth 1.0a | OAuth 2.0 Bearer | OAuth 2.1 + DPoP |
+-------------------------------+-------------------+-------------------+-------------------+-------------------+
| 1. بالواسطہ پرامپٹ انجیکشن | انتہائی سنگین (10)| شدید خطرہ (7/10) | انتہائی سنگین (10)| معمولی خطرہ (2/10)|
| (لاگز اور کونسول سے چوری) | کیز مستقل افشا | دستخط بنانا مشکل | ٹوکن فوری چوری | کی کے بغیر بے کار |
+-------------------------------+-------------------+-------------------+-------------------+-------------------+
| 2. لوکل پورٹ سنفنگ | لاگو نہیں ہوتا | کم خطرہ (3/10) | شدید خطرہ (8/10) | محفوظ (1/10) |
| (لوپ بیک پر کوڈ چرانا) | ری ڈائریکشن نہیں | نونس محفوظ ہے | کوڈ فوری چوری | PKCE سے مکمل تحفظ |
+-------------------------------+-------------------+-------------------+-------------------+-------------------+
| 3. SSRF ٹول کا استحصال | انتہائی سنگین (10)| درمیانہ خطرہ (5) | انتہائی سنگین (10)| محفوظ (1/10) |
| (غلط سرور پر کال بھیجنا) | مکمل اختیارات گم | ایڈریس کا ملاپ فیل| ٹوکن کا غلط استعمال| DPoP پتہ مماثل نہیں|
+-------------------------------+-------------------+-------------------+-------------------+-------------------+
| 4. ذیلی پراسیس کی جاسوسی | انتہائی سنگین (10)| درمیانہ خطرہ (5) | شدید خطرہ (8/10) | معمولی خطرہ (2/10)|
| (/proc/environ کا معائنہ) | مستقل کیز افشا | ماحول میں کیز | ماحول میں ٹوکن | مختصر اور کی باؤنڈ|
+-------------------------------+-------------------+-------------------+-------------------+-------------------+
| 5. بیک وقت تجدید کا تصادم | لاگو نہیں ہوتا | لاگو نہیں ہوتا | معمولی خطرہ (2) | زیادہ (Mutex کا |
| (ایک ساتھ کئی ایجنٹس) | تجدید نہیں ہوتی | تجدید نہیں ہوتی | ٹوکن کلسٹرز | استعمال ضروری ہے) |
+-------------------------------+-------------------+-------------------+-------------------+-------------------+9. قدم بہ قدم گائیڈ: محفوظ OAuth 2.1 + PKCE MCP سرور
// server.ts - Hardened Remote MCP Server with OAuth 2.1 Validation
import express, { Request, Response, NextFunction } from "express";
import { createRemoteJWKSet, jwtVerify } from "jose";
const app = express();
app.use(express.json());
// Configuration
const ISSUER = "https://auth.enterprise.com/";
const AUDIENCE = "https://mcp.enterprise.com/";
const JWKS_URI = new URL("https://auth.enterprise.com/.well-known/jwks.json");
const JWKS = createRemoteJWKSet(JWKS_URI);
interface AuthenticatedRequest extends Request {
tokenClaims?: any;
}
/**
* Enterprise OAuth 2.1 Token Validation Middleware
*/
async function requireOAuth21(
req: AuthenticatedRequest,
res: Response,
next: NextFunction
): Promise<void> {
const authHeader = req.headers.authorization;
if (!authHeader || !authHeader.startsWith("Bearer ")) {
res.status(401).json({
jsonrpc: "2.0",
error: { code: -32001, message: "Missing or invalid OAuth 2.1 Authorization header." },
id: req.body?.id || null,
});
return;
}
const token = authHeader.split(" ")[1];
try {
// Cryptographically verify token signature, issuer, audience, and expiration
const { payload } = await jwtVerify(token, JWKS, {
issuer: ISSUER,
audience: AUDIENCE,
});
// Enforce OAuth 2.1 requirement: reject tokens without an expiration claim
if (!payload.exp || typeof payload.exp !== "number") {
res.status(401).json({
jsonrpc: "2.0",
error: { code: -32002, message: "Non-compliant token: missing expiration claim." },
id: req.body?.id || null,
});
return;
}
req.tokenClaims = payload;
next();
} catch (err: any) {
res.status(401).json({
jsonrpc: "2.0",
error: { code: -32003, message: `Token verification failed: ${err.message}` },
id: req.body?.id || null,
});
}
}
/**
* Fine-Grained Scope Enforcement Guard
*/
function requireScope(requiredScope: string) {
return (req: AuthenticatedRequest, res: Response, next: NextFunction): void => {
const scopes: string[] = (req.tokenClaims?.scope || "").split(" ");
if (!scopes.includes(requiredScope)) {
res.status(403).json({
jsonrpc: "2.0",
error: {
code: -32004,
message: `Insufficient permissions: missing required scope '${requiredScope}'`,
},
id: req.body?.id || null,
});
return;
}
next();
};
}
/**
* Standard MCP JSON-RPC 2.0 Handler Endpoint
*/
app.post(
"/mcp/v1",
requireOAuth21,
requireScope("mcp:tools:execute"),
async (req: AuthenticatedRequest, res: Response): Promise<void> => {
const { jsonrpc, method, params, id } = req.body;
if (jsonrpc !== "2.0") {
res.status(400).json({ jsonrpc: "2.0", error: { code: -32600, message: "Invalid JSON-RPC version." }, id });
return;
}
// Router for MCP Primitives
switch (method) {
case "tools/list":
res.json({
jsonrpc: "2.0",
result: {
tools: [
{
name: "query_database",
description: "Executes read-only SQL queries against the analytics warehouse.",
inputSchema: {
type: "object",
properties: { query: { type: "string" } },
required: ["query"],
},
},
],
},
id,
});
break;
case "tools/call":
if (params?.name === "query_database") {
// Verify elevated data scope for this specific tool execution
const scopes: string[] = (req.tokenClaims?.scope || "").split(" ");
if (!scopes.includes("db:analytics:read")) {
res.json({
jsonrpc: "2.0",
error: { code: -32005, message: "Forbidden: tool requires 'db:analytics:read' scope." },
id,
});
return;
}
// Execute tool with verified, scoped identity
const userSub = req.tokenClaims.sub;
console.log(`Executing query on behalf of verified agent identity: ${userSub}`);
res.json({
jsonrpc: "2.0",
result: {
content: [
{
type: "text",
text: JSON.stringify({ status: "success", rows_returned: 42, latency_ms: 12 }),
},
],
},
id,
});
} else {
res.status(404).json({ jsonrpc: "2.0", error: { code: -32601, message: "Tool not found." }, id });
}
break;
default:
res.status(404).json({ jsonrpc: "2.0", error: { code: -32601, message: "Method not found." }, id });
}
}
);
const PORT = process.env.PORT || 8080;
app.listen(PORT, () => {
console.log(`Hardened OAuth 2.1 MCP Server listening on port ${PORT}`);
});10. نتائج اور اسٹریٹجک سفارشات (E-E-A-T)
AI ماڈلز کو انٹرپرائز انفراسٹرکچر سے جوڑتے ہوئے ایجنٹس کو محدود اعتبار کے حامل نمائندے سمجھنا چاہیے۔ کسی ایجنٹ کو مکمل طور پر بااعتماد سروس سمجھنا یا مکمل ناقابل اعتبار جان کر ہر کلک پر انسان کا محتاج بنانا تکنیکی غلطی ہے۔
OAuth 2.1 انٹرپرائز زیرو ٹرسٹ سیکیورٹی اور ڈویلپرز کی خود مختاری کے درمیان توازن قائم کرتا ہے۔
5 نکاتی سیکیورٹی چیک لسٹ
- جامد کیز کا خاتمہ: تمام
.envفائلوں کو صاف کر کے مختصر مدتی OAuth 2.1 ٹوکنز لائیں۔ - S256 کے ساتھ PKCE کی پابندی: تمام ٹولز میں SHA-256 کے ساتھ RFC 7636 کا نفاذ یقینی بنائیں۔
- ہیڈ لیس ماحول میں Device Flow یا Private Key JWT کا نفاذ: کونسول پر پاس ورڈ مانگنے کی فرسودہ روش ترک کریں۔
- Mutex کے ذریعے ٹوکن ریفریش کا انتظام: متوازی ایجنٹس کے درمیان ٹوکن تصادم سے پیدا ہونے والی خرابیوں کو روکیں۔
- DPoP (RFC 9449) کو لازمی بنائیں: حساس کاموں کے لیے ٹوکنز کو بھیجنے والے سے وابستہ کر کے پرامپٹ انجیکشن کے خطرات کا قلع قمع کریں۔