« JWT डिकोड करना » का क्या अर्थ है?
JWT डिकोड करना (« jwt decode », « decode jwt online ») का मतलब है स्ट्रिंग को दो-बिंदुओं पर काटना, फिर मूल JSON पाने के लिए हर सेगमेंट को Base64URL में डिकोड करना। किसी की की ज़रूरत नहीं : हेडर और payload बस एन्कोड किए गए हैं, एन्क्रिप्ट नहीं। यही « jwt payload decoder » या « decode jwt without verify » के पीछे का इरादा है — टोकन में क्या है यह देखना, बिना यह दावा किए कि वह प्रामाणिक है।
दोनों क्रियाओं में फ़र्क साफ़ रखना ज़रूरी है। पढ़ना JWT कुछ साबित नहीं करता : कोई भी आकर्षक payload वाला टोकन बनाकर अपने ही सीक्रेट से साइन कर सकता है। सत्यापन सिग्नेचर साबित करती है कि सामग्री किसी तीसरे पक्ष ने नहीं बदली। बिना सिग्नेचर जाँच के « admin: true » दिखाने वाला डिकोडर आपको कहानी सुनाता है, तथ्य नहीं।
JWT के तीन सेगमेंट
स्ट्रिंग बिंदुओं से अलग ठीक तीन भागों में बँटती है : header.payload.signature। हेडर में न्यूनतम होता है alg और typ, कभी-कभी kid यह बताने के लिए कि कौन सी की उपयोग हुई। payload में होते हैं claims, यानी वे key-value जोड़ियाँ जिनका रजिस्ट्री IANA संभालता है। सिग्नेचर पहले दो सेगमेंट को ठीक वैसे ही जोड़कर कवर करती है जैसे वे लिखे गए हैं — स्पेस या किसी एक वर्ण में छोटा-सा बदलाव भी तुलना तोड़ देता है।
पूरी दिक्कत यही है कि ये सेगमेंट Base64 नहीं, Base64URL हैं : प्लस चिह्न हाइफ़न बन जाता है, स्लैश अंडरस्कोर, और पैडिंग = गायब हो जाता है। इसलिए सामान्य Base64 डिकोडर मान्य JWT पर भी असफल हो जाता है। संदर्भ टैब की तालिका « Base64URL बनाम सामान्य Base64 » ठीक यही प्रतिस्थापन दिखाती है।
सिग्नेचर कैसे जाँचें : HS256, RS256, ES256
किसी HMAC एल्गोरिदम — HS256, HS384, HS512 — के लिए साइन और सत्यापन दोनों में वही सीक्रेट काम करता है : उपकरण पुनर्गणना करता है HMAC(secret, base64url(header) + "." + base64url(payload)) और परिणाम की तुलना टोकन की सिग्नेचर से करता है। यह सबसे आम मामला है, और साथ ही सबसे खतरनाक भी : सीक्रेट रखने वाली कोई भी सेवा टोकन जारी कर सकती है। 32 बाइट से कम का सीक्रेट, जो वातावरणों के बीच दोबारा उपयोग हो, पूरी श्रृंखला को भेदने के लिए काफी है।
इन एल्गोरिदम असममित — RS256, RS384, RS512, ES256, ES384, ES512, PS256 — के लिए सत्यापन हेतु सिर्फ़ पब्लिक की चाहिए, जिससे किसी तीसरे पक्ष के जारी किए टोकन की जाँच उसका सिग्नेचर सीक्रेट साझा किए बिना की जा सकती है। PEM फ़ॉर्मेट में की चिपकाएँ -----BEGIN PUBLIC KEY----- (SPKI) ; OpenSSL एक्सपोर्ट का सीधा परिणाम उपयोग में लाया जा सकता है। ES256 में सिग्नेचर सीधे r||s फ़ॉर्मेट में होती है, जो WebCrypto को चाहिए।
अंत में सावधान रहेंalg confusion : यदि आपकी सेवा RS256 की उम्मीद करती है लेकिन ऐसे टोकन को स्वीकार कर लेती है जिसका हेडर HS256 घोषित करता है, तो हमलावर पब्लिक की — जो HMAC की बन जाती है — से साइन करेगा और सत्यापन पार कर जाएगा। अपेक्षित एल्गोरिदम सर्वर पर स्थिर रखें, उसे कभी टोकन स्वयं न पढ़ें।
exp, iat, nbf : भ्रमित करने वाले टाइमस्टैम्प
ये तीनों claims Unix सेकंड, बिना मिलीसेकंड और बिना टाइम़ोन : iat में 1516239022 का मतलब 2018-01-17T21:30:22Z है। दो गलतियाँ बार-बार होती हैं : मिलीसेकंड वाली तिथि से तुलना (मान दस हज़ार गुना बड़ा) और टाइमस्टैम्प को UTC के बजाय स्थानीय समय मान लेना। टैब « समाप्ति » दोनों दिशाओं में रूपांतरित करता है, ISO 8601, स्थानीय तिथि और शेष या बीता समय दिखाता है — इससे « पहले से समाप्त » टोकन घड़ी के हर सेकंड तक पहचाना जा सकता है।
वैधता अवधि बढ़ाने से सुरक्षा का स्तर नहीं बढ़ता : exp आगे खिसकाने से दिखने वाला मान बदलता है, सिग्नेचर नहीं। यदि आपको दोबारा जारी करना है, तो सीक्रेट या प्राइवेट की से टोकन पर फिर साइन करें — यही टैब « एन्कोड » का काम है।
Base64URL : पारंपरिक डिकोडर असफल क्यों होते हैं
Base64URL (RFC 4648 §5) वर्णमाला के रूप में उपयोग करता है A-Z a-z 0-9 - _ और पैडिंग स्वीकार नहीं करता। 20 अक्षरों के payload की लंबाई का पैडिंग = हटाने के बाद चार का गुणज न होना आम बात है, खराबी नहीं। ये वर्ण - और _ मनुष्य की आँख के लिए भ्रमित करने वाले हैं, जिसकी वजह से आधे « टूटे टोकन » की शिकायतें आती हैं। हमारा डिकोडर दोनों वर्णमालाएँ, मिश्रित अक्षर, वैकल्पिक पैडिंग और Bearer.
सुरक्षा : JWT जो नहीं करता
JWT न गोपनीयता देता है, न रद्दीकरण। payload सभी के लिए पठनीय है : ऐसा ईमेल, आंतरिक भूमिका या निजी डेटा कभी न रखें जिसे आप सादे पाठ में भेजना पसंद न करते। और साइन किया गया टोकन exp लॉगआउट के बाद भी मान्य रहता है — इसके लिए रद्दीकरण सूची, jti सर्वर पर नज़र रखना, या छोटी वैधता अवधि के साथ refresh token। एक अच्छी आदत : exp छोटी (10 से 15 मिनट), iat नियंत्रित, nbf से मिलाया हुआ iat, aud और iss प्राप्ति पर जाँचे जाते हैं।
इनके लिए अनुशंसित
back-end और front-end डेवलपर (OAuth 2.0, OpenID Connect, REST API), इंटीग्रेटर और DevOps (पहचान इन्फ़्रास्ट्रक्चर, JWKS, की रोटेशन), टेस्टर और पेनटेस्टर (claims का पुनर्लेखन, alg confusion, समाप्ति), सिस्टम एडमिन (किसी अकारण 401 की डीबगिंग), छात्र (Base64URL और WebCrypto समझने के लिए), और हर उस व्यक्ति के लिए जिसे चाहिए ऑनलाइन JWT डिकोडर तेज़, पूर्ण और गोपनीय — इनके पूरक हैंBase64 एन्कोडर डिकोडर,URL एन्कोडर डिकोडर और JSON फ़ॉर्मेटर.