JWT (JSON Web Token) IETF द्वारा RFC 7519 में परिभाषित एक ओपन स्टैंडर्ड है (RFC 7515 JWS सिग्नेचर फॉर्म का वर्णन करता है, RFC 7516 JWE एन्क्रिप्शन का वर्णन करता है, RFC 7517 JWK कीज को परिभाषित करता है) HTTP अनुरोधों, OIDC फ्लो और माइक्रोसर्विस कॉल्स के बीच 'घोषित' उपयोगकर्ता जानकारी को सुरक्षित रूप से स्थानांतरित करने के लिए। एक मानक JWT स्ट्रिंग Base64URL-एन्कोडेड तीन सेगमेंट से बनी होती है: Header (एल्गोरिदम और प्रकार), Payload (Claims, उपयोगकर्ता डेटा) और Signature (पहले दो पर की-आधारित सिग्नेचर)। तीन सेगमेंट एक डॉट `.` से जुड़े होते हैं, उदा. `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`।
**JWT एन्क्रिप्शन नहीं है।** यह सबसे आम गलतफहमी है। Payload डिफॉल्ट रूप से प्लेन-टेक्स्ट होता है — कोई भी इसे Base64URL में डिकोड करके सामग्री पढ़ सकता है। JWT **टैम्परिंग डिटेक्शन** प्रदान करता है, गोपनीयता नहीं: सर्वर साझा की के साथ Header.Payload को फिर से साइन करता है और टोकन के Signature से तुलना करता है। यदि वे मेल खाते हैं, टोकन ट्रांजिट में बदला नहीं गया है। यह 'एंटी-काउंटरफिट स्टैम्प वाला ट्रेन टिकट' का रूपक है: निरीक्षक को इससे मतलब है कि टिकट असली है या नहीं, QR कोड पढ़ने योग्य है या नहीं इससे नहीं।
JWT 13 एल्गोरिदम के बीच जिम्मेदारियों को साफ तौर पर बांटता है। **HMAC परिवार** (HS256/HS384/HS512) साइनिंग और वेरिफिकेशन के लिए सममित की का उपयोग करता है, तेज और सरल, एक सेवा या विश्वसनीय क्लस्टर के लिए उपयुक्त; secret कम से कम digest की लंबाई का होना चाहिए (उदा. HS256 के लिए ≥ 32 बाइट्स)। **RSA परिवार** (RS256/RS384/RS512) सबसे आम असममित स्कीम RSASSA-PKCS1-v1_5 का उपयोग करता है — साइनर के पास प्राइवेट की होती है, वेरिफायर के पास पब्लिक की होती है। **RSA-PSS परिवार** (PS256/PS384/PS512) मजबूत सुरक्षा गारंटी के साथ नए RSA-PSS पैडिंग का उपयोग करता है, AWS SigV4 और आधुनिक OIDC आइडेंटिटी प्रोवाइडर द्वारा प्राथमिकता दी जाती है। **ECDSA परिवार** (ES256/ES384/ES512) छोटे सिग्नेचर और बेहतर प्रदर्शन के साथ एलिप्टिक कर्व्स (क्रमशः P-256/P-384/P-521) का उपयोग करता है। **EdDSA** (मुख्य रूप से Ed25519) बेहद तेज और नियतिवादी है (वही संदेश + वही की = हर बार वही सिग्नेचर) और OAuth 2.1 और नए प्रोटोकॉल में अनुशंसित एल्गोरिदम है।
सुरक्षा वह जगह है जहां JWT प्रोडक्शन में ठोकर खाता है। OWASP JWT Cheat Sheet कम से कम चार सख्त नियमों को सूचीबद्ध करता है: (1) Payload में कभी भी पासवर्ड, राष्ट्रीय पहचान दस्तावेज, कार्ड नंबर या API कीज को प्लेन-टेक्स्ट के रूप में न रखें; (2) सर्वर को **टोकन के Header में घोषित alg फील्ड पर कभी भरोसा नहीं करना चाहिए** — हार्ड-कोडेड एल्गोरिदम के साथ वेरिफाई करना चाहिए, अन्यथा `alg: none` में हेडर को फिर से लिखने वाला हमलावर सब कुछ बायपास कर देता है (यह CVE-2015-9235 जैसे ऐतिहासिक CVE का स्रोत है); (3) HMAC secrets यादृच्छिक होने चाहिए और कम से कम 32 बाइट्स लंबे होने चाहिए, कभी छोटी स्ट्रिंग्स नहीं; (4) वेरिफिकेशन केवल सिग्नेचर चेक्स से अधिक है — आपको `exp` (समाप्ति), `nbf` (not-before), `iss` (जारीकर्ता) और `aud` (दर्शक) को भी मान्य करना चाहिए। यह टूल इनमें से प्रत्येक Claims को UI में हाइलाइट करता है ताकि आप तुरंत बता सकें कि विफलता सिग्नेचर समस्या है, समय समस्या है या Claims समस्या है।
JWT सत्रों का विकल्प नहीं है। सत्रें उपयोगकर्ता की स्थिति को सर्वर पर संग्रहित करती हैं (Redis या डेटाबेस); JWT स्थिति को टोकन में पैक करता है। माइक्रोसर्विस आर्किटेक्चर, स्टेटलेस API, मोबाइल क्लाइंट और बहुत अधिक CORS वाले सेटअप JWT से लाभान्वित होते हैं; पारंपरिक एंटरप्राइज सिस्टम और तत्काल रद्दीकरण की आवश्यकता वाले फ्लो (उदा. 'इस उपयोगकर्ता को अभी निकालो') अभी भी सत्रों द्वारा बेहतर सेवा प्राप्त करते हैं। यह टूल शुद्ध JWT डिबगिंग के साथ-साथ सत्र से JWT माइग्रेशन के टोकन पार्स / सिग्नेचर वेरिफिकेशन / Payload एडिटिंग स्टेप्स को भी कवर करता है।