DAT (Distributed Access Token) ​

1. جائزہ ​

بیک وقت آن لائن صارفین کی تعداد بڑھنے کے ساتھ سیشنز (Session) کی تعداد بھی بڑھتی جاتی ہے اور سیشن سرور پر ضرورت سے زیادہ بوجھ پڑنے لگتا ہے۔

DAT ایک ایسی ٹوکن وضاحت ہے جو سیشن سرور کے اس بوجھ کے مسئلے کو حل کرنے اور سرورز کے درمیان حالت (State) شیئر کیے بغیر (Stateless) موثر توثیق کو ممکن بنانے کے لیے تیار کی گئی ہے۔

DAT نقطے (.) سے الگ کیے گئے 5 فکسڈ فیلڈز پر مشتمل ایک سٹرنگ ہے۔ JSON پارسنگ کے بغیر صرف الگ کرنے والے نشان کی جگہ سے ہر فیلڈ کاٹی جا سکتی ہے، اور میعاد ختم ہونے کا وقت اور خفیہ کردہ علاقہ خود وضاحت کا حصہ ہیں۔

2. وائر فارمیٹ ​

expire . cid . plain . secure . signature

2.1. فیلڈ کی تفصیلی وضاحت ​

میعاد ختم ہونے کا وقت : uint64 (Unix Time)

• ٹوکن کی میعاد ختم ہونے کا وقت سیکنڈز (Seconds) کی اکائی میں 64-بٹ بغیر علامت عدد صحیح کے طور پر ظاہر کرتا ہے۔
• صرف خالص اعشاری ہندسے قابلِ قبول ہیں۔ علامت، خالی جگہ یا کوئی الگ کرنے والا نشان شامل ہو تو یہ فارمیٹ کی خرابی ہے۔

CID : Hex (uint64)

• ٹوکن کی تصدیق کے لیے استعمال ہونے والا سرٹیفکیٹ ID (Certificate ID) ہے۔
• صرف خالص سولہ اعشاری ہندسے قابلِ قبول ہیں، اور 0x سابقہ استعمال نہیں ہوتا۔

سادہ ڈیٹا : Base64Url (Binary)

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

خفیہ کردہ ڈیٹا : Base64Url (Binary)

• کلائنٹ سے مخفی رکھے جانے والے ڈیٹا کو رکھتا ہے۔ یہ سرٹیفکیٹ کے انکرپشن الگورتھم سے خفیہ کیا گیا ہوتا ہے، اس لیے جس کلائنٹ کے پاس سرٹیفکیٹ نہیں وہ اس کے مواد کو ڈی کرپٹ نہیں کر سکتا۔
• اندرونی ڈھانچہ IV(96bit) + سائفر ٹیکسٹ ہے، اور IV ہر انکرپشن پر نئے سرے سے تیار ہوتا ہے۔

دستخط : Base64Url (Binary)

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

3. معیاری اصول (Canonical Rules) ​

مختلف زبانوں میں لکھے گئے کلائنٹس ایک ہی ٹوکن کی بالکل ایک جیسی تعبیر کریں، اس کے لیے ضروری ہے کہ نیچے دیے گئے اصول کسی بھی نفاذ میں مختلف نہ ہوں۔ حوالہ جاتی نفاذ Rust (dat-rust) ہے، اور باقی تمام نفاذات اسی اصول کے مطابق ترتیب دیے گئے ہیں۔

3.1. عددی فیلڈز کی پارسنگ ​

expire اور cid کی تعبیر سختی سے کی جاتی ہے۔ نیچے دیے گئے سب ان پٹ فارمیٹ کی خرابی کے طور پر مسترد کیے جاتے ہیں۔

3.2. میعاد ختم ہونے کا فیصلہ ​

DAT ٹوکن اور سرٹیفکیٹ کی میعاد کی حدیں ایک دوسرے سے مختلف ہیں۔ انہیں خلط ملط نہ کریں۔

ٹوکن میعاد کے وقت پہنچتے ہی فوراً غیر مؤثر ہو جاتا ہے، جبکہ سرٹیفکیٹ اسی وقت تک درست رہتا ہے۔ اس کی وجہ یہ ہے کہ سرٹیفکیٹ کو ٹوکن سے ایک ٹِک زیادہ زندہ رہنا چاہیے تاکہ حد پر جاری ہونے والے ٹوکن کی تصدیق ہو سکے۔

3.3. خالی secure پے لوڈ ​

اگر خفیہ کرنے کے لیے کوئی ڈیٹا نہ ہو تو secure ایک خالی سٹرنگ ہوتی ہے۔

• encrypt(خالی ان پٹ) → خالی آؤٹ پٹ (نہ IV لگتا ہے نہ GCM ٹیگ)
• decrypt(خالی ان پٹ) → خالی آؤٹ پٹ
• اگر خالی نہ ہو مگر IV کی لمبائی (12 بائٹس) سے کم یا برابر ہو تو یہ ڈی کرپشن کی خرابی ہے۔

1893456000.1a.SGVsbG8..T3RoZXItc2lnbmF0dXJl
                      ↑ secure کی جگہ خالی ہے — یہ ایک درست ٹوکن ہے

4. اجراء اور تصدیق ​

4.1. اجراء کا طریقہ کار ​

1. مینیجر کے پاس موجود سرٹیفکیٹس میں سے اجراء کے قابل (issuable) سرٹیفکیٹ چنا جاتا ہے۔
2. expire = now + dat_ttl_seconds شمار کیا جاتا ہے۔
3. plain کو Base64Url میں انکوڈ کیا جاتا ہے، اور secure کو خفیہ کرنے کے بعد Base64Url میں انکوڈ کیا جاتا ہے۔
4. expire.cid.plain.secure سٹرنگ پر دستخط کر کے اسے آخری فیلڈ کے طور پر جوڑ دیا جاتا ہے۔

4.2. تصدیق کا طریقہ کار ​

1. نقطے (.) سے 5 فیلڈز میں تقسیم کریں۔ فیلڈز کی تعداد مختلف ہو تو یہ فارمیٹ کی خرابی ہے۔
2. expire کی جانچ کریں۔ میعاد ختم شدہ ٹوکن دستخط کی تصدیق سے پہلے ہی مسترد کر دیا جاتا ہے۔
3. cid سے سرٹیفکیٹ تلاش کریں۔ اگر موجود نہ ہو تو تصدیق ممکن نہیں۔
4. expire.cid.plain.secure حصے پر دستخط کی تصدیق کریں۔
5. تصدیق کامیاب ہونے کے بعد ہی secure کو ڈی کرپٹ کریں۔

5. JWT سے موازنہ ​

DAT اور JWT (JSON Web Token) دونوں نقطے (.) سے الگ کیے گئے ٹوکن ڈھانچے اور دستخط کے ذریعے تصدیق کا طریقہ شیئر کرتے ہیں، لیکن اندرونی ڈیزائن میں درج ذیل اہم فرق ہیں۔

5.1. ساختی فرق کا موازنہ ​

• JWT ڈھانچہ

  header	body	signature
  Base64Url (JSON String)	Base64Url (JSON String)	Base64Url (Binary)

• DAT ڈھانچہ

  میعاد ختم ہونے کا وقت	CID	سادہ ڈیٹا	خفیہ کردہ ڈیٹا	دستخط
  Unixtime (uint64)	Hex (uint64)	Base64Url (Binary)	Base64Url (Encrypt Binary)	Base64Url (Binary)

5.2. اہم فرق ​

• Binary پر مبنی ہلکا پھلکا پن: JWT ہیڈر اور باڈی کو JSON سٹرنگ کی شکل میں ہینڈل کرتا ہے، جبکہ DAT بائنری (Binary) ڈیٹا کو براہ راست ہینڈل کر کے ڈیٹا کا حجم بہتر بناتا ہے اور پارسنگ کی کارکردگی بڑھاتا ہے۔
• سیکیورٹی کی اندرونی شمولیت (خفیہ کردہ ڈیٹا فیلڈ): JWT میں بنیادی طور پر پے لوڈ (Payload) سادہ متن میں ظاہر ہوتا ہے اور انکرپشن کی ضرورت پڑنے پر JWE جیسی الگ وضاحت لاگو کرنی پڑتی ہے۔ اس کے برعکس DAT خفیہ کردہ ڈیٹا فیلڈ کے ذریعے خود ٹوکن ہی میں انکرپشن کی صلاحیت سپورٹ کرتا ہے۔
• میعاد کی پابندی لازمی: JWT میں exp (Claims) فیلڈ اختیاری ہے، لیکن DAT میں میعاد ختم ہونے کا وقت فیلڈ ٹوکن کے ڈھانچے میں لازمی ہے، اس لیے میعاد کی تصدیق لازماً انجام پاتی ہے۔
• الگورتھم کی کوئی گفت و شنید نہیں: JWT ہیڈر کی alg قدر خود ٹوکن کے ساتھ لے کر چلتا ہے، جس سے الگورتھم کنفیوژن حملے کی سطح پیدا ہوتی ہے۔ DAT میں الگورتھم کا فیصلہ سرٹیفکیٹ کرتا ہے اور ٹوکن میں الگورتھم کی معلومات ہوتی ہی نہیں۔