JWT डिकोडर

JWT क्या है?#

एक JWT (JSON Web Token, RFC 7519 में परिभाषित) दो पक्षों के बीच claims लेकर जाने के लिए बना एक सघन, URL-सुरक्षित टोकन है। यह वह credential है जो आपका ब्राउज़र लॉगिन के बाद किसी API को भेजता है, वह identity assertion जो कोई OAuth प्रदाता किसी निर्भर अनुप्रयोग को देता है, और वह लिफ़ाफ़ा जिसमें अधिकांश आधुनिक session और access-control प्रवाह यात्रा करते हैं। आकर्षण यह है कि claims — उपयोगकर्ता कौन है, वह क्या कर सकता है, टोकन कब समाप्त होता है — JSON के रूप में टोकन के भीतर ही यात्रा करते हैं, इसलिए प्राप्तकर्ता सेवा बिना डेटाबेस लुकअप के उन्हें पढ़ सकती है।

एक JWT में ठीक तीन base64url-एन्कोडेड भाग बिंदुओं से अलग होते हैं: header.payload.signature। हेडर एल्गोरिदम और टोकन प्रकार नाम देता है। पेलोड claims का एक JSON ऑब्जेक्ट है — पंजीकृत claims जैसे sub (subject), iat (जारी समय), exp (समाप्ति), nbf (इसके बाद मान्य), साथ ही आपका अनुप्रयोग जो भी कस्टम claims जोड़ता है। हस्ताक्षर वह है जो जारीकर्ता ने अन्य दो भागों पर किसी secret या निजी कुंजी से गणना किया; इसके सत्यापन से ही सिद्ध होता है कि टोकन के साथ छेड़छाड़ नहीं हुई।

यह पेज एक JWT को डिकोड और निरीक्षण करता है। यह तीन भागों को विभाजित करता है, हेडर और पेलोड को base64url-डिकोड करके पठनीय JSON में लाता है, मानक समय claims को मानव-पठनीय टाइमस्टैम्प के रूप में सामने लाता है, और एक लाइव स्थिति बैज (मान्य, समाप्त, अभी मान्य नहीं) दिखाता है। यह जानबूझकर हस्ताक्षर सत्यापित नहीं करता — उसके लिए जारीकर्ता की secret या सार्वजनिक कुंजी चाहिए और वह एक 100% क्लाइंट-साइड टूल के दायरे से बाहर है। हस्ताक्षर खंड कच्चा, जैसा प्राप्त हुआ, दिखाया जाता है।

इसका उपयोग कैसे करें#

1. बाईं ओर इनपुट बॉक्स में अपना टोकन चिपकाएँ। इसमें तीन बिंदु-पृथक खंड होने चाहिए; इसके चारों ओर रिक्ति स्वचालित छँटती है।
2. यदि आप केवल लेआउट काम करते देखना चाहते हैं तो एक अंतर्निहित उदाहरण टोकन (iat/exp/nbf के साथ) लोड करने के लिए नमूना क्लिक करें।
3. इनपुट और परिणाम फलकों को खाली करने के लिए साफ़ करें क्लिक करें।
4. दायाँ पैनल पढ़ें:
   • शीर्ष पर स्थिति बैज — हरा मान्य, समाप्त, या अभी मान्य नहीं — वर्तमान समय के साथ तुलना में nbf और exp claims पर आधारित।
   • हेडर कार्ड (अपनी शीर्षक पट्टी में एल्गोरिदम के साथ, उदा. HS256)।
   • पेलोड कार्ड, JSON के रूप में सुंदर-प्रिंट।
   • समय-claims सूची — जारी समय, इसके बाद मान्य, समाप्ति — प्रत्येक एक Unix टाइमस्टैम्प और पठनीय तिथि दोनों के रूप में रेंडर।
   • हस्ताक्षर खंड, कच्चा दिखाया गया क्योंकि यह अभी भी base64url-एन्कोडेड बाइट्स हैं।
5. यदि टोकन विकृत है, तो लाल स्थिति पंक्ति बताती है कि यह तीन-खंड आकार जाँच, base64url डिकोड, या JSON पार्स में विफल रहा।

मुख्य विशेषताएँ#

• लाइव समय-claim स्थिति। iat, nbf, और exp पढ़ता है और बताता है कि टोकन वर्तमान में मान्य है, पहले ही समाप्त, या अभी प्रभावी नहीं — वे तीन प्रश्न जो आप एक लॉगिन बग के दौरान वास्तव में पूछते हैं।
• मानव-पठनीय तिथियाँ। 1700000000 जैसी Unix epoch संख्याएँ उन UTC तिथियों के बगल में दिखाई जाती हैं जिनका वे प्रतिनिधित्व करती हैं, इसलिए आप मानसिक epoch अंकगणित करना बंद कर देते हैं।
• एल्गोरिदम सामने। हेडर का alg मान हेडर कार्ड की शीर्षक पट्टी में खींचा जाता है, ताकि आप तुरंत देखें कि आपके पास HS256, RS256, या कुछ अप्रत्याशित है।
• UTF-8 सुरक्षित डिकोडिंग। Base64url खंड TextDecoder द्वारा बाइट्स के रूप में डिकोड होते हैं, इसलिए ग़ैर-ASCII claims (नाम, अन्य लिपियों में भूमिकाएँ) mojibake के बजाय सही रेंडर होते हैं।
• केवल डिकोड — कभी सत्यापित नहीं। टूल कभी secret नहीं माँगता, जो इसे ऐसे टोकन चिपकाने के लिए सुरक्षित बनाता है जिन पर आप पूरी तरह भरोसा नहीं करते: कुछ भी कहीं नहीं भेजा जाता, और हस्ताक्षर दिखाया जाता है किंतु जाँचा नहीं।

विस्तृत उदाहरण#

नमूना क्लिक करें और इनपुट एक टोकन से भरता है जिसका हेडर डिकोड होकर यह होता है:

{
  "alg": "HS256",
  "typ": "JWT"
}

और जिसका पेलोड डिकोड होकर यह होता है:

{
  "sub": "1234567890",
  "name": "ArpGate Demo",
  "iat": 1700000000,
  "exp": 4102444800,
  "nbf": 1699999000
}

समय-claims सूची तब दिखाती है:

Issued at   1700000000  (2023-11-14 22:13:20 UTC)
Not before  1699999000  (2023-11-14 21:56:40 UTC)
Expires     4102444800  (2100-01-01 00:00:00 UTC)

स्थिति बैज मान्य पढ़ता है, क्योंकि वर्तमान समय nbf के बाद और exp से पहले है। हस्ताक्षर खंड शाब्दिक स्ट्रिंग c2FtcGxlLXNpZ25hdHVyZS1ub3QtdmVyaWZpZWQ के रूप में दिखाया गया — जो “sample-signature-not-verified” पाठ में डिकोड होता है, एक जानबूझकर मार्कर कि इस टोकन का हस्ताक्षर उदाहरणमात्र है, कोई वास्तविक HMAC-SHA256 आउटपुट नहीं।

वह अंतिम बिंदु इस टूल के बारे में समझने के लिए सबसे महत्वपूर्ण बात है: एक टोकन जो साफ़ डिकोड होता है ज़रूरी नहीं कि भरोसेमंद टोकन हो। कोई भी हेडर और पेलोड जाली बना सकता है; केवल हस्ताक्षर, जारीकर्ता की secret या सार्वजनिक कुंजी के विरुद्ध जाँचा गया, प्रामाणिकता सिद्ध करता है। claims पढ़ने और समय खिड़कियों को डिबग करने के लिए इस पेज का उपयोग करें; हस्ताक्षर अपने वास्तविक बैकएंड में सत्यापित करें।

अक्सर पूछे जाने वाले प्रश्न#

क्या यह टूल मुझे बता सकता है कि कोई JWT प्रामाणिक है?#

नहीं, और वह डिज़ाइन से है। डिकोड केवल टोकन के भीतर के JSON को पढ़ता है — यह सिद्ध नहीं करता कि टोकन उसी द्वारा जारी किया गया जो जारी करने का दावा करता है। प्रामाणिकता सत्यापित करने के लिए आपको alg-उपयुक्त कुंजी (HS256 के लिए एक साझा secret, RS256/ES256 के लिए जारीकर्ता की सार्वजनिक कुंजी) और किसी भरोसेमंद बैकएंड पर एक सत्यापन दिनचर्या चाहिए। कभी भी साफ़ डिकोड किए गए टोकन को सत्यापित मान न लें।

स्थिति “समाप्त” दिखाती है। क्या मैं यहाँ टोकन ताज़ा कर सकता हूँ?#

नहीं। ताज़ा करने का अर्थ है एक नया एक्सेस टोकन पाने के लिए अपने प्रमाणीकरण सर्वर के refresh endpoint को बुलाना — एक नेटवर्क संक्रिया जो यह स्थैतिक, क्लाइंट-साइड पेज नहीं कर सकता और नहीं करना चाहिए। आप यहाँ कर सकते हैं वह यह पुष्टि करना कि पुराना टोकन ठीक कब समाप्त हुआ, जो आमतौर पर वह सुराग है जिसकी आपको आवश्यकता थी।

iat, nbf, और exp में क्या अंतर है?#

iat (जारी समय) वह है जब टोकन बनाया गया — सूचनात्मक। nbf (इसके बाद मान्य) वह सबसे जल्दी समय है जब टोकन स्वीकार किया जाना चाहिए; nbf से पहले एक सत्यापनकारी सर्वर इसे अस्वीकार करना चाहिए भले ही हस्ताक्षर मान्य हो। exp (समाप्ति) वह कठोर सीमा है जिसके बाद टोकन अस्वीकृत होना चाहिए। एक विधिवत टोकन में nbf ≤ iat ≈ अभी और exp निकट भविष्य में कहीं (एक्सेस टोकन के लिए मिनट, रिफ़्रेश टोकन के लिए अधिक) होता है।

मेरे पेलोड में ग़ैर-ASCII अक्षर हैं और वे और कहीं विकृत दिखते हैं। यहाँ सही क्यों हैं?#

क्योंकि कुछ डिकोडर गलती से प्रत्येक base64url अक्षर को एक बाइट मानते हैं बजाय पहले कच्चे बाइट्स में डिकोड करने के। यह पेज एक Uint8Array में डिकोड करता है और फिर इसे TextDecoder से चलाता है, जो बाइट्स को उचित UTF-8 के रूप में निर्वचन करता है। वही सही तरीका है, और इसीलिए किसी भी लिपि में नाम, भूमिकाएँ और scopes लिखे जैसे रेंडर होते हैं।