मुफ़्त JWT डिकोडर

JSON Web Token का संक्षिप्त इतिहास

JSON Web Token (JWT) को IETF के JOSE वर्किंग ग्रुप के तहत Michael B. Jones (Microsoft), John Bradley (Ping Identity), और Nat Sakimura (NRI) द्वारा मई 2015 में RFC 7519 के रूप में मानकीकृत किया गया था। यह आधे दशक के काम की पराकाष्ठा थी: पहला JWT इंटरनेट-ड्राफ्ट दिसंबर 2010 में दिखाई दिया, जो SAML 2.0 (2005) के भारी XML-आधारित अभिकथन प्रारूप और कुछ हल्के की महसूस की गई आवश्यकता से उत्पन्न हुआ जिसे ब्राउज़र मूल रूप से पार्स कर सकें। सफलता XML के बजाय JSON और PEM के बजाय base64url चुनना थी: एक JWT URL क्वेरी स्ट्रिंग या Authorization: Bearer हेडर में फिट हो सकता था। पूरे JOSE परिवार को एक समन्वित सेट के रूप में भेजा गया: हस्ताक्षर के लिए RFC 7515 (JWS), एन्क्रिप्शन के लिए RFC 7516 (JWE), कुंजी प्रारूप के लिए RFC 7517 (JWK), एल्गोरिथम पहचानकर्ताओं के लिए RFC 7518 (JWA), और दावों की परत के लिए RFC 7519 (JWT), सभी मई 2015 के एक ही दिन। अपनाना तत्काल था। OAuth 2.0 (RFC 6749, 2012) ने एक्सेस टोकन को मानकीकृत किया था लेकिन उनके प्रारूप को अपारदर्शी छोड़ा था; उद्योग ने JWT चुना। OpenID Connect (दिसंबर 2014, OpenID फाउंडेशन) ने आईडी टोकन के लिए JWT को अनिवार्य बनाया। 2017 तक हर प्रमुख पहचान प्रदाता (Auth0, Okta, Azure AD, AWS Cognito, Google Identity, Firebase Auth) ने JWT को अपने मूल सत्र प्रारूप के रूप में जारी किया। JWT.io, वह डिकोडर वेबसाइट जिसे Auth0 ने 2014 में लॉन्च किया, वास्तविक JWT डिबगिंग टूल बन गई और प्रारूप की डेवलपर माइंडशेयर को सीमेंट करने में मदद की। दो सुरक्षा घटनाओं ने आधुनिक खतरे के मॉडल को आकार दिया: Tim McLean का 2015 खुलासा alg: none बायपास और HS/RS एल्गोरिथम-भ्रम हमले का, और CVE-2022-21449 (अप्रैल 2022), Java 15-18 के ECDSA सत्यापनकर्ता में Neil Madden का «Psychic Signatures» बग। दोनों ने लाइब्रेरी-डिफ़ॉल्ट सख्ती की: अधिकांश आधुनिक लाइब्रेरी अब alg: none को सीधे अस्वीकार करती हैं और टोकन हेडर से पढ़ने के बजाय अपेक्षित एल्गोरिथम को पिन करती हैं।

JWT की संरचना

• तीन base64url-एन्कोडेड खंड। एक JWT स्ट्रिंग header.payload.signature है: डॉट्स द्वारा अलग किए गए तीन खंड, प्रत्येक base64url-एन्कोडेड। RFC 7519 इसे JWT कॉम्पैक्ट सीरियलाइज़ेशन कहती है। पूरी चीज़ URL या HTTP हेडर में फिट होती है; वह सघनता डिज़ाइन लक्ष्य था जिसने JWT को SAML जैसे XML-आधारित पूर्ववर्तियों से अलग किया।
• हेडर। एक छोटा JSON ऑब्जेक्ट जिसमें आमतौर पर दो फ़ील्ड होते हैं: alg (हस्ताक्षर एल्गोरिथम, जैसे HS256, RS256, ES256) और typ (लगभग हमेशा «JWT»)। वैकल्पिक फ़ील्ड में kid (कुंजी रोटेशन के लिए उपयोग की जाने वाली एक कुंजी पहचानकर्ता) और cty (नेस्टेड टोकन के लिए सामग्री प्रकार) शामिल हैं। हेडर सत्यापनकर्ता को बताता है कि हस्ताक्षर को कैसे मान्य किया जाए; कभी भी इस पर अकेले भरोसा न करें, हमेशा सर्वर-साइड पर अपेक्षित एल्गोरिथम को पिन करें।
• पेलोड। दावों का एक JSON ऑब्जेक्ट, एक विषय के बारे में कुंजी-मान अभिकथन। RFC 7519 §4.1 सात मानक दावे आरक्षित करता है: iss (जारीकर्ता), sub (विषय), aud (दर्शक), exp (समाप्ति), nbf (पहले नहीं), iat (जारी किया गया), और jti (अद्वितीय JWT ID)। जारीकर्ता स्वतंत्र रूप से कस्टम दावे जोड़ते हैं। पेलोड हस्ताक्षरित है लेकिन एन्क्रिप्टेड नहीं: टोकन वाला कोई भी इसे पढ़ सकता है।
• हस्ताक्षर। क्रिप्टोग्राफिक प्रमाण कि हेडर और पेलोड के साथ छेड़छाड़ नहीं की गई। हस्ताक्षर इनपुट शाब्दिक स्ट्रिंग base64url(header) + "." + base64url(payload) है; हस्ताक्षर स्वयं फिर तीसरे खंड के रूप में base64url-एन्कोड किया जाता है। सत्यापन के लिए सममित रहस्य (HS*) या असममित सार्वजनिक कुंजी (RS*, ES*, PS*, EdDSA) की आवश्यकता होती है और इसे हमेशा एक विश्वसनीय सर्वर पर होना चाहिए।
• base64url, base64 नहीं। JWT खंड RFC 4648 §5 से URL-सुरक्षित base64 वैरिएंट का उपयोग करते हैं: वर्ण 62 + के बजाय - है, वर्ण 63 / के बजाय _ है, और अनुगामी = पैडिंग हटा दी जाती है। JavaScript का बिल्ट-इन atob() केवल मानक base64 को संभालता है, इसलिए JWT डिकोडर डिकोड करने से पहले वर्णमाला का अनुवाद करते हैं और फिर से पैड करते हैं।
• NumericDate: सेकंड, मिलीसेकंड नहीं। RFC 7519 exp, nbf, और iat को «1970-01-01T00:00:00Z UTC से सेकंड की संख्या» के रूप में परिभाषित करता है। JavaScript का Date.now() मिलीसेकंड लौटाता है, इसलिए एक सामान्य बग एक exp है जो तीन परिमाण के क्रम से बहुत बड़ा है, जो एक टोकन उत्पन्न करता है जो वर्ष 53,000 के आसपास «समाप्त» होता है। टोकन ढालते समय हमेशा Math.floor(Date.now() / 1000) का उपयोग करें।

व्यवहार में JWT का उपयोग कहाँ होता है

• OAuth 2.0 एक्सेस टोकन। RFC 6749 ने एक्सेस-टोकन प्रारूप को अपारदर्शी छोड़ा, लेकिन व्यवहार में उद्योग ने JWT पर मानकीकृत किया। Auth0, Okta, Azure AD, AWS Cognito, और Google Identity सभी डिफ़ॉल्ट रूप से JWT एक्सेस टोकन जारी करते हैं। आपके Authorization हेडर में बियरर टोकन लगभग हमेशा एक JWT होता है।
• OpenID Connect ID टोकन। OIDC (दिसंबर 2014) अपने id_token के लिए JWT अनिवार्य करता है। id_token प्रमाणीकृत उपयोगकर्ता के बारे में पहचान दावे (sub, email, name, picture) ले जाता है और आगे पारित होने के बजाय रिलाइंग पार्टी द्वारा उपभोग किया जाता है। यह «Google के साथ साइन इन», «Apple के साथ साइन इन», और समकक्ष फ्लो के पीछे प्राथमिक तंत्र है।
• API प्रमाणीकरण। स्टेटलेस REST API JWT अपनाते हैं क्योंकि यह सर्वर-साइड सत्र स्टोर की आवश्यकता को हटा देता है: API भरोसा करता है कि हस्ताक्षर क्या सत्यापित करता है। Stripe-शैली API कुंजियाँ सर्वर-टू-सर्वर ट्रैफ़िक के लिए सामान्य रहती हैं, लेकिन उपयोगकर्ता-स्कोप्ड API के लिए, Authorization: Bearer <jwt> पैटर्न अब डिफ़ॉल्ट है।
• माइक्रोसर्विस-टू-माइक्रोसर्विस ऑथ। API एज पर ढाला गया एक उपयोगकर्ता-स्कोप्ड JWT आंतरिक सेवा-टू-सेवा कॉल के माध्यम से अग्रेषित किया जाता है, जिससे प्रत्येक सेवा को पुन: प्रमाणीकरण के बिना मूल प्रमाणीकरण पर भरोसा करने की अनुमति मिलती है। पैटर्न को कभी-कभी «टोकन अनुवाद» कहा जाता है: एज गेटवे एक अपारदर्शी सत्र को नीचे की कॉल के लिए स्कोप किए गए एक अल्पकालिक JWT के लिए विनिमय करता है।
• एकल-पृष्ठ अनुप्रयोग सत्र। SPAs (React, Vue, Angular) ने ऐतिहासिक रूप से सुविधा के लिए localStorage में एक्सेस टोकन संग्रहीत किए। आधुनिक मार्गदर्शन (OWASP, Auth0) यह है कि एक्सेस टोकन को मेमोरी में और रिफ्रेश टोकन को HttpOnly + Secure + SameSite=Strict कुकीज़ में रखें, क्योंकि localStorage पृष्ठ पर उतरने वाले किसी भी XSS द्वारा पढ़ा जा सकता है।
• मोबाइल ऐप सत्र। iOS और Android ऐप्स प्लेटफ़ॉर्म Keychain या Keystore में एक्सेस टोकन संग्रहीत करते हैं। प्रत्येक बैकएंड कॉल पर टोकन को Authorization: Bearer के रूप में भेजा जाता है। प्रत्येक उपयोग पर रिफ्रेश टोकन घुमाए जाते हैं, और एक्सेस टोकन का छोटा exp (आमतौर पर 5-15 मिनट) चोरी-डिवाइस रीप्ले के खिलाफ प्राथमिक रक्षा है।

मानक और सुरक्षा मील के पत्थर

• RFC 7519 (JWT, मई 2015)। आधार विनिर्देश। JWT कॉम्पैक्ट सीरियलाइज़ेशन, सात मानक पंजीकृत दावे (iss, sub, aud, exp, nbf, iat, jti), और NumericDate प्रारूप को परिभाषित करता है। लेखक: Michael B. Jones, John Bradley, Nat Sakimura।
• RFC 7515 (JWS, मई 2015)। JSON Web Signature। हस्ताक्षरित-रैपर प्रारूप जिसे लगभग हर कोई अनौपचारिक रूप से «JWT» कहता है: डॉट्स से जुड़े तीन base64url खंड। JWS कॉम्पैक्ट और JSON सीरियलाइज़ेशन दोनों रूपों का समर्थन करता है; JWT केवल कॉम्पैक्ट रूप का उपयोग करता है।
• RFC 7516 (JWE, मई 2015)। JSON Web Encryption। पाँच खंडों के साथ एन्क्रिप्टेड वैरिएंट (हेडर, एन्क्रिप्टेड कुंजी, IV, सिफरटेक्स्ट, प्रमाणीकरण टैग)। JWS नहीं, JWE का उपयोग करें, जब पेलोड को गोपनीय होना चाहिए, न कि केवल छेड़छाड़-स्पष्ट।
• RFC 7517 (JWK, मई 2015)। JSON Web Key। क्रिप्टोग्राफिक कुंजियों का JSON प्रतिनिधित्व। JWKS एंडपॉइंट (/.well-known/jwks.json) एक JSON Web Key Set प्रकाशित करता है, जो शून्य-डाउनटाइम कुंजी रोटेशन के लिए आधुनिक तंत्र है: सत्यापनकर्ता kid द्वारा कुंजियाँ देखते हैं।
• RFC 7518 (JWA, मई 2015)। JSON Web Algorithms। alg पहचानकर्ताओं का रजिस्टर: HS256/384/512 (HMAC), RS256/384/512 (RSASSA-PKCS1-v1_5), ES256/384/512 (ECDSA), PS256/384/512 (RSASSA-PSS), EdDSA (Ed25519/Ed448), और (जानबूझकर शायद ही कभी उपयोग किया जाने वाला) none।
• alg: none बायपास (Tim McLean, 2015)। RFC 7518 none को असुरक्षित संदर्भों के लिए एक वैध एल्गोरिथम मान के रूप में सूचीबद्ध करता है। भोले सत्यापनकर्ता हेडर को {"alg":"none"} में फिर से लिखे गए और एक खाली हस्ताक्षर के साथ एक टोकन स्वीकार करेंगे, जिससे हमलावर किसी भी पेलोड को जाली बना सकेंगे। आधुनिक लाइब्रेरी डिफ़ॉल्ट रूप से none को अस्वीकार करती हैं; विनिर्देश स्वयं कहता है कि सत्यापनकर्ता «डिफ़ॉल्ट रूप से असुरक्षित JWS स्वीकार नहीं करना चाहिए»।
• HS/RS एल्गोरिथम-भ्रम हमला (Tim McLean, 2015)। यदि एक सत्यापनकर्ता टोकन हेडर से एल्गोरिथम चुनता है इसे पिन करने के बजाय, एक हमलावर हेडर को HS256 में फिर से लिख सकता है और सर्वर की RSA सार्वजनिक कुंजी को HMAC रहस्य के रूप में उपयोग करके टोकन पर हस्ताक्षर कर सकता है। लाइब्रेरी HS256 देखती है, कॉन्फ़िगर की गई RSA सार्वजनिक कुंजी को सममित रहस्य के रूप में मानती है, और हस्ताक्षर सत्यापित हो जाते हैं। शमन: बैंड के बाहर अपेक्षित एल्गोरिथम पिन करें; इसे कभी भी टोकन से प्राप्त न करें।
• CVE-2022-21449 «Psychic Signatures» (Neil Madden, अप्रैल 2022)। Java 15-18 के ECDSA सत्यापनकर्ता ने जाँच नहीं की कि हस्ताक्षर के r और s मान शून्य-नहीं थे, जिसका मतलब है कि शाब्दिक रूप से सभी-शून्य हस्ताक्षर वैध स्वीकार किए गए थे। प्रभावित JVM पर ES256/384/512 के साथ हस्ताक्षरित JWT को एक खाली हस्ताक्षर के साथ जाली बनाया जा सकता है। Oracle के अप्रैल 2022 क्रिटिकल पैच अपडेट में पैच किया गया।

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

संबंधित टूल