JWT के अंदर क्या है, और डिकोड करना वेरिफ़ाई करना क्यों नहीं है

JSON Web Token (JWT) डॉट से जुड़े तीन टेक्स्ट-हिस्से होते हैं: हेडर, पेलोड और सिग्नेचर। पहले दो केवल एन्कोड किए गए होते हैं, एन्क्रिप्ट नहीं, इसलिए टोकन जिसके पास है, वह उन्हें पढ़ सकता है। सिग्नेचर सर्वर को यह जाँचने देता है कि टोकन किसी भरोसेमंद पक्ष ने जारी किया है और उसमें किसी ने बदलाव नहीं किया। टोकन को डिकोड करने से पता चलता है कि उसमें क्या लिखा है। उस पर भरोसा करना चाहिए या नहीं, यह केवल वेरिफ़ाई करने से पता चलता है।

JWT डिकोडरटोकन एक्सपायर हुआ, या अब भी वैध?मुफ़्त में करें

तीन हिस्से

टोकन कुछ ऐसा दिखता है: header.payload.signature। jwt.io के प्रसिद्ध उदाहरण टोकन का पहला हिस्सा यह है:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

पहले दोनों हिस्सों में से हर एक JSON है, जिसे base64url में बदला गया है। base64url एक ऐसा टेक्स्ट-रूप है जो URL में सुरक्षित रहता है। पहला हिस्सा डिकोड करने पर यह मिलता है:

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

उसी उदाहरण का पेलोड डिकोड करने पर यह मिलता है:

{"sub":"1234567890","name":"John Doe","iat":1516239022}

पेलोड में claims होते हैं, यानी उपयोगकर्ता या सेशन के बारे में बयान। सिग्नेचर पहले दो हिस्सों और एक key से निकाला जाता है, इसलिए एक अक्षर भी बदलने पर सिग्नेचर मेल खाना बंद कर देता है। base64url को उलटने के लिए किसी key की ज़रूरत नहीं होती, इसलिए पेलोड में कभी पासवर्ड, private key या निजी डेटा न रखें।

रजिस्टर्ड claims

JWT के मानक RFC 7519 ने कुछ छोटे claim नाम आरक्षित किए हैं:

iss (issuer): टोकन किसने बनाया।
sub (subject): टोकन किसके बारे में है, आमतौर पर उपयोगकर्ता ID।
aud (audience): वह सेवा जिसके लिए टोकन है।
exp (expiration time): वह समय जिसके बाद टोकन अमान्य है।
nbf (not before): वह सबसे पहला समय जब टोकन मान्य है।
iat (issued at): टोकन कब बनाया गया।

समय 1 जनवरी 1970 UTC से गिने गए सेकंड होते हैं, जिसे Unix time कहते हैं। उदाहरण में exp नहीं है, इसलिए मानक के हिसाब से वह कभी समाप्त नहीं होता। असली टोकन में यह होना चाहिए। role या email जैसे दूसरे नाम एप्लिकेशन के होते हैं।

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

डिकोड करने में टोकन को डॉट पर तोड़ा जाता है, base64url को उलटा जाता है और JSON पढ़ा जाता है। इससे दिखता है कि टोकन क्या दावा करता है। नकली टोकन के साथ भी यही होता है, क्योंकि कोई भी किसी भी सिग्नेचर के साथ कोई भी claims लिख सकता है।

वेरिफ़ाई करने में सही key से सिग्नेचर दोबारा निकाला जाता है और देखा जाता है कि वह मेल खाता है या नहीं। साथ ही यह भी जाँचा जाता है कि exp और nbf मौजूदा समय को सही सीमा में रखते हैं, और iss तथा aud वही मान हैं जो सेवा अपेक्षा करती है। जो एप्लिकेशन वेरिफ़ाई किए बिना role claim पढ़ लेता है, वह टोकन लिखने वाले पर भरोसा कर रहा है। यह एक आम गलती है।

HS256, RS256 और ES256

alg मान बताता है कि कौन-सी विधि इस्तेमाल हुई। तीन आम हैं:

HS256 SHA-256 के साथ HMAC है। एक साझा secret से साइन और वेरिफ़ाई दोनों होते हैं, इसलिए secret उस सर्वर पर ही रहना चाहिए जो टोकन जारी करता है।
RS256 SHA-256 के साथ RSA सिग्नेचर है। जारी करने वाला private key से साइन करता है, और public key वाला कोई भी वेरिफ़ाई कर सकता है। दूसरी सेवाएँ टोकन जाँच सकती हैं, पर बना नहीं सकतीं।
ES256 P-256 curve और SHA-256 के साथ ECDSA सिग्नेचर है। यह RS256 की तरह काम करता है, पर key और सिग्नेचर छोटे होते हैं।

जब एक ही सेवा अपने टोकन जारी भी करती है और जाँचती भी है, तब HS256 इस्तेमाल करें। जब दूसरी सेवाओं को ऐसे टोकन जाँचने हों जो उन्होंने जारी नहीं किए, तब RS256 या ES256 इस्तेमाल करें।

हेडर पर भरोसा करने से होने वाली समस्याएँ

हेडर वही लिखता है जो टोकन भेजता है, इसलिए वेरिफ़ायर को नियम तय करने का अधिकार हेडर को नहीं देना चाहिए।

alg: none। बिना सिग्नेचर वाला टोकन "alg":"none" घोषित कर सकता है। कुछ लाइब्रेरी ने एक समय ऐसे टोकन स्वीकार कर लिए और जाँच छोड़ दी। अनुमत algorithms अपने कोड में तय करें, टोकन से कभी न लें।
Algorithm confusion। सर्वर RS256 की उम्मीद करता है और उसके पास public key है। हमलावर उसी public key को HMAC secret मानकर साइन किया हुआ HS256 टोकन भेजता है। ऐसा वेरिफ़ायर जो हेडर में लिखा कोई भी algorithm स्वीकार कर ले, उसे भी स्वीकार कर लेता है। हर key को ठीक एक algorithm से बाँधें।
कमज़ोर secrets। हमलावर के पास हेडर, पेलोड और सिग्नेचर होते हैं, इसलिए वह ऑफ़लाइन संभावित secrets आज़मा सकता है। छोटा secret या कोई आम शब्द ऐसी सूची से जल्दी टूट जाता है। RFC 7518 कहता है कि HS256 की key कम से कम 256 bits की और रैंडम होनी चाहिए।

Production टोकन को वेबसाइट पर चिपकाना

एक वैध, समाप्त न हुआ टोकन जिसके पास भी हो, उसके लिए काम करता है, जब तक वह समाप्त नहीं होता। उसे पासवर्ड की तरह समझें। किसी साइट पर चिपकाने से पहले पता करें कि वह साइट उसे किसी सर्वर को भेजती है या नहीं। जो टूल पूरी तरह ब्राउज़र टैब में चलता है, उसे ऐसा करने की ज़रूरत नहीं। किसी भी पेज को ब्राउज़र के developer tools में उसके network requests देखकर जाँचा जा सकता है।

टोकन आम तौर पर समाप्त होने से पहले रद्द नहीं किए जा सकते, जब तक सर्वर उनकी सूची न रखे। अगर कोई चालू टोकन लीक हो जाए, तो सेवा से सेशन रद्द करने या उसकी keys बदलने को कहें। जहाँ संभव हो, डीबगिंग के लिए टेस्ट-वातावरण का टोकन इस्तेमाल करें। JWT डिकोडर आपके ब्राउज़र टैब में तीनों हिस्से पढ़ता है, और जो भी आप चिपकाते हैं वह कहीं नहीं भेजा जाता।

Webhooks: साझा secret के साथ वही विचार

ज़्यादातर webhook providers request body का HMAC एक header में भेजते हैं, जो उस secret से निकाला जाता है जो आपने उनके साथ साझा किया है। आपका receiver वही HMAC निकालता है और दोनों की तुलना करता है। आम गड़बड़ियाँ छोटी होती हैं। hash करने से पहले JSON दोबारा format हो जाता है, इसलिए बाइट्स बदल जाते हैं। टेस्ट secret लाइव ट्रैफ़िक पर इस्तेमाल हो जाता है। या सिग्नेचर साधारण string equality से तुलना किए जाते हैं, जिससे समय (timing) की जानकारी लीक हो सकती है। constant-time तुलना इस्तेमाल करें।

वेबहुक सिग्नेचर टेस्टर आपके चिपकाए secret और body से सिग्नेचर निकालता है, GitHub, Stripe, Slack, Shopify या किसी भी HMAC योजना के लिए, ताकि आप देख सकें कि दोनों मान मेल खाते हैं या नहीं।

त्वरित उत्तर

क्या JWT एन्क्रिप्टेड होता है?

नहीं। मानक JWT साइन किया होता है, और कोई भी उसका हेडर और पेलोड पढ़ सकता है। केवल सिग्नेचर उसे बदलावों से बचाता है।

अगर मैं पेलोड बदल दूँ तो क्या होगा?

सिग्नेचर मेल खाना बंद कर देगा, इसलिए वेरिफ़ाई करने वाला सर्वर टोकन अस्वीकार कर देगा। claims पढ़ने से सिग्नेचर की जाँच नहीं होती, इसलिए डिकोडर फिर भी आपका बदला हुआ संस्करण दिखाएगा।