نجی روٹنگ طے کرتی ہے کہ سرور تک کون پہنچتا ہے؛ OAuth کے نقل و حمل کے قواعد طے کرتے ہیں کہ ہر پیغام کیسے سفر کرتا ہے۔ براؤزر، اجازت سرور، ٹوکن اینڈ پوائنٹ اور ریسورس سرور سب ایک ہی VPN کے پیچھے ہو سکتے ہیں اور پھر بھی مختلف ٹانگوں پر پیغامات کا تبادلہ کر سکتے ہیں۔ ہر ٹانگ کی اپنی نقل و حمل کی ضرورت ہے، اور VPN ان میں سے کسی کو نرم نہیں کرتا۔ VPN کی حد اور پروٹوکول کی حد الگ الگ لکیریں ہیں۔

فیصلہ آسان ہو جاتا ہے اگر آپ یہ پوچھنا چھوڑ دیں کہ نیٹ ورک قابلِ اعتماد ہے یا نہیں اور یہ پوچھنا شروع کریں کہ کون سا تبادلہ کون سی حد عبور کر رہا ہے۔

نیٹ ورک کے حساب سے نہیں، ٹانگ کے حساب سے فیصلہ کریں

اینڈ پوائنٹس الگ الگ لکھیں: اجازت اینڈ پوائنٹ، ٹوکن اینڈ پوائنٹ، ری ڈائریکٹ URI، ریسورس سرور کا URL، TLS کے ختم ہونے کا مقام اور VPN گیٹ وے۔ پھر نشان زد کریں کہ ہر درخواست کون فریق شروع کرتا ہے اور جواب کہاں جاتا ہے۔

جو VPN گیٹ وے پر ختم ہوتا ہے وہ اس گیٹ وے تک کے حصے کو خفیہ کرتا ہے۔ درخواست اس کے پیچھے سادہ HTTP کے طور پر جاری رہ سکتی ہے، اور وہ بقیہ ٹانگ HTTPS نہیں بن جاتی کیونکہ پہلے کا حصہ خفیہ کیا گیا تھا۔ پروٹوکول کو اسی تسلسل سے غرض ہے۔ پہلی چھلانگ کو خفیہ کرنا دوسری چھلانگ کو محفوظ نہیں بناتا۔

نقل و حمل سروس کی شناخت کی جانچ بھی ساتھ لے کر چلتی ہے۔ براؤزر ایپلیکیشن URL کے سرٹیفکیٹ کی تصدیق کرتا ہے؛ VPN براؤزر کی جانب سے یہ تصدیق نہیں کرتا اور نہ ہی کسی غیر تصدیق شدہ اینڈ پوائنٹ کو قابلِ قبول بنا دیتا ہے۔ سرٹیفکیٹ اس اینڈ پوائنٹ کا نام بتاتا ہے جسے کلائنٹ سمجھتا ہے کہ وہ کال کر رہا ہے۔ گیٹ وے تک کی سرنگ اس اینڈ پوائنٹ کا نام نہیں بدلتی اور نہ اس کی تصدیق کرتی ہے۔

اجازت کا جواب اور ری ڈائریکٹ URI

OAuth کی موجودہ بہترین سیکیورٹی پریکٹس اجازت کے جوابات کو غیر خفیہ کنکشنز پر بھیجنے سے منع کرتی ہے۔ اس میں وہ ری ڈائریکٹ بھی شامل ہے جو اجازت کوڈ یا ٹوکن کلائنٹ تک واپس لے جاتا ہے، نہ صرف ابتدائی درخواست۔

یہی رہنمائی HTTP ری ڈائریکٹ URI کی اجازت نہیں دیتی، سوائے مخصوص نیٹو کلائنٹ لوپ بیک صورت کے۔ اندرونی ہوسٹ نام کوئی نئی استثنا پیدا نہیں کرتا، اور ایسا DNS نام جو صرف VPN کے اندر حل ہوتا ہو، اگر اسکیم کہے تو پھر بھی HTTP URL ہے۔ رجسٹرڈ URI میں اسکیم چیک کریں، صرف ہوسٹ نام نہیں۔

بالکل درست HTTPS ری ڈائریکٹ URI اجازت سرور پر رجسٹر کریں اور کلائنٹ پر سرٹیفکیٹ کی تصدیق فعال رکھیں۔ ترقی کے لیے ایسا شارٹ کٹ جو HTTPS کی ضرورت کو دبا دے، ایسا فلو بناتا ہے جو اس پروڈکشن کنفیگریشن سے مختلف برتاؤ کرتا ہے جس کی اسے نقل کرنی چاہیے۔

ٹوکن اینڈ پوائنٹ اور bearer ٹوکن کی درخواستیں

ٹوکن کی درخواست اسناد یا ایسا کوڈ لے کر چلتی ہے جسے رسائی کے بدلے بدلا جا سکتا ہے۔ اسے غیر محفوظ ٹانگ پر بھیجنا ایسا مواد بے نقاب کرتا ہے جس پر ریسورس سرور بعد میں بھروسا کرے گا، چاہے اردگرد کا نیٹ ورک نجی ہو۔ جو پراکسی درخواست پڑھ سکتی ہے وہ اس میں موجود اسناد بھی پڑھ سکتی ہے۔

bearer ٹوکن والی ریسورس درخواستوں کے لیے RFC 6750 اس تصریح کے لیے TLS کو نافذ کرنا اور استعمال کرنا لازمی قرار دیتا ہے۔ دفتری سب نیٹ کو قابلِ اعتماد کہنا وہ عمومی پروٹوکول استثنا نہیں ہے جس کی سادہ متن bearer تعیناتی کو ضرورت ہوتی ہے۔

دونوں ٹانگوں کے لیے دستاویزی محفوظ اینڈ پوائنٹ URLs استعمال کریں۔ اگر کوئی لائبریری HTTP ٹوکن اینڈ پوائنٹ کو کال کرنے سے انکار کرے تو یہ انکار تصریح کے کام کرنے کی علامت ہے، نہ کہ کوئی ایسی کنفیگریشن خرابی جسے بائی پاس کرنا ہو۔ اس URL کو کلائنٹ کنفیگریشن میں درج کریں بجائے اس کے کہ رن ٹائم پر اخذ کریں۔

TLS کہاں ختم ہوتا ہے اور کیا باقی رہ جاتا ہے

اگر TLS کسی مجاز فرنٹ اینڈ پر ختم ہوتا ہے تو اس فرنٹ اینڈ کا نام لیں اور اس سے ایپلیکیشن تک کے راستے کا جائزہ لیں۔ فرنٹ اینڈ بقیہ حصے پر فارورڈنگ، بھروسے اور رازداری کا ذمہ دار ہو جاتا ہے، اور سروس کی معاون آرکیٹیکچر کو یہی ترتیب بیان کرنی چاہیے۔

راستے میں کہیں اور موجود VPN ان ذمہ داریوں کو طے نہیں کرتا۔ وہ یہ بھی نہیں بتاتا کہ براؤزر کو نظر آنے والا ایپلیکیشن URL اس سرٹیفکیٹ سے میل کھاتا ہے جو فرنٹ اینڈ پیش کرتا ہے۔

اندرونی تعیناتی کے لیے ختم ہونے کا مقام اور اس کی پیش کردہ شناخت درج کریں۔ ایسا فرنٹ اینڈ جو کسی مختلف نام کے سرٹیفکیٹ کے ساتھ TLS ختم کرے، براؤزر کی ایسی وارننگ پیدا کرتا ہے جسے آپریٹرز اکثر ٹھیک کرنے کے بجائے دبا دیتے ہیں۔

نیٹو لوپ بیک استثنا تنگ ہے

لوپ بیک ری ڈائریکٹ استثنا صارف کے اپنے آلے پر ہونے والی کال بیک سے متعلق ہے، جہاں کلائنٹ اور براؤزر وہی آلہ مشترکہ طور پر استعمال کرتے ہیں۔ یہ ترتیب ایک ہی آلے پر کال بیک کی ہے، اور یہ کسی دفتری سب نیٹ کو HTTP پر عام اجازت سرور یا ٹوکن لے جانے والی API فراہم کرنے کی اجازت نہیں دیتی۔

استثنا کو کلائنٹ کی قسم اور اسی کال بیک تک محدود رکھیں جسے وہ بیان کرتا ہے۔ اسے ویب ایپلیکیشن، مشترکہ اندرونی سروس یا کسی دوسرے ہوسٹ کے ری ڈائریکٹ URI پر لاگو کرنا تعیناتی بدلتا ہے، استثنا نہیں۔

ہر حد پر حقیقی فلو آزمائیں اور اسے کلائنٹ کی قسم سے موازنہ کریں۔ کام کرنے والا ری ڈائریکٹ یہ نہیں بتاتا کہ ٹوکن لے جانے والی ہر ٹانگ نے مطلوبہ تحفظ استعمال کیا، اور سبز VPN آئیکن اگلی درخواست کی اسکیم کے بارے میں کچھ نہیں بتاتا۔

متعلقہ مضامین