आपका JWT तुरंत क्यों समाप्त हो रहा है: exp सेकंड में है, मिलीसेकंड में नहीं

10:00 पर जारी किया गया, 10:00 पर समाप्त हो गया - एक टोकन इसके पहले उपयोग पर अस्वीकार कर दिया गया और एक सर्वर घड़ी जो समस्या नहीं थी

अपने पहले अनुरोध पर अस्वीकृत टोकन सर्वर गड़बड़ी के संदेह को आमंत्रित करता है, लेकिन घड़ियां बदलने से पहले कच्चे दावों का निरीक्षण करें। यदि एक घटक एक मिलीसेकंड घड़ी से `exp` उत्पन्न करता है जबकि दूसरा न्यूमेरिकडेट सेकंड की तुलना करता है, तो मान परिमाण के तीन क्रमों से भिन्न होते हैं। कोई भी सामान्य तुल्यकालन समायोजन उस अंतर की व्याख्या नहीं करता है।

थ्रोअवे या संशोधित टोकन का उपयोग करें क्योंकि धारक टोकन एक क्रेडेंशियल है। ToolAcre का JWT डिकोडर पेलोड डेटा पढ़ता है लेकिन जानबूझकर हस्ताक्षर सत्यापित नहीं करता है। मूल परीक्षण स्थिरता और उसके इच्छित जीवनकाल को संरक्षित करने के बाद ही संख्यात्मक समय दावे को टाइमस्टैम्प कन्वर्टर में कॉपी करें।

RFC 7519 क्या कहता है - NumericDate 1970-01-01T00:00:00Z के बाद से सेकंड के रूप में, और यह एक स्ट्रिंग के बजाय एक संख्या क्यों है

आसन्न प्रकाशित JWT लेख पहले से ही महत्वपूर्ण अनुबंध बताता है: `exp` NumericDate Unix युग से सेकंड की गणना करता है। इसके मानक स्पष्टीकरण को दोहराने से यहां कोई मूल्य नहीं जुड़ जाएगा। व्यावहारिक प्रश्न यह है कि क्या प्रत्येक निर्माता, क्रमबद्धकर्ता, सत्यापनकर्ता और परीक्षण स्थिरता समान पैमाने का सम्मान करते हैं।

स्पष्ट सीमा कोड देखें: जारी करते समय एक मिलीसेकंड घड़ी को सेकंड में विभाजित किया जाता है, और सत्यापन करते समय एक सेकंड की तुलना की जाती है। दावा अंकगणित के लिए उपयोग की जाने वाली स्वरूपित तारीख के बजाय एक संख्या ही रहना चाहिए। मानव-पठनीय UTC एक नैदानिक ​​प्रक्षेपण है, टोकन का आधिकारिक प्रतिनिधित्व नहीं।

इस अनुबंध को जारीकर्ता और सत्यापनकर्ता परीक्षणों में गैर-शून्य मान के साथ पिन करें। युग शून्य का उपयोग करने वाला परीक्षण यह नहीं बता सकता कि किसी भी पक्ष को एक हजार से विभाजित किया गया है या गुणा किया गया है।

मौजूदा JWT आलेख न्यूमेरिकडेट सेकंड स्थापित करता है; यह आलेख उस तथ्य को एक्सपायरी डिबगिंग पर लागू करता है

यदि कोई सत्यापनकर्ता वैध सेकंड दावे को मिलीसेकंड के रूप में व्याख्या करता है, तो तारीख 1970 के करीब आती है और समाप्त हो जाती है। यदि कोई जारीकर्ता वर्तमान मिलीसेकंड मान को किसी फ़ील्ड में लिखता है जिसे बाद में सेकंड के रूप में व्याख्या किया जाता है, तो समाप्ति इच्छित जीवनकाल से कहीं आगे या लाइब्रेरी की समर्थित सीमा से परे चली जाती है। कौन सा लक्षण प्रकट होता है यह पहचानता है कि स्केल त्रुटि किस पक्ष की है।

ऐसे "फिक्स" से बचें जो अंकों की गिनती के आधार पर दोनों रूपों को स्वीकार करता है। यह विकृत टोकन को एक स्थायी वैकल्पिक प्रोटोकॉल में बदल देता है और जारीकर्ता प्रतिगमन को छिपा सकता है। उन मानों को अस्वीकार करें जो एप्लिकेशन के न्यूमेरिकडेट अनुबंध का उल्लंघन करते हैं, पीढ़ी को सही करते हैं, और ऐसे फिक्स्चर जोड़ते हैं जो सेकंड को मिलीसेकंड से अलग करते हैं।

मिलीसेकंड की गलतियाँ तत्काल अस्वीकृति या अविश्वसनीय रूप से दूरस्थ समाप्ति का कारण बन सकती हैं, यह इस बात पर निर्भर करता है कि कौन सा पक्ष गलत है

किसी फ़्रेमवर्क द्वारा उन्हें परिवर्तित करने से पहले `exp`, `iat` और `nbf` को कच्चे मान के रूप में उजागर करने के लिए पेलोड को डीकोड करें। `exp − iat` की तुलना सेकंड में इच्छित टोकन जीवनकाल से करें। `nbf` को अलग से जांचें; एक टोकन समाप्त नहीं हो सकता है फिर भी उपयोग योग्य नहीं है। उचित दिखने वाले समय से प्रामाणिकता का अनुमान न लगाएं।

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

कार्यान्वित उदाहरण: 1700003600 का एक व्यय - इसे UTC और स्थानीय समय में परिवर्तित करना, इसे IAT के विरुद्ध जांचना, और जीवनकाल की पुष्टि करना वही है जो आप चाहते थे

`iat = 1,700,000,000` और `exp = 1,700,003,600` के लिए, घटाने पर 3,600 सेकंड या एक घंटा मिलता है। कन्वर्टर समाप्ति को स्पष्ट रूप से सेकंड के रूप में पढ़ता है और `2023-11-14T23:13:20.000Z` लौटाता है; समस्या का समय `2023-11-14T22:13:20.000Z` है।

वे संख्याएँ इस लेख के नैदानिक ​​उदाहरण के लिए अद्वितीय हैं। यदि मिलीसेकंड का चयन करने से जनवरी 1970 रीडिंग उत्पन्न होती है, तो यह गलत पैमाने का अपेक्षित प्रमाण है। पुष्टि करें कि एक घंटे की नीति सही ढंग से लागू होने से पहले सत्यापनकर्ता का वर्तमान समय भी सेकंड में व्यक्त किया गया है।

फ़ॉर्मेटिंग से पहले एक घंटे के अंतर की गणना की जाती है, इसलिए यह प्रत्येक क्षेत्र में एक घंटा रहता है। स्थानीय डिस्प्ले भिन्न हो सकते हैं, लेकिन `exp − iat` नहीं।

कार्यान्वित उदाहरण: स्पष्ट सेकंड का उपयोग करके exp 1,700,003,600 की नजदीकी आईएटी से तुलना करें

एक सत्यापनकर्ता मामूली घड़ी अंतर को समायोजित करने के लिए समय के दावों के आसपास एक छोटे से एप्लिकेशन-परिभाषित सहिष्णुता की अनुमति दे सकता है। यह भंडार सेकंड की अनुशंसित संख्या को परिभाषित नहीं करता है, इसलिए यहां कोई सार्वभौमिक छूट निर्धारित नहीं है। सुरक्षा नीति और पुस्तकालय विन्यास प्राधिकारी हैं।

सहनशीलता एक हजार के कारक के सापेक्ष छोटी रहनी चाहिए। जब तक कोई विकृत दावा पास नहीं हो जाता तब तक इसका विस्तार करना समाप्ति प्रवर्तन को कमजोर करता है और जारीकर्ता बग को जीवित छोड़ देता है। सबसे पहले घड़ी इकाइयों और सिंक्रनाइज़ेशन को सामान्य करें; फिर तय करें कि क्या एक सीमित भत्ता एप्लिकेशन के खतरे के मॉडल को पूरा करता है।

यदि कोई सहिष्णुता कॉन्फ़िगर की गई है, तो सेकंड में उस सीमा के अंदर और बाहर मूल्यों का परीक्षण करें। यह किसी भी दिनांक या स्थान प्रतिपादन से स्वतंत्र रूप से नीति सिद्ध करता है।

सहनशीलता-1,000 बेमेल कारक की मरम्मत नहीं कर सकती

टाइमस्टैम्प रूपांतरण किसी टोकन के हस्ताक्षर, अनुमत एल्गोरिदम, कुंजी, जारीकर्ता या दर्शकों को सत्यापित नहीं कर सकता है। यहां तक ​​कि एक पूरी तरह से स्वरूपित, भविष्य का `exp` दावा भी जाली टोकन के अंदर हो सकता है। JWT डिकोडर इस सीमा के बारे में जानबूझकर पारदर्शी है और इसे एक विश्वसनीय सत्यापनकर्ता के साथ जोड़ा जाना चाहिए।

यह यह भी स्थापित नहीं कर सकता है कि कैप्चर किए गए उत्पादन टोकन को रद्द कर दिया गया है या क्या सत्र नीति इसकी नाममात्र समाप्ति को ओवरराइड करती है। गैर-संवेदनशील फिक्स्चर के साथ डीबग मान। यदि किसी वास्तविक घटना के लिए क्रेडेंशियल्स की जांच की आवश्यकता होती है, तो सामान्य क्लिपबोर्ड वर्कफ़्लो के बजाय अधिकृत वातावरण और हैंडलिंग प्रक्रिया का उपयोग करें।

नियमित डिबगिंग के दौरान डिकोडिंग केवल सिंथेटिक या सुरक्षित रूप से संशोधित फिक्स्चर के साथ होनी चाहिए। लाइव बियरर क्रेडेंशियल की प्रतिलिपि बनाने से टाइमस्टैम्प अंकगणित से असंबंधित एक सुरक्षा समस्या उत्पन्न होती है।

टेकअवे: क्स्प दस अंकों का है, तेरह नहीं - और कैसे JWT डिकोडर और Unix टाइमस्टैम्प कन्वर्टर एक ही टैब में बैठते हैं ताकि आप सेकंड में दावे की जांच कर सकें

JWT समय के दावों को प्रत्येक सीमा पर सेकंड के रूप में मानें और अवधि के रूप में उनके अंतर का परीक्षण करें। टाइमस्टैम्प कन्वर्टर एक व्यक्तिगत दावे को UTC और स्थानीय संदर्भ में बदल देता है; JWT डिकोडर कच्चे नंबर को उजागर करता है। साथ में वे विश्वास का दावा किए बिना समय की व्याख्या करते हैं।

टिकाऊ सुधार जारी करने और सत्यापन कोड में होता है, न कि समर्थन रनबुक में जो टोकन के काम करने तक इकाइयों को टॉगल करता है। स्पष्ट सेकंड सुरक्षित रखें, विकृत पैमाने को अस्वीकार करें और हस्ताक्षर सत्यापन को एक अलग अनिवार्य निर्णय के रूप में रखें।

उस पृथक्करण से अवलोकन क्षमता में भी सुधार होता है: जेनरेशन लॉग टोकन को उजागर किए बिना अवधि नीति की रिपोर्ट कर सकते हैं, जबकि सत्यापन मेट्रिक्स समाप्त हो चुके, समय से पहले और अमान्य-हस्ताक्षर परिणामों को अलग कर सकते हैं।