DAT (Distributed Access Token)
DAT کے تعارف کا پس منظر
آج کل بہت سے سسٹم JWT اپناتے ہیں، لیکن اصل پروڈکشن ماحول میں درج ذیل ساختی حدود موجود ہیں۔
انہی مسائل کو حل کرنے کے لیے ایک نئی ٹوکن وضاحت، DAT، ڈیزائن کی گئی۔
🧩 سیکیورٹی وضاحتوں کا بکھراؤ اور نفاذ کی کمی
JWT، JWE جیسے انکرپشن معیارات فراہم کرتا ہے، لیکن ان کا استعمال لازمی نہیں ہے۔
نتیجتاً بہت سے ڈویلپمنٹ ماحول میں انکرپشن چھوڑ دی جاتی ہے یا غیر معیاری طریقوں سے ڈیٹا منتقل کیا جاتا ہے، جس سے سیکیورٹی کمزوریاں پیدا ہوتی ہیں۔
🔑 فکسڈ کی (Static Key) کے استعمال سے سیکیورٹی خطرات
دستخطی کی کی روٹیشن (Key Rolling) لازمی نہ ہونے کی وجہ سے اکثر ایک ہی کی طویل عرصے تک استعمال ہوتی رہتی ہے۔ کی چوری ہو جانے کی صورت میں یہ پورے سسٹم کی سیکیورٹی کے انہدام تک لے جا سکتا ہے؛ درحقیقت بڑی ای-کامرس سائٹس پر اسی وجہ سے سیکیورٹی واقعات پیش آ چکے ہیں۔
📉 اوور ہیڈ کی وجہ سے کارکردگی میں کمی
JWT ہر درخواست پر JSON پارسنگ کے عمل سے گزرتا ہے اور کافی CPU وسائل خرچ کرتا ہے۔ اعلیٰ کارکردگی کے متقاضی ماحول میں یہ پارسنگ لاگت پورے سسٹم کا بڑا رکاوٹ (bottleneck) بن سکتی ہے۔
DAT کا بنیادی فلسفہ
DAT اس اصول کے تحت ڈیزائن کیا گیا ہے کہ سیکیورٹی اختیاری نہیں بلکہ لازمی ہونی چاہیے، اور کارکردگی پر سمجھوتہ نہیں کیا جا سکتا۔
⚡ ہلکا اور تیز
DAT میں، جیسا کہ اوپر دکھایا گیا ہے، نقطے (.) سے الگ کیے گئے صرف پانچ فکسڈ فیلڈز ہوتے ہیں۔ فیلڈز کی ترتیب وضاحت میں طے شدہ ہے، اس لیے JSON پارسنگ کے بغیر صرف الگ کرنے والا نشان تلاش کر کے ہر قدر کاٹی جا سکتی ہے۔
🔐 لازمی سیکیورٹی
DAT ڈیٹا کی منتقلی کے دوران سادہ (Plain) اور خفیہ کردہ (Secure) علاقوں کو طبعی طور پر الگ رکھتا ہے۔
یہ لازمی بناتا ہے کہ حساس معلومات ہمیشہ خفیہ کی جائیں، اور پورا عمل سرٹیفکیٹ میں اعلان کردہ معیاری الگورتھمز (ECDSA، AES-GCM وغیرہ) سے محفوظ رہتا ہے۔
انکرپشن الگورتھم کا فیصلہ ٹوکن نہیں بلکہ سرٹیفکیٹ کرتا ہے۔ ٹوکن میں الگورتھم کی معلومات موجود ہی نہیں ہوتیں، اس لیے JWT کے alg ہیڈر سے پیدا ہونے والے الگورتھم کنفیوژن حملے کی کوئی سطح موجود نہیں۔
🔄 لازمی کی رولنگ
DAT سرٹیفکیٹ صرف ٹوکن کے اجراء اور میعاد ختم ہونے کا ہی نہیں بلکہ کی کے لائف سائیکل کا بھی براہ راست انتظام کرتا ہے۔
سرٹیفکیٹ میں "کب سے کب تک اجراء ممکن ہے" وضاحت کی سطح پر طے شدہ ہوتا ہے، لہٰذا وہ مدت گزر جانے پر اس سرٹیفکیٹ سے نئے ٹوکن نہیں بنائے جا سکتے۔ منتظم کی غفلت سے ایک ہی کی کئی سال تک استعمال ہوتے رہنے کی صورتحال ساختی طور پر پیدا ہی نہیں ہوتی۔
⏱️ اجراء کی مدت اور میعاد کی علیحدگی
"وہ مدت جس میں سرٹیفکیٹ ٹوکن جاری کر سکتا ہے" اور "جاری کردہ ٹوکن کے زندہ رہنے کی مدت" دو مختلف قدریں ہیں۔
اسی لیے سرٹیفکیٹ کے اجراء بند کر دینے کے بعد بھی پہلے سے جاری ٹوکنز اپنی پوری عمر مکمل کر لیتے ہیں، اور اسی دوران کلسٹر قدرتی طور پر اگلے سرٹیفکیٹ پر منتقل ہو جاتا ہے۔
توثیقی طریقہ کار کا موازنہ
| درجہ بندی | DAT | JWT | سیشن |
|---|---|---|---|
| توثیق کا طریقہ | تقسیم شدہ تصدیق | تقسیم شدہ تصدیق | مرکزی |
| ڈیٹا ڈھانچہ | Raw Bytes (فکسڈ آفسیٹ پر مبنی) | JSON (Key-Value ٹیکسٹ پر مبنی) | Serialized Object (آبجیکٹ سیریلائزیشن) |
| پارسنگ طریقہ کار | Byte ڈیٹا کی فوری میپنگ | JSON پارسنگ اور ٹائپ کاسٹنگ کی ضرورت | آبجیکٹ ڈی سیریلائزیشن اور I/O |
| پروسیسنگ کارکردگی | بہترین (پارسنگ اوور ہیڈ کم سے کم) | درمیانہ (JSON پروسیسنگ کی کارکردگی پر منحصر) | کم (نیٹ ورک/ڈسک I/O) |
| انکرپشن | بطور ڈیفالٹ شامل | الگ سے JWE کا نفاذ درکار (پیچیدہ) | قابلِ اطلاق نہیں |
| کی مینجمنٹ | سسٹم کی جانب سے لازمی رولنگ (لازمی سیکیورٹی) | خود نافذ کرنا پڑتا ہے (لاپرواہ انتظام کا خطرہ) | قابلِ اطلاق نہیں |
| کی کی میعاد | کی کی وضاحت میں لازمی طور پر درج | اختیاری (انتظام نہ ہونے پر مستقل) | مرکزی سرور کا انتظام |
| الگورتھم کا انتخاب | سرٹیفکیٹ طے کرتا ہے (ٹوکن میں نہیں) | ٹوکن ہیڈر کا alg | قابلِ اطلاق نہیں |
| میعاد ختم ہونے کا وقت | وضاحت کے مطابق لازمی فیلڈ | اختیاری کلیم (exp) | سرور انتظام کرتا ہے |
کارکردگی
اگلی دستاویزات
- DAT — ٹوکن کا وائر فارمیٹ اور معیاری اصول
- سرٹیفکیٹ — سرٹیفکیٹ کا ڈھانچہ، الگورتھمز اور لائف سائیکل
- CMS ہم آہنگی — سرٹیفکیٹ کی تقسیم اور آپریشن کے دوران جاننے کے قابل رویّہ