डेवलपर टूल · JWT डिकोडर
ID टोकन बनाम एक्सेस टोकन: ओपनID कनेक्ट JWT एक API कुंजी क्यों नहीं है
· पेजभूमि
जेडब्ल्यूटी शपथ प्रमाणीकरण
दोनों एक ही प्रदाता के JWT हो सकते हैं, फिर भी वे अलग-अलग प्रश्नों का उत्तर देते हैं। यह पोस्ट बताती है कि एक ID टोकन और एक एक्सेस टोकन में क्या होता है, किसे उनका उपभोग करना चाहिए, और डिकोडिंग द्वारा उन्हें अलग कैसे बताया जाए।
API उस टोकन को अस्वीकार कर देता है जो पूरी तरह से वैध दिखता है - क्योंकि यह कभी भी API के लिए नहीं था
एक API एक अच्छी तरह से निर्मित, सही ढंग से हस्ताक्षरित टोकन को अस्वीकार कर सकता है क्योंकि वह क्रेडेंशियल किसी अन्य उपभोक्ता और उद्देश्य के लिए जारी किया गया था। "यह एक JWT है" एक संभावित प्रारूप का वर्णन करता है, इसे हर जगह भेजने की अनुमति नहीं। ID टोकन और एक्सेस टोकन एक पहचान प्रवाह में विभिन्न प्रश्नों का उत्तर देते हैं।
ToolAcre डिबगिंग का समर्थन करने वाले हेडर और पेलोड पैटर्न को उजागर कर सकता है, लेकिन यह टोकन को प्रमाणित नहीं कर सकता है या ओपनID कनेक्ट प्रोफ़ाइल को मान्य नहीं कर सकता है। अंतिम वर्गीकरण दृश्य निरीक्षण के बजाय प्रदाता अनुबंध, जारी करने के प्रवाह और विश्वसनीय सत्यापन परिणाम से आना चाहिए।
ID-टोकन दावे पहचान के उपयोग का सुझाव दे सकते हैं; यह सामान्य डिकोडर ओपनID कनेक्ट प्रोफ़ाइल को मान्य नहीं करता है
एक ID टोकन उस क्लाइंट को प्रमाणीकरण जानकारी संप्रेषित करता है जिसने साइन-इन का अनुरोध किया है। प्रोफ़ाइल के आधार पर, दृश्यमान दावों में गैर, प्रमाणीकरण समय, प्रमाणीकरण विधियां या किसी अन्य टोकन से संबंधित हैश शामिल हो सकता है। वे फ़ील्ड सामान्य API प्राधिकरण अनुदान नहीं हैं।
डिकोडर `auth_time` को समय-आकार वाले फ़ील्ड के रूप में मानता है और अन्य नामों को एप्लिकेशन-विशिष्ट के रूप में प्रदर्शित करता है जब तक कि वे इसके मूल सात में से न हों। यह नॉन, `at_hash`, `amr` या क्लाइंट ऑडियंस शब्दार्थ को मान्य नहीं करता है। एक पठनीय पहचान पेलोड तब तक अविश्वसनीय रहता है जब तक ग्राहक इसे सही ढंग से सत्यापित नहीं कर लेता।
एक्सेस टोकन JWT या अपारदर्शी हो सकते हैं; केवल तीन-भाग वाले JWT ही इस डिकोडर में फिट होते हैं
एक एक्सेस टोकन एक प्राधिकरण प्रणाली के तहत एक संसाधन सर्वर पर कॉल को अधिकृत करता है। यह एक JWT या एक अपारदर्शी स्ट्रिंग हो सकती है। केवल तीन-भाग वाली हस्ताक्षरित आकृति ToolAcre के मार्ग में फिट बैठती है; एक अपारदर्शी टोकन में डिकोड करने के लिए कोई सामान्य क्लाइंट-साइड संरचना नहीं होती है और इसे इस टूल के माध्यम से मजबूर नहीं किया जाना चाहिए।
JWT एक्सेस टोकन दर्शकों और दायरे की जानकारी ले सकता है, लेकिन उन मूल्यों को प्रमाणित सत्यापन और संसाधन नीति की आवश्यकता होती है। ब्राउज़र पैनल एक संसाधन सर्वर को लागू नहीं करता है और यह नहीं बता सकता है कि कोई दायरा किसी विशेष ऑपरेशन की अनुमति देता है या नहीं।
टोकन ताज़ा करें - आम तौर पर अपारदर्शी, कभी भी डिकोड नहीं किया जाता है, और कभी भी API पर नहीं भेजा जाता है
ताज़ा टोकन प्रदाता नियमों के तहत प्रतिस्थापन पहुंच क्रेडेंशियल प्राप्त करने का समर्थन करता है। यह आमतौर पर अपारदर्शी है और संसाधन APआई के लिए अभिप्रेत नहीं है। यह एक उच्च-मूल्य वाला क्रेडेंशियल भी है, इसलिए इसे डिकोडर में चिपकाने से विश्वसनीय निदान लाभ के बिना जोखिम पैदा होता है।
यह निष्कर्ष न निकालें कि प्रत्येक टोकन-आकार का मान डिकोड किया जाना चाहिए। ताज़ा विफलताओं के लिए प्रदाता टूलींग और नियंत्रित लॉग का उपयोग करें। उत्पादन टोकन के खिलाफ ToolAcre की स्पष्ट चेतावनी यहां विशेष बल के साथ लागू होती है, और इसका तीन-खंड पार्सर कोई ताज़ा ऑपरेशन प्रदान नहीं करता है।
ऑडियंस अलग-अलग होती है - ID टोकन में क्लाइंट ID बनाम एक्सेस टोकन में संसाधन
दर्शक एक मजबूत सुराग है क्योंकि इच्छित उपभोक्ता भिन्न होता है। एक ID टोकन अक्सर क्लाइंट को लक्षित करता है, जबकि एक एक्सेस टोकन एक संसाधन को लक्षित करता है। सटीक पहचानकर्ता और प्रतिनिधित्व प्रदाता और प्रोफ़ाइल पर निर्भर करते हैं, इसलिए यह आलेख एक सार्वभौमिक स्ट्रिंग पैटर्न का आविष्कार नहीं करता है।
एक हेडर `typ` एक स्पष्ट लेबल भी प्रदान कर सकता है, लेकिन सत्यापन तक यह टोकन-नियंत्रित डेटा बना रहता है। ToolAcre केवल तभी चेतावनी देता है जब एक स्ट्रिंग `typ` `JWT` से भिन्न होती है; यह प्रत्येक प्रोफ़ाइल लेबल को नहीं पहचानता है या किसी को प्राधिकरण निर्णय में नहीं बदलता है।
व्यावहारिक उदाहरण: दृश्यमान फ़ील्ड को टोकन प्रकार का प्रमाण माने बिना उनकी तुलना करें
दो सिंथेटिक उदाहरणों को डिकोड करें: एक ग्राहक-उन्मुख प्रमाणीकरण दावों वाला और दूसरा संसाधन दर्शकों और दायरे वाला। `aud`, `typ` और पेलोड नामों में अंतर रिकॉर्ड करें। यह अभ्यास सिखाता है कि जारीकर्ता से क्या पूछना है, न कि उदाहरण की पहचान कैसे साबित करनी है।
एक निर्मित टोकन समान लेबल की प्रतिलिपि बना सकता है, और एक वास्तविक टोकन प्रदाता-विशिष्ट सम्मेलनों का उपयोग कर सकता है। जारी प्रतिक्रिया और दस्तावेज़ीकरण से प्रकार की पुष्टि करें, फिर इसे इच्छित उपभोक्ता के साथ सत्यापित करें। डिकोडर का आउटपुट साक्ष्य का समर्थन कर रहा है, निर्णायक प्राधिकारी नहीं।
इसमें क्या शामिल नहीं है - OAuth प्रवाह जो इन टोकन को जारी करता है, जो एक अलग विषय है
यह तुलना टोकन जारी करने वाले प्राधिकरण-कोड, डिवाइस या अन्य प्रवाह की व्याख्या नहीं करती है। इसमें प्रदाता-विशिष्ट सत्यापन चरण, अपारदर्शी एक्सेस-टोकन आत्मनिरीक्षण या ताज़ा रोटेशन भी शामिल नहीं है। वे विषय चयनित पारिस्थितिकी तंत्र और तैनाती पर निर्भर करते हैं।
तत्काल डिबगिंग प्रश्न को सीमित रखें: ग्राहक को कौन सा क्रेडेंशियल प्राप्त हुआ, उसका इच्छित उपभोक्ता कौन है, और कौन सा विश्वसनीय घटक इसे मान्य करता है? उन तीन प्रश्नों का उत्तर देने से सामान्य JWT आकृति को प्रोटोकॉल भूमिकाओं को मिटाने से रोका जा सकता है।
टेकअवे: भेजने से पहले ऑड देखें और टाइप करें - ToolAcre JWT डिकोडर आपको यह जांचने देता है कि आपके पास किस प्रकार का टोकन है
टोकन भेजने से पहले दर्शकों को देखें और टाइप करें, लेकिन सत्यापन सफल होने तक किसी भी फ़ील्ड पर भरोसा न करें। एक ID टोकन उसके ग्राहक सत्यापन सीमा पर होता है; एक एक्सेस टोकन इसके संसाधन सर्वर से संबंधित है। रिफ्रेश टोकन प्रदाता की रिफ्रेश प्रक्रिया में होता है, API पर नहीं।
ToolAcre सुरक्षित तीन-भाग वाले उदाहरणों को पढ़ने में मदद करता है और उन्हें वर्गीकृत या मान्य करने का कोई दावा नहीं करता है। संभावित गलतियों को पहचानने के लिए इसका उपयोग करें, फिर दस्तावेज़ प्रवाह और स्वतंत्र रूप से कॉन्फ़िगर किए गए सत्यापनकर्ता को क्रेडेंशियल का वास्तविक उद्देश्य स्थापित करने दें।