TrendVidStream نے اپنا تمام authentication stack ایک rotating-refresh-token سسٹم پر منتقل کر دیا ہے جو چوری شدہ ٹوکن کو اس وقت پکڑ لیتا ہے جیسے ہی اسے دوبارہ استعمال کیا جائے۔ اس تبدیلی نے 30 دن کے JWT کو، جو کبھی حملہ آور کو آزادانہ گھومنے کی اجازت دیتا تھا، ایک مختصر مدت کے credential میں بدل دیا ہے جو فوری طور پر lock-out کا سبب بنتا ہے۔
ایک واحد ڈیٹا بریچ (breach) نے اس تبدیلی پر مجبور کیا: ایک پارٹنر SDK نے 30 دن کے JWT کو plain text میں cache کر لیا تھا، ایک حملہ آور نے اسے نکالا اور کسی دوسرے ملک سے اسے دوبارہ استعمال (replay) کیا، اور اس کا واحد حل signing key کو rotate کرنا تھا—ایک ایسا عمل جس نے ہر صارف کو log out کر دیا۔ اس واقعے نے کمپنی کی token security کو نئے سرے سے ترتیب دیا اور اب یہی ویڈیو اسٹریمنگ سروس کو طاقت فراہم کر رہا ہے۔
پرانا ماڈل کیوں ناکام ہوا
JWTs (JSON Web Tokens) خود مختار (self-contained)، دستخط شدہ (signed) بلاگز ہیں جو سرور کو ڈیٹا بیس کی تلاش کے بغیر درخواست کی تصدیق کرنے کی اجازت دیتے ہیں۔ یہ سہولت ایک قیمت چھپاتی ہے: اگر ایک ٹوکن ہفتوں تک برقرار رہتا ہے، تو اسے چرانے سے حملہ آور کو ہفتوں تک رسائی مل جاتی ہے۔ اس ڈیٹا بریچ میں، چوری شدہ ٹوکن اپنی 30 دن کی میعاد ختم ہونے تک کارآمد رہا کیونکہ اسے وقت سے پہلے منسوخ (invalidate) کرنے کا کوئی طریقہ نہیں تھا۔
Signing key کو rotate کرنا تمام ٹوکنز کو منسوخ کرنے کا واحد عالمی طریقہ ہے، لیکن یہ ہر صارف کو دوبارہ log in کرنے پر مجبور کرتا ہے، جس سے سروس میں خلل پڑتا ہے اور اعتماد کم ہوتا ہے۔ خامی JWT میں نہیں تھی بلکہ ایک واحد، طویل مدتی credential پر بھروسہ کرنے میں تھی۔
نئے ڈیزائن کا خلاصہ
TrendVidStream اب دو قسم کے ٹوکن جاری کرتا ہے:
- Access tokens – 15 منٹ کے لیے کارآمد؛ یہ ہر API call کے لیے ضروری permissions رکھتے ہیں۔
- Refresh tokens – ایک بار استعمال ہونے والے ٹوکنز جو ایک مختصر مدت کے access token کے بدلے ایک نیا جوڑا (pair) فراہم کرتے ہیں۔
جب کوئی کلائنٹ refresh token پیش کرتا ہے، تو سرور:
- ٹوکن کے signature اور claims کی تصدیق کرتا ہے۔
- چیک کرتا ہے کہ آیا ٹوکن پہلے ہی استعمال ہو چکا ہے۔
- اگر چیک کامیاب ہو جائے، تو ایک بالکل نیا refresh token اور ایک تازہ 15 منٹ کا access token جاری کرتا ہے۔
- پرانے refresh token کو "استعمال شدہ" (used) کے طور پر نشان زد کرتا ہے۔
اگر مرحلہ 2 ناکام ہو جائے—یعنی وہی ٹوکن دوسری بار ظاہر ہو—تو سرور اسے چوری کے سگنل کے طور پر لیتا ہے اور اس لاگ ان سیشن سے منسلک ٹوکنز کے پورے "خاندان" (family) کو منسوخ کر دیتا ہے۔ متاثرہ صارف اور حملہ آور دونوں کو دوبارہ log in کرنے پر مجبور کیا جاتا ہے، جس سے ڈیٹا بریچ کا دورانیہ کم ہو جاتا ہے۔
ٹوکن فیملیز کی ٹریکنگ
ہر ٹوکن کو ایک الگ ریکارڈ سمجھنے کے بجائے، سسٹم انہیں فیملیز میں گروپ کرتا ہے جو صارف کے لاگ ان ہونے پر شروع ہوتی ہیں۔ ہر rotation اس فیملی کا ایک نیا رکن تخلیق کرتی ہے۔ پروڈکشن میں استعمال ہونے والا SQLite schema درج ذیل چیزیں محفوظ کرتا ہے:
- family_id – پورے سیشن کے لیے ایک مستحکم شناختی نمبر (identifier)۔
- token_id – ہر refresh token کے لیے ایک منفرد شناختی نمبر۔
- generation – ڈیبگنگ (debugging) کے لیے مفید ایک کاؤنٹر۔
- used_at – اس وقت کا ٹائم اسٹیمپ (timestamp) جب ٹوکن کو ریڈیم کیا گیا۔
- revoked – ایک فلیگ (flag) جو سیٹ ہونے کی صورت میں پوری فیملی کو غیر فعال کر دیتا ہے۔
جب دوبارہ استعمال کا واقعہ (reuse event) پکڑا جاتا ہے، تو اس family_id کے لیے revoked فلیگ سیٹ کر دیا جاتا ہے، جس سے متاثرہ سیشن سے تعلق رکھنے والا ہر ٹوکن فوری طور پر منسوخ ہو جاتا ہے۔ یہ ایک خاموش ہائی جیکنگ کو ایک ہائی سگنل الرٹ میں بدل دیتا ہے جو لاگز (logs) میں ظاہر ہوتا ہے۔
تین عملی قواعد جو سسٹم کو قابل اعتماد رکھتے ہیں
پہلے signature کی تصدیق کریں اگر سرور signature کی تصدیق کرنے سے پہلے "کیا یہ پہلے استعمال ہوا ہے؟" چیک کرتا ہے، تو ایک حملہ آور ٹوکن آئی ڈیز کا اندازہ لگا کر بڑے پیمانے پر منسوخی (revocations) کا عمل شروع کر سکتا ہے۔ پہلے اصلیت کی تصدیق کرنا غیر ضروری denial-of-service حملوں کو روکتا ہے۔
گریس ونڈو (grace window) کی اجازت دیں موبائل ایپس اکثر ٹوکن کی میعاد ختم ہونے پر تیزی سے دو refresh درخواستیں بھیجتی ہیں۔ اگر سرور بہت زیادہ سخت ہو، تو دوسری درخواست کو دوبارہ استعمال کے طور پر نشان زد کر دیا جائے گا، جس سے ایک جائز صارف لاگ آؤٹ ہو جائے گا۔ چند سیکنڈ کا بفر ایک "استعمال شدہ" ٹوکن کو بھی نیا جوڑا فراہم کرنے کی اجازت دیتا ہے، جس سے race conditions کا مسئلہ حل ہو جاتا ہے۔
پورے بہاؤ (flow) کو row locking کے ساتھ ایک ٹرانزیکشن (transaction) میں رکھیں atomicity کے بغیر، دو بیک وقت آنے والی درخواستیں یہ سمجھ سکتی ہیں کہ وہ ٹوکن استعمال کرنے والی پہلی درخواست ہیں، جس سے ڈپلیکیٹ refresh tokens جاری ہو سکتے ہیں اور single-use کی ضمانت ٹوٹ سکتی ہے۔ ڈیٹا بیس ٹرانزیکشن جو ٹوکن رو (row) کو لاک کر دیتی ہے، اس بات کی ضمانت دیتی ہے کہ صرف ایک درخواست کامیاب ہو۔
حاصلِ کلام: refresh tokens کو ایک بار استعمال ہونے والا بنا کر اور دوبارہ استعمال پر نظر رکھ کر، ایک سسٹم ہر چوری شدہ credential کو ایک الارم میں بدل سکتا ہے، جس سے پورے پلیٹ فارم کو لاگ آؤٹ کیے بغیر صارفین کا تحفظ ممکن ہوتا ہے۔