डेवलपर टूल · JWT डिकोडर
सात पंजीकृत JWT दावे: आईएस, सब, एयूडी, एक्सपी, एनबीएफ, आईएटी और जेटीआई
· पेजभूमि
जेडब्ल्यूटी डेटा-प्रारूप प्रमाणीकरण
RFC 7519 परिभाषित अर्थों और प्रकारों के साथ सात दावा नाम सुरक्षित रखता है। यह पोस्ट प्रत्येक के बारे में बताती है, उनके पीछे स्ट्रिंगऑरयूआरआई और न्यूमेरिकडेट प्रकार, और पंजीकृत, सार्वजनिक और निजी दावे कैसे सह-अस्तित्व में हैं।
मुझे कौन से दावा नामों का उपयोग करना चाहिए? - डिज़ाइन प्रश्न का रजिस्ट्री उत्तर देती है
दावा नाम चुनना आंशिक रूप से एक अंतरसंचालनीयता निर्णय है। पंजीकृत नाम का पुन: उपयोग करने से पाठकों और पुस्तकालयों को एक स्थापित अर्थ मिलता है, जबकि एप्लिकेशन-विशिष्ट नामों के लिए स्थानीय दस्तावेज़ीकरण की आवश्यकता होती है। ToolAcre अपनी विवरण तालिका में सात मुख्य नामों को पहचानता है और अन्य दावों को शब्दार्थ बताए बिना दृश्यमान छोड़ देता है।
एक परिचित नाम स्वचालित रूप से भरोसेमंद नहीं होता है। डिकोडर टोकन में मौजूद किसी भी वस्तु को पढ़ता है और कभी भी उसके हस्ताक्षर को सत्यापित नहीं करता है। पंजीकृत शब्दावली मनुष्यों को डेटा वर्गीकृत करने में मदद करती है; केवल एक विश्वसनीय सत्यापनकर्ता ही यह स्थापित कर सकता है कि जारीकर्ता ने संरक्षित मूल्य की आपूर्ति की है।
आईएसएस और सब को स्ट्रिंग के रूप में प्रदर्शित किया जाता है; यह कार्यान्वयन StringOrURI सिंटैक्स को लागू नहीं करता है
`iss` पहचानता है कि टोकन का दावा किसने इसे जारी किया है, और `sub` पहचानता है कि यह किसके बारे में है या क्या है। ToolAcre दोनों का वर्णन करता है और उनके मान प्रदर्शित करता है, लेकिन इसका कार्यान्वयन StringOrURI व्याकरण को मान्य नहीं करता है या सेवा कॉन्फ़िगरेशन के साथ किसी भी फ़ील्ड की तुलना नहीं करता है।
एक सत्यापनकर्ता को अपेक्षित जारीकर्ता को विश्वसनीय कुंजी सामग्री से बांधना चाहिए और उस जारीकर्ता के नामस्थान के तहत विषय की व्याख्या करनी चाहिए। ज्ञात जारीकर्ता स्ट्रिंग को गढ़े हुए पेलोड में कॉपी करने से डिकोडर मूल स्थापित किए बिना विश्वसनीय दिखता है। क्रिप्टोग्राफ़िक सत्यापन के बाद ही इन फ़ील्ड का उपयोग करें।
aud - इच्छित प्राप्तकर्ता, एक स्ट्रिंग या सरणी के रूप में
`aud` इच्छित प्राप्तकर्ताओं का वर्णन करता है और लागू टोकन नियमों के तहत इसे एक मान या सूची के रूप में दर्शाया जा सकता है। ToolAcre की सामान्य दावा तालिका सरणियों को JSON पाठ के रूप में संरक्षित करती है लेकिन यह तय नहीं करती है कि वर्तमान सेवा उनमें दिखाई देती है या नहीं।
श्रोता प्रासंगिक है. वही प्रमाणित टोकन एक API के लिए उपयुक्त और दूसरे के लिए गलत हो सकता है। एक संसाधन सर्वर को विश्वसनीय कॉन्फ़िगरेशन में एक अपेक्षित पहचानकर्ता की आवश्यकता होती है और उसे टोकन को परिभाषित करने की अनुमति देने के बजाय एक बेमेल को अस्वीकार करना चाहिए जहां इसे स्वीकार किया जाना चाहिए।
exp, nbf और iat - तीन न्यूमेरिकडेट दावे जो एक टोकन को समय में बांधते हैं
`exp`, `nbf` और `iat` न्यूमेरिकडेट दावे हैं। ToolAcre युग के बाद से परिमित संख्याओं को सेकंड के रूप में मानता है, दिनांक प्रदर्शन के लिए 1,000 से गुणा करता है और ब्राउज़र घड़ी के सापेक्ष समाप्ति या उससे पहले लेबल करता है। यह छूट को परिभाषित नहीं करता है या सर्वर स्वीकृति को लागू नहीं करता है।
समाप्ति दावा की गई अंतिम सीमा को चिह्नित करती है, यह इस बात का प्रमाण नहीं है कि टोकन कभी वैध था। नॉट-बिफोर दावा की गई प्रारंभ सीमा को चिह्नित करता है, और इश्यू-एट दावा किए गए निर्माण समय को रिकॉर्ड करता है। प्रत्येक को एक पेलोड में जाली बनाया जा सकता है, इसलिए समय अंकगणित को एक विश्वसनीय प्रवाह में हस्ताक्षर सत्यापन का पालन करना होगा।
जेटीआई - रीप्ले डिटेक्शन और डिनालिस्ट के लिए एक विशिष्ट पहचानकर्ता
`jti` एक टोकन पहचानकर्ता है। सिस्टम रीप्ले ट्रैकिंग या निरस्तीकरण स्थिति के लिए एक प्रमाणित, उपयुक्त रूप से उत्पन्न पहचानकर्ता का उपयोग कर सकता है, लेकिन दावा अकेले कोई संपत्ति प्रदान नहीं करता है। ToolAcre इसे रीप्ले डिटेक्शन के लिए एक टोकन ID के रूप में वर्णित करता है और इसका सटीक मान प्रदर्शित करता है।
विशिष्टता, भंडारण और लुकअप व्यवहार जारीकर्ता और सत्यापनकर्ता वास्तुकला से संबंधित हैं। एक डिकोडर यह निर्धारित नहीं कर सकता है कि क्या किसी अन्य टोकन ने पहचानकर्ता का पुन: उपयोग किया है या क्या किसी अस्वीकृत सूची में यह शामिल है। इसे तब तक उम्मीदवार सहसंबंध मान के रूप में मानें जब तक कि आसपास का विश्वसनीय सिस्टम साक्ष्य उपलब्ध न करा दे।
ToolAcre डिस्प्ले में पंजीकृत विवरण और एप्लिकेशन-विशिष्ट दावे
कार्यान्वयन केवल व्याख्यात्मक पाठ के माध्यम से पंजीकृत नामों को अलग करता है। प्रत्येक पेलोड संपत्ति अभी भी `listClaims` द्वारा लौटाई जाती है; अज्ञात नामों को एक शून्य विवरण प्राप्त होता है और UI उन्हें एप्लिकेशन-विशिष्ट लेबल करता है। यह सार्वजनिक रजिस्ट्री से परामर्श नहीं करता है या निजी-नाम टकराव को नहीं रोकता है।
वह सीमा स्रोत द्वारा सिद्ध किए जाने से अधिक दावा करने से बचती है। टीमों को अपने निजी दावों का दस्तावेजीकरण करना चाहिए और अंतरसंचालनीयता के मामले में टकराव-प्रतिरोधी नाम चुनना चाहिए। डिकोडर में विवरण की अनुपस्थिति का अर्थ है "इस स्थानीय सात-नाम तालिका में नहीं," "अमान्य" या "अनदेखा करना सुरक्षित" नहीं।
व्यावहारिक उदाहरण - एक यथार्थवादी पेलोड को पढ़ना और प्रत्येक दावे को वर्गीकृत करना
`{"iss":"https://issuer.example","sub":"user-7","aud":["orders"],"exp":1717246800,"nbf":1717243100,"iat":1717243200,"jti":"demo-9","tenant":"north"}` पर विचार करें. ToolAcre तीन संख्यात्मक समय को फ़ॉर्मेट करते समय सात पंजीकृत फ़ील्ड और लेबल `tenant` एप्लिकेशन-विशिष्ट का वर्णन करता है।
यह वर्गीकरण पेलोड डिज़ाइन की समीक्षा करने में मदद करता है। यह URL, विषय, दर्शक, दिनांक, पहचानकर्ता या किरायेदार को प्रमाणित नहीं करता है। एक जाली टोकन वस्तु को हूबहू पुन: पेश कर सकता है। प्राधिकरण तर्क में केवल सत्यापित दावे फ़ीड करें, फिर उपभोक्ता सेवा के अपेक्षित मान लागू करें।
टेकअवे: पंजीकृत नामों का उपयोग तब करें जब वे फिट हों - ToolAcre JWT डिकोडर पेलोड दिखाता है ताकि आप देख सकें कि वास्तविक जारीकर्ता कौन सा दावा सेट करता है
पंजीकृत नामों का उपयोग तब करें जब उनके परिभाषित अर्थ उपयुक्त हों, क्योंकि पहचानने योग्य शब्दावली अनावश्यक अनुवाद को कम कर देती है। निजी फ़ील्ड को दस्तावेज़ीकृत और न्यूनतम रखें। `sub`, `aud` या किसी समय दावे को भिन्न स्थानीय अर्थ के साथ केवल इसलिए ओवरलोड न करें क्योंकि डाउनस्ट्रीम कोड पहले से ही उस कुंजी को पार्स करता है।
ToolAcre दिखा सकता है कि एक सुरक्षित टोकन में कौन से नाम हैं और उसके संख्यात्मक दावे कैसे प्रस्तुत होते हैं। यह किसी भी मूल्य को प्रमाणित नहीं कर सकता. डिकोडिंग का उपयोगी परिणाम समीक्षा के लिए एक सूची है; सत्यापन और नीति का उपयोगी परिणाम एक निर्णय है, और वे अलग रहते हैं।