डेवलपर टूल · JWT डिकोडर
401 को डिबग करना: API को दोष देने से पहले डिकोड किए गए JWT में क्या जांचना चाहिए
· यह क्यों मायने रखती है
जेडब्ल्यूटी डिबगिंग प्रमाणीकरण
अधिकांश टोकन अस्वीकृतियों में कुछ दावा संबंधी समस्याएं आती हैं जिन्हें आप पेलोड को पढ़कर समझ सकते हैं। यह पोस्ट एक्सपायरी से लेकर ऑडियंस से लेकर कॉपी-पेस्ट त्रुटियों तक की जांच करने के लिए एक चेकलिस्ट देती है।
इसने कल काम किया - 401 जो बिना किसी कोड परिवर्तन के दिखाई देता है
एक 401 जो क्लाइंट कोड परिवर्तन के बिना दिखाई देता है, टोकन आयु, जारीकर्ता नीति, कुंजी रोटेशन, दर्शकों के चयन या क्षतिग्रस्त प्रतिलिपि में उत्पन्न हो सकता है। यह मानने के बजाय कि API नीचे है, साक्ष्य से शुरुआत करें। क्रेडेंशियल में हेरफेर करने से पहले प्रतिक्रिया विवरण और सहसंबंध पहचानकर्ताओं को सुरक्षित रखें।
केवल समाप्त हो चुकी, सिंथेटिक या उचित रूप से नियंत्रित प्रतिलिपि को डिकोड करें। ToolAcre संरचनात्मक और दावा सुराग उजागर कर सकता है, लेकिन यह प्रत्येक सर्वर अस्वीकृति की पहचान नहीं कर सकता क्योंकि इसमें कोई कुंजी, जारीकर्ता नीति या API लॉग नहीं है। चेकलिस्ट प्रश्नों को संक्षिप्त करती है; यह संसाधन सर्वर के फैसले को प्रतिस्थापित नहीं करता है।
त्रुटियों को पहले कॉपी करें - 'बियरर' उपसर्ग, अनुगामी नई पंक्तियाँ और काटे गए टोकन
पहले कॉपी किए गए मान की जांच करें. ToolAcre आसपास के रिक्त स्थान को ट्रिम करता है और एक केस-असंवेदनशील `Bearer ` उपसर्ग को हटाता है, जो एक सामान्य प्राधिकरण-हेडर पेस्ट को संभालता है। इसके बाद बिल्कुल तीन बिंदु-पृथक खंडों की आवश्यकता होती है। दावा विश्लेषण शुरू होने से पहले एक गलत गिनती काट-छांट, गलत टोकन फॉर्म या अतिरिक्त विराम चिह्न की ओर इशारा करती है।
एक खाली हेडर या पेलोड विशेष रूप से विफल हो जाता है। अमान्य Base64url, अमान्य UTF-8 और अमान्य JSON में अलग-अलग त्रुटियां हैं। वे भेद यह निर्धारित करने में मदद करते हैं कि क्या परिवहन ने टोकन को नुकसान पहुंचाया है। निरीक्षण को अवरुद्ध किए बिना हस्ताक्षर विकृत हो सकता है, लेकिन वह चेतावनी संभावित सत्यापन विफलता बनी रहती है जिसके लिए सर्वर-साइड पुष्टि की आवश्यकता होती है।
exp और nbf: प्रदर्शन को वैधता निर्णय में बदले बिना सेकंड-आधारित मानों का निरीक्षण करें
आगे संख्यात्मक `exp` और `nbf` मानों का निरीक्षण करें। ToolAcre सेकंड को 1,000 से गुणा करता है, UTC दिखाता है और ब्राउज़र घड़ी के सापेक्ष पहले की समाप्ति या भविष्य को लेबल करता है। तेरह-अंकीय मान से पता चल सकता है कि मिलीसेकंड वहाँ लिखे गए थे जहाँ सेकंड अपेक्षित थे।
प्रवर्तन के लिए इन लेबलों का प्रचार न करें. एक जाली टोकन भविष्य की समाप्ति का दावा कर सकता है, और सर्वर एक अलग घड़ी या छूट नीति का उपयोग कर सकता है। प्रदर्शन विश्वसनीय लॉग के साथ तुलना करने लायक अंकगणित की पहचान करता है; दावों की स्वीकृति को प्रभावित करने से पहले क्रिप्टोग्राफ़िक सत्यापन सफल होना चाहिए।
aud और iss - क्या यह टोकन इस API के लिए है, जारीकर्ता की ओर से यह API भरोसा करता है?
`aud` को API की नीति के तहत इच्छित प्राप्तकर्ता की पहचान करनी चाहिए, जबकि `iss` को विश्वसनीय जारीकर्ता संबंध से मेल खाना चाहिए। ToolAcre दोनों को डिकोड किए गए मानों के रूप में सूचीबद्ध करता है और उनके पंजीकृत अर्थों की व्याख्या करता है। यह उनकी तुलना API कॉन्फ़िगरेशन से नहीं करता है या जारीकर्ता स्ट्रिंग को कुंजी सेट से नहीं बांधता है।
एक विश्वसनीय जारीकर्ता URL और दर्शकों का नाम गढ़ा जा सकता है। हस्ताक्षर-सत्यापन सीमा को संरक्षित करने के बाद ही सर्वर की कॉन्फ़िगर अपेक्षाओं के साथ सटीक डिकोड किए गए मानों की तुलना करें। यदि कई सेवाएँ पहचान के बुनियादी ढांचे को साझा करती हैं, तो एक सेवा के लिए वैध टोकन को दूसरी सेवा में उपयोग करने से रोकने के लिए दर्शकों की जाँच विशेष रूप से महत्वपूर्ण है।
हेडर और दावों द्वारा टोकन प्रकार का सुझाव दिया जा सकता है, लेकिन डिकोडिंग उस वर्गीकरण को प्रमाणित नहीं कर सकती है
एक ID टोकन और एक एक्सेस टोकन दोनों तीन-भाग वाले जेडब्ल्यूटी की तरह दिख सकते हैं। हेडर `typ`, ऑडियंस, स्कोप और प्रोफ़ाइल-विशिष्ट दावे यह सुझाव दे सकते हैं कि आपके पास कौन सा है। ToolAcre एक अप्रत्याशित स्ट्रिंग `typ` के बारे में चेतावनी देता है, लेकिन यह OpenID कनेक्ट या OAuth टोकन वर्गीकरण को लागू नहीं करता है।
अपेक्षित टोकन प्रकार स्थापित करने के लिए जारीकर्ता दस्तावेज़ और क्लाइंट प्रवाह का उपयोग करें। किसी API को ID टोकन भेजना तब भी विफल हो सकता है, जब उसका हस्ताक्षर पहचान प्रदाता के लिए मान्य हो। डिकोडिंग निदान का समर्थन करता है; यह प्रकार के लेबल को प्रमाणित नहीं कर सकता या API प्राधिकार प्रदान नहीं कर सकता।
कुंजी रोटेशन के बाद बच्चा - एक वैध टोकन जो उस कुंजी को संदर्भित करता है जो अब सर्वर के पास नहीं है
कुंजी घुमाने के बाद, हेडर `kid` सर्वर के वर्तमान विश्वसनीय सेट से अनुपस्थित कुंजी को संदर्भित कर सकता है। पहचानकर्ता को पढ़ें, फिर सत्यापनकर्ता पर कैश और कुंजी-सेट लॉग का निरीक्षण करें। हेडर-प्रदत्त URL न लाएं या त्वरित समाधान के रूप में एम्बेडेड कुंजी सामग्री स्वीकार न करें।
यदि सत्यापनकर्ता अनुमत कुंजी का पता नहीं लगा पाता है, तो एक सही ढंग से हस्ताक्षरित टोकन अभी भी विफल हो सकता है, जबकि एक हमलावर किसी भी `kid` को असत्यापित हेडर में लिख सकता है। मान विश्वसनीय जारीकर्ता कॉन्फ़िगरेशन द्वारा बाधित एक लुकअप संकेत है, यह सबूत नहीं है कि किसी विशेष कुंजी पर विश्वास किया जाना चाहिए।
कारगर उदाहरण - ToolAcre JWT डिकोडर में चेकलिस्ट के माध्यम से अस्वीकृत टोकन चलाना
एक कार्यशील ट्राइएज के लिए, एक नियंत्रित अस्वीकृत टोकन लें, तीन खंडों की पुष्टि करें, त्रुटियों का निरीक्षण करें, फिर इसे संपादित किए बिना `exp`, `nbf`, `aud`, `iss`, `typ` और `kid` रिकॉर्ड करें। प्रत्येक फ़ील्ड की तुलना अनुरोध के लक्ष्य API और सत्यापनकर्ता के विश्वसनीय कॉन्फ़िगरेशन से करें। वास्तविक विफलता कैटेगरी के लिए सर्वर लॉग खुले रखें।
यदि सभी दृश्य मान अपेक्षित लगते हैं, तो यह निष्कर्ष न निकालें कि API गलत है। हस्ताक्षर में खराबी, गलत कुंजी सामग्री, निरस्त स्थिति या अदर्शित नीति अभी भी 401 की व्याख्या कर सकती है। ToolAcre का `signatureVerified` झूठा ही रहता है, भले ही JSON कितना भी साफ-सुथरा दिखाई दे।
इसमें क्या शामिल नहीं है और टेकअवे - एक डिकोडर आपको यह नहीं बता सकता कि हस्ताक्षर वैध है या नहीं; चेकलिस्ट दावा समस्याओं का पता लगाती है, और हस्ताक्षर विफलताओं के लिए सर्वर लॉग की आवश्यकता होती है
एक डिकोडर आपको यह नहीं बता सकता कि हस्ताक्षर वैध है या नहीं। इसकी दावा जांच सूची में कॉपी और पेलोड संबंधी समस्याएं पाई जाती हैं जो बिना चाबी के दिखाई देती हैं; हस्ताक्षर विफलताओं और आधिकारिक नीति निर्णयों के लिए सर्वर साक्ष्य की आवश्यकता होती है। एक डिकोड को कई में से एक नैदानिक अवलोकन के रूप में मानें।
सबसे तेज़ विश्वसनीय पथ का आदेश दिया गया है: प्रतिक्रिया संदर्भ को संरक्षित करें, टोकन आकार का निरीक्षण करें, समय इकाइयों की तुलना करें, फिर विश्वसनीय कॉन्फ़िगरेशन के साथ जारीकर्ता, दर्शकों, प्रकार और कुंजी पहचानकर्ता की तुलना करें। जब तक वास्तविक सत्यापनकर्ता क्रिप्टोग्राफी और नीति की पुष्टि नहीं कर देता तब तक विश्वास कम करना बंद करें।