شیڈول شدہ کام یا انسانی لاگ اِن: API کو کون سی شناخت دیکھنی چاہیے؟

شیڈول شدہ کام اور لاگ اِن پرامپٹ پر کھڑا شخص ایک ہی API کو مختلف اسناد، مختلف عمر اور مختلف مالکان کے ساتھ پکارتے ہیں۔ کام کو نیٹ ورک راستہ، ایپلیکیشن شناخت اور اجازتوں کا مجموعہ درکار ہے؛ شخص کو لاگ اِن، دوسرا عنصر اور سیشن درکار ہے۔ دونوں کو ملانا ایسی خودکاری پیدا کرتا ہے جو شخص کا پاس ورڈ بدلنے پر ٹوٹ جاتی ہے، یا ایسی کثیر عنصری پالیسی جو cron کام کو زندہ رکھنے کے لیے بالکل اتنی ہی کمزور کی گئی ہو۔

ایک جیسے دکھنے والے تین دروازے

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

اسی لیے ایگریس نوڈ بدلنے سے ماخذ پتے کی وجہ سے ملنے والی مستردگی ٹھیک ہو سکتی ہے اور غلط ٹوکن اچھوتا رہ سکتا ہے۔ اسی لیے درست API ٹوکن بھی اس کام سے نجی اینڈ پوائنٹ تک رسائی نہیں بناتا جس کا وہاں کوئی راستہ نہیں۔

تفاعلی راستہ خودکاری کے لیے برا سانچہ ہے

کسی شخص کا لاگ اِن اسکرپٹ میں لکھنا دلکش ہے کیونکہ یہ ایک بار چلتا ہے۔ اسکرپٹ پاس ورڈ، شاید یک بار پاس ورڈ کا بیج محفوظ کرتی ہے، اور پھر ایسے چیلنج پر منحصر ہوتی ہے جو انسان کا تقاضا کرنے کے لیے بنایا گیا ہو۔ OAuth کے لیے موجودہ بہترین سیکیورٹی عمل، RFC 9700، resource-owner-password-credentials گرانٹ کو ممنوع قرار دیتا ہے اور بتاتا ہے کہ یہ دو عنصری اور کثیر مرحلہ توثیق کے ساتھ کیوں بری طرح بیٹھتا ہے۔

معاون متبادل عام طور پر خفیہ کلائنٹ کا بہاؤ ہے جس میں اجازت سرور ایپلیکیشن کی توثیق کرتا ہے اور ٹوکن جاری کرتا ہے۔ RFC 6749 کے حصہ 4.4 میں client-credentials گرانٹ اس کی ایک مثال ہے۔ اس کا ہونا یہ معنی نہیں رکھتا کہ ہر API اسے قبول کرتا ہے، یا صارف کے تفویض کردہ کام کو اس سے بدلا جا سکتا ہے، کیونکہ یہ خدمات کے مالک سے سوالات ہیں۔ کوڈ لکھنے سے پہلے پوچھیں کہ خدمت کون سا بلا نگرانی ماڈل معاون ہے۔

VPN اب بھی کہاں موزوں ہے

VPN وہ نیٹ ورک راستہ مہیا کر سکتا ہے جو نجی API کا تقاضا ہے، اور یہ جائز کردار ہے۔ یہ کام کی ایپلیکیشن کے سامنے توثیق نہیں کرتا، اور یہ طے نہیں کرتا کہ کام کیا کر سکتا ہے۔ مشترکہ ایگریس پتہ بھی کام کی نہیں بلکہ میزبان کی شناخت کرتا ہے، اس لیے اس پتے کے لیے اجازت فہرست میں اندراج اس پر چلنے والے ہر عمل کو گزرنے دیتا ہے۔

اگر کام مشترکہ رنر پر چلتا ہے، تو یہ فرق کم نہیں بلکہ زیادہ اہم ہے۔ اسی میزبان پر دوسرا ورک فلو راستہ اور پتہ ورثے میں لیتا ہے، اور API دونوں میں فرق نہیں کر سکتا۔ یہ مشترکہ پاس ورڈ جیسی ہی کمزوری ہے، ایک تہہ نیچے سرکائی گئی۔ پابندی وہاں رکھیں جہاں ایپلیکیشن اسے نافذ کر سکے، اور اگر اجازت فہرست مزید تنگ نہیں کر سکتے تو رنر کو الگ رکھیں۔

دونوں ڈیزائنوں کا ایمانداری سے موازنہ کریں

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

اگر دونوں جواب ہاں ہیں، تو ڈیزائن کو اُدھار لیا گیا پاس ورڈ نہیں بلکہ تفویض ماڈل درکار ہے۔ وہ فیصلہ وہاں لکھیں جہاں اگلا نگہبان اسے پائے۔

حوالگی سے پہلے کیا تصدیق کریں

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

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

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