JWT क्या है? JSON Web Token समझें

JWT के तीन हिस्से

JWT डॉट से अलग किए तीन Base64URL-एन्कोडेड सेगमेंट हैं: header.payload.signature। Base64URL यानी URL-सेफ़ कैरेक्टर वाला और बिना पैडिंग का Base64, ताकि टोकन हेडर, क्वेरी स्ट्रिंग और कुकी में जा सके।

• हेडर — टोकन टाइप और साइनिंग एल्गोरिदम बताने वाला JSON, जैसे {"alg": "HS256", "typ": "JWT"}। इसमें kid (key id) भी हो सकता है जो वेरिफ़ायर को बताता है कौन-सी key इस्तेमाल करनी है।
• पेलोड — JSON ऑब्जेक्ट के रूप में क्लेम। यहाँ कुछ भी रखा जा सकता है, लेकिन यह सिर्फ़ एन्कोडेड है, एन्क्रिप्टेड नहीं: जिसके पास टोकन है वह इसे पढ़ सकता है।
• सिग्नेचर — हेडर में बताए एल्गोरिदम से एन्कोडेड हेडर और पेलोड पर कैलकुलेट किया जाता है। HS256 शेयर्ड सीक्रेट (HMAC) इस्तेमाल करता है; RS256 और ES256 साइन करने के लिए प्राइवेट key और वेरिफ़ाई करने के लिए पब्लिक key।

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiI0MiIsIm5hbWUiOiJMYXlsYSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTc1NjcwMDAwMCwiZXhwIjoxNzU2NzAzNjAwfQ
.4l3Y2cYpXqZ0cVZ5m4Q8n1fGx0y8s3oT0kq4rV7cWvA

header  → {"alg":"HS256","typ":"JWT"}
payload → {"sub":"42","name":"Layla","role":"admin","iat":1756700000,"exp":1756703600}

आज़माएँ: JWT डिकोडर

स्टैंडर्ड क्लेम और उनका मतलब

• iss (issuer) — टोकन किसने बनाया, आमतौर पर ऑथ सर्वर का URL।
• sub (subject) — टोकन किसके बारे में है, आमतौर पर यूज़र id।
• aud (audience) — टोकन किस सर्विस के लिए है। वेरिफ़ायर को दूसरे audience के टोकन रिजेक्ट करने चाहिए।
• exp (expiration) — Unix टाइमस्टैम्प जिसके बाद टोकन अमान्य है। छोटी लाइफ़टाइम (एक्सेस टोकन के लिए मिनट) लीक का नुक़सान सीमित करती है।
• nbf (not before) और iat (issued at) — टाइमस्टैम्प जो बताते हैं टोकन कब वैध हुआ और कब बना।
• jti (JWT id) — यूनिक id, replay पकड़ने या किसी खास टोकन को रद्द करने के लिए।
• कस्टम क्लेम — रोल, परमिशन, tenant id, ईमेल। इन्हें छोटा रखें: टोकन हर रिक्वेस्ट के साथ जाता है।

आज़माएँ: JWT क्लेम एनालाइज़र आज़माएँ: JWT एक्सपायरेशन चेकर

डिकोड करना वेरिफ़ाई करना नहीं है

JWT डिकोड करने का मतलब है हेडर और पेलोड को Base64URL-डिकोड करके पढ़ना। यह कोई भी बिना किसी key के कर सकता है — इसीलिए डिकोड किए पेलोड पर अकेले कभी भरोसा नहीं करना चाहिए। वेरिफ़ाई करने का मतलब है सही key और एल्गोरिदम से सिग्नेचर दोबारा कैलकुलेट करके मिलान की पुष्टि करना, फिर exp, nbf, iss और aud जाँचना।

डिबगिंग के दौरान टोकन पढ़ने के लिए ऑनलाइन डिकोडर सही टूल है: देखना कि वह किस यूज़र का नाम लेता है, कौन-से रोल रखता है और कब एक्सपायर होता है। यह सिक्योरिटी चेक नहीं है, और ब्राउज़र में चलने वाला डिकोडर ही एकमात्र किस्म है जिसमें असली टोकन पेस्ट करना चाहिए।

आज़माएँ: JWT डिकोडर आज़माएँ: JWT हेडर एनालाइज़र

HS256 बनाम RS256 बनाम ES256

• HS256 (SHA-256 के साथ HMAC) — एक शेयर्ड सीक्रेट साइन भी करता है और वेरिफ़ाई भी। सरल, तेज़, तब ठीक जब एक ही सर्विस टोकन जारी और इस्तेमाल करती है। जो पक्ष वेरिफ़ाई कर सकता है वह जाली टोकन भी बना सकता है।
• RS256 (RSA सिग्नेचर) — प्राइवेट key साइन करती है, पब्लिक key वेरिफ़ाई करती है। कोई भी सर्विस प्रकाशित पब्लिक key (अक्सर JWKS एंडपॉइंट से) से वेरिफ़ाई कर सकती है, टोकन बनाए बिना। OAuth प्रोवाइडर का डिफ़ॉल्ट।
• ES256 (P-256 के साथ ECDSA) — RS256 जैसा असममित मॉडल, कहीं छोटी key और सिग्नेचर के साथ।
• none — ऐसा एल्गोरिदम जिसका मतलब है "कोई सिग्नेचर नहीं"। वेरिफ़ायर को इसे रिजेक्ट करना चाहिए; alg=none स्वीकार करना क्लासिक JWT कमज़ोरियों में से एक है।

आज़माएँ: JWT जनरेटर आज़माएँ: HMAC जनरेटर

JWT सिक्योरिटी नियम

• सिग्नेचर वेरिफ़ाई करें और सर्वर पर एल्गोरिदम पिन करें। टोकन के अपने हेडर को कभी तय न करने दें कि कौन-सा एल्गोरिदम इस्तेमाल होगा।
• हमेशा exp जाँचें, और aud व iss को अपनी वैल्यू से मिलाएँ।
• पेलोड में कभी सीक्रेट, पासवर्ड या संवेदनशील निजी डेटा न रखें — टोकन रखने वाला कोई भी उसे पढ़ सकता है। एन्क्रिप्शन चाहिए तो JWE इस्तेमाल करें।
• एक्सेस टोकन छोटी लाइफ़ के रखें और नए पाने के लिए रिफ़्रेश टोकन इस्तेमाल करें।
• ब्राउज़र में टोकन सावधानी से स्टोर करें: HttpOnly, Secure, SameSite कुकी localStorage से सुरक्षित है, जिसे कोई भी इंजेक्ट की गई स्क्रिप्ट पढ़ सकती है।
• HS256 के लिए मज़बूत सीक्रेट इस्तेमाल करें — कम से कम 256 बिट रैंडमनेस, कभी पासवर्ड नहीं।
• रद्द करने की योजना बनाएँ: JWT एक्सपायर होने तक वैध रहता है, इसलिए लॉगआउट या समझौता हुए अकाउंट के लिए denylist (jti) या छोटी लाइफ़टाइम चाहिए।

आज़माएँ: रैंडम सीक्रेट जनरेटर आज़माएँ: OAuth टोकन डिकोडर

OAuth 2.0 और OpenID Connect में JWT

OAuth 2.0 एक्सेस टोकन अक्सर JWT होते हैं, हालाँकि स्पेक इसे ज़रूरी नहीं करता; OpenID Connect ID टोकन हमेशा JWT होते हैं। ID टोकन क्लाइंट एप्लिकेशन के लिए ऑथेंटिकेटेड यूज़र (sub, ईमेल, नाम) बताता है; एक्सेस टोकन क्लाइंट को API कॉल करने की परमिशन देता है (scope, aud)। दोनों एक ही तरह वेरिफ़ाई होते हैं, लेकिन ID टोकन को कभी एक्सेस टोकन की तरह API को नहीं भेजना चाहिए।

आज़माएँ: OAuth टोकन डिकोडर

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