DAT (Distributed Access Token) ​

DAT को अपनाने की पृष्ठभूमि ​

आज बहुत-से सिस्टम JWT अपना रहे हैं, लेकिन वास्तविक उत्पादन परिवेश में निम्नलिखित संरचनात्मक सीमाएँ मौजूद हैं।
इन्हें हल करने के लिए ही एक नया टोकन विनिर्देश, DAT, डिज़ाइन किया गया।

🧩 सुरक्षा विनिर्देश का विखंडन और अनिवार्यता का अभाव ​

JWT, JWE जैसे एन्क्रिप्शन मानक उपलब्ध कराता है, परंतु उनका उपयोग अनिवार्य नहीं है।
इसके कारण कई विकास परिवेशों में एन्क्रिप्शन को छोड़ दिया जाता है या डेटा को गैर-मानक तरीकों से भेजा जाता है, जिससे सुरक्षा कमज़ोरियाँ पैदा होती हैं।

🔑 स्थिर कुंजी (Static Key) के उपयोग से उत्पन्न सुरक्षा जोखिम ​

हस्ताक्षर कुंजी का रोटेशन (Key Rolling) अनिवार्य न होने के कारण एक ही कुंजी को लंबे समय तक इस्तेमाल करने के मामले अक्सर होते हैं। कुंजी चोरी हो जाने पर यह पूरे सिस्टम की सुरक्षा के ढहने तक ले जा सकता है, और वास्तव में बड़ी कॉमर्स साइटों पर इसी कारण से उल्लंघन की घटनाएँ हो चुकी हैं।

📉 ओवरहेड के कारण प्रदर्शन में गिरावट ​

JWT हर अनुरोध पर JSON पार्सिंग की प्रक्रिया से गुज़रता है और काफ़ी CPU संसाधन खर्च करता है। उच्च प्रदर्शन की माँग वाले परिवेशों में यह पार्सिंग लागत पूरे सिस्टम का अवरोध बिंदु बन सकती है।

DAT का मूल दर्शन ​

DAT इस सिद्धांत के तहत डिज़ाइन किया गया है कि सुरक्षा विकल्प नहीं बल्कि अनिवार्यता होनी चाहिए, और प्रदर्शन से समझौता नहीं किया जा सकता।

⚡ हल्का और तेज़ है ​

DAT में, जैसा ऊपर दिखाया गया है, बिंदु (.) से विभाजित केवल पाँच निश्चित फ़ील्ड होते हैं। फ़ील्ड की स्थिति विनिर्देश में तय होने के कारण JSON पार्सिंग के बिना, केवल विभाजक ढूँढ़कर प्रत्येक मान को काटा जा सकता है।

🔐 अनिवार्य की गई सुरक्षा ​

DAT डेटा भेजते समय सादे (Plain) और एन्क्रिप्टेड (Secure) क्षेत्रों को भौतिक रूप से अलग करता है।
यह अनिवार्य करता है कि संवेदनशील जानकारी अवश्य एन्क्रिप्ट हो, और पूरी प्रक्रिया प्रमाणपत्र में घोषित मानक एल्गोरिदम (ECDSA, AES-GCM आदि) से सुरक्षित रहती है।

एन्क्रिप्शन एल्गोरिदम टोकन नहीं, बल्कि प्रमाणपत्र तय करता है। टोकन में एल्गोरिदम की जानकारी होती ही नहीं, इसलिए JWT के alg हेडर से उत्पन्न होने वाले एल्गोरिदम कन्फ़्यूज़न हमले का कोई सतह-क्षेत्र मौजूद नहीं है।

🔄 अनिवार्य की गई की रोलिंग ​

DAT प्रमाणपत्र केवल टोकन के जारी होने और समाप्त होने का ही नहीं, बल्कि कुंजी के जीवनचक्र का भी सीधे प्रबंधन करता है।
प्रमाणपत्र में विनिर्देश के स्तर पर ही यह अंकित रहता है कि "कब से कब तक जारी किया जा सकता है", इसलिए वह अवधि बीत जाने पर उस प्रमाणपत्र से नया टोकन नहीं बनाया जा सकता। प्रशासक की लापरवाही से एक ही कुंजी को कई वर्षों तक इस्तेमाल करते रहने की स्थिति संरचनात्मक रूप से उत्पन्न ही नहीं होती।

⏱️ जारी करने की अवधि और वैधता अवधि का पृथक्करण ​

"वह अवधि जिसमें प्रमाणपत्र टोकन जारी कर सकता है" और "वह अवधि जिसमें जारी किया गया टोकन जीवित रहता है" — ये दोनों अलग-अलग मान हैं।
इसकी बदौलत प्रमाणपत्र द्वारा जारी करना बंद कर देने के बाद भी पहले से जारी टोकन अपना पूरा जीवनकाल पूरा कर सकते हैं, और उसी बीच क्लस्टर स्वाभाविक रूप से अगले प्रमाणपत्र पर चला जाता है।

प्रमाणीकरण तंत्रों की तुलना ​

प्रदर्शन ​

अगले दस्तावेज़ ​

• DAT — टोकन का वायर फ़ॉर्मैट और कैनोनिकल नियम
• प्रमाणपत्र — प्रमाणपत्र संरचना, एल्गोरिदम, जीवनचक्र
• CMS सिंक — प्रमाणपत्र वितरण और संचालन के समय जानने योग्य व्यवहार