JWT डिकोडरले वास्तवमा के गर्छ
JSON Web Token (JWT) हेर्दा अस्पष्ट अनियमित क्यारेक्टरको लामो स्ट्रिङ जस्तो देखिन्छ, तर यो इन्क्रिप्ट गरिएको छैन र यो कुनै गोप्य सिफर पनि होइन। यो दुई पक्षबीच संरचित डेटा बोक्ने एउटा कम्प्याक्ट, URL-सुरक्षित कन्टेनर हो। माथिको डिकोडरमा टोकन पेस्ट गर्नुहोस् र यसले त्यो स्ट्रिङलाई टुक्राउँछ र भित्रको वास्तविक JSON देखाउँछ — मेटाडेटा, क्लेम, टोकन कसका लागि हो, र यो कहिले समाप्त हुन्छ। सबै कुरा तपाईंको ब्राउजरमै हुन्छ। टोकन कहिल्यै अपलोड, लग, वा कतै पठाइँदैन, जुन कुरा तपाईं जाँच गर्दै गरेको चीज कुनै जीवित सेसन क्रेडेन्सियल हो भने धेरै महत्त्वपूर्ण हुन्छ।
तीन भाग, दुई थोप्लो
हरेक राम्रोसँग बनेको JWT थोप्लोले जोडिएका तीनवटा Base64url-इन्कोड गरिएका स्ट्रिङ हुन्: header.payload.signature। त्यो एउटै थोप्लो क्यारेक्टरले नै पार्सरहरूलाई एउटा खण्ड कहाँ सकिन्छ र अर्को कहाँ सुरु हुन्छ भनी थाहा हुन्छ, र त्यही कारण गलत संख्याको थोप्लो भएको टोकनलाई अरू केही पढ्नुअघि नै अस्वीकार गरिन्छ।
हेडर टोकन आफैंलाई वर्णन गर्ने सानो JSON अब्जेक्ट हो। यसमा प्रायः typ (प्रकार, सामान्यतया JWT) र alg — हस्ताक्षर एल्गोरिदम, जस्तै HS256 (SHA-256 सँग HMAC) वा RS256 (SHA-256 सँग RSA) हुन्छ। हेडरले भेरिफायरलाई हस्ताक्षर ठ्याक्कै कसरी उत्पादन गरियो भनी बताउँछ।
पेलोड धेरैजसो मानिसले वास्ता गर्ने भाग हो। यो अर्को JSON अब्जेक्ट हो जसमा क्लेम — प्रयोगकर्ता र टोकनका बारेमा भनाइहरू हुन्छन्। विशिष्टिकरणले क्लेमहरूलाई दर्ता (मानक, आरक्षित नाम), सार्वजनिक, र निजी (तपाईंले आफ्नो एपका लागि आविष्कार गर्ने अनुकूलित नाम) मा वर्गीकरण गर्छ। पेलोड डिकोड गर्नाले को लगइन गरेको छ, उसको भूमिका के हो, र उसको सेसन कहिले समाप्त हुन्छ भन्ने देखाउँछ।
हस्ताक्षर क्रिप्टोग्राफिक सील हो। यो हेडरबाटको एल्गोरिदम प्लस एउटा गोप्य वा निजी की प्रयोग गरी इन्कोड गरिएको हेडर र पेलोडमाथि गणना गरिन्छ। यसले अरू दुई खण्ड दुवैलाई समेट्ने भएकाले, हेडर वा पेलोडमा एउटा क्यारेक्टरको पनि परिवर्तनले यसलाई अमान्य बनाउँछ।
तपाईंले सबैभन्दा बढी देख्ने क्लेमहरू
दर्ता क्लेमहरू छोटो, तीन-अक्षरका नाम हुन् जुन RFC 7519 ले परिभाषित गरेको छ ताकि फरक प्रणालीहरू एकअर्कासँग काम गर्न सकून्। मुठ्ठीभरले लगभग जताततै देखा पर्छन्:
iss— issuer: कसले टोकन बनायो (तपाईंको auth सर्भर वा पहिचान प्रदायक)।sub— subject: टोकन जोसँग सम्बन्धित छ, सामान्यतया एउटा स्थिर प्रयोगकर्ता ID।aud— audience: टोकन जसका लागि उद्देश्यित छ त्यो प्राप्तकर्ता। कुनै API ले आफैं नभएको audience भएका टोकनहरू अस्वीकार गर्नुपर्छ।exp— expiration time: एउटा Unix टाइमस्ट्याम्प जुनपछि टोकन स्वीकार गर्न हुँदैन।iat— issued at: टोकन कहिले बनाइयो भन्ने Unix टाइमस्ट्याम्प।
तपाईंले nbf (यसअघि होइन) र jti (एउटा अनौठो टोकन ID) पनि भेट्टाउन सक्नुहुन्छ। टाइमस्ट्याम्पहरू UTC मा 1970 देखिको सेकेन्ड हुन्, त्यसैले तिनलाई मानिसले पढ्न मिल्ने मितिमा प्रस्तुत गर्ने डिकोडरले टोकन पहिल्यै समाप्त भएको छ कि छैन जाँच गर्ने मानसिक गणना बचाउँछ।
डिकोडिङ भेरिफाई गर्नु होइन — यही भागले मानिसलाई टोक्छ
यो भिन्नता JWT बारेमा बुझ्नुपर्ने सबैभन्दा महत्त्वपूर्ण एउटा कुरा हो। डिकोडिङ भन्नाले सामग्री पढ्नु हो: यसलाई कुनै की चाहिँदैन र टोकन भएको जो कोहीले यो गर्न सक्छ, किनभने Base64url इन्कोडिङ हो, इन्क्रिप्सन होइन। भेरिफाइङ भन्नाले टोकन प्रामाणिक र नछेडिएको छ भनी प्रमाणित गर्नु हो — सही गोप्य वा सार्वजनिक कीले हस्ताक्षर पुनः गणना गर्नु र यो मिल्छ भनी पुष्टि गर्नु।
यो टुलले डिकोड गर्छ। यसले टोकनले के भन्छ देखाउँछ, टोकन भरपर्दो छ कि छैन होइन। कुनै टोकन नक्कली, समाप्त भएको, वा पुनः प्रयोग गरिएको हुन सक्छ र फेरि पनि पूर्णतया सफा देखिने JSON मा डिकोड हुन सक्छ। कहिल्यै पनि डिकोड गरिएको क्लेममा मात्र भर परेर अनुमति निर्णय नगर्नुहोस्। उत्पादनमा तपाईं सर्भर-साइडमा हस्ताक्षर भेरिफाई गर्नुहुन्छ, exp जाँच गर्नुहुन्छ, र iss र aud तपाईंले अपेक्षा गरेकोसँग मिल्छ भनी पुष्टि गर्नुहुन्छ — एउटा प्रमाणित लाइब्रेरी प्रयोग गरेर, कहिल्यै हातैले बनाइएको स्ट्रिङ तुलना गरेर होइन।
पेलोड कुनै भल्ट होइन
पेलोड केवल Base64url-इन्कोड गरिएको भएकाले, टोकन बीचमा समाते जोकोहीले यो पढ्न सक्छ। यसभित्रको हरेक कुरालाई सार्वजनिक ठान्नुहोस्। JWT क्लेममा पासवर्ड, पूर्ण क्रेडिट कार्ड नम्बर, गोप्य की, वा कुनै पनि संवेदनशील व्यक्तिगत डेटा नराख्नुहोस् — तपाईंले यसलाई यहाँ एक क्लिकमा डिकोड गर्न सक्नुहुन्छ भने, यसको प्रतिलिपि पाउने अरू जो कोहीले पनि सक्छन्। हस्ताक्षरले परिवर्तन बाट जोगाउँछ, कहिल्यै पढाइ बाट होइन। तपाईंलाई साँच्चै पेलोड सामग्री लुकाउन आवश्यक छ भने, त्यो JWE (इन्क्रिप्ट गरिएका टोकन) को काम हो, पूर्णतया फरक विशिष्टिकरण।
गोपनीयता र सम्बन्धित टुलहरू
टोकन जाँच्नु संवेदनशील कार्य भएकाले, यो डिकोडर पूर्णतया क्लाइन्ट-साइडमा चल्छ — पार्सिङ तपाईंको ट्याबमा सामान्य JavaScript हो र केही पनि तपाईंको मेसिन छोड्दैन। सेसन टोकन सर्भर-समर्थित टुलमा पेस्ट गर्नु भनेको जीवित क्रेडेन्सियल तेस्रो पक्षलाई सुम्पिनु हो, जुन तपाईंले ठ्याक्कै बेवास्ता गर्नुपर्ने कुरा हो। यसमुनिको इन्कोडिङका लागि, हाम्रो Base64 टुल हेर्नुहोस्, र थप अन-डिभाइस युटिलिटीका लागि हाम्रा बाँकी डेभलपर टुलहरू अन्वेषण गर्नुहोस्।
बारम्बार सोधिने प्रश्नहरू
के JWT इन्क्रिप्ट गरिएको हुन्छ?
होइन। मानक JWT Base64url-इन्कोड गरिएको हुन्छ, इन्क्रिप्ट गरिएको होइन। टोकन भएको जो कोहीले हेडर र पेलोड पढ्न सक्छ। सामग्री लुकाउन आवश्यक भए JWE प्रयोग गर्नुहोस्।
के यो टुलले हस्ताक्षर भेरिफाई गर्छ?
होइन। यसले हेडर र पेलोड मात्र डिकोड गरी देखाउँछ। हस्ताक्षर भेरिफाई गर्न इस्युअरको गोप्य वा सार्वजनिक की चाहिन्छ र यो तपाईंको सर्भरमा गरिनुपर्छ।
के मेरो टोकन यहाँ पेस्ट गर्नु सुरक्षित छ?
हो। डिकोडिङ पूर्णतया स्थानीय JavaScript प्रयोग गरी तपाईंको ब्राउजरभित्रै हुन्छ। टोकन कहिल्यै अपलोड, भण्डारण, वा कुनै सर्भरमा पठाइँदैन।
iss, sub, aud, exp र iat को अर्थ के हो?
ती दर्ता क्लेम हुन्: issuer, subject, audience, expiration time र issued-at time। तीन समय-सम्बन्धित क्लेमले सेकेन्डमा Unix टाइमस्ट्याम्प प्रयोग गर्छन्।
डिकोड गरेपछि देखिने क्लेममा भर पर्न मिल्छ?
आफैंमा मात्र होइन। डिकोड गरिएका क्लेम नक्कली वा समाप्त भएको टोकनबाट आउन सक्छन्। तिनमा भर पर्नुअघि सधैं हस्ताक्षर भेरिफाई गर्नुहोस् र सर्भर-साइडमा समाप्ति जाँच गर्नुहोस्।
मेरो टोकनमा थोप्लोले विभाजित तीन भाग किन छन्?
ती हेडर, पेलोड र हस्ताक्षर हुन्, प्रत्येक Base64url-इन्कोड गरिएको र थोप्लोले जोडिएको। थोप्लोले पार्सरहरूलाई हरेक खण्ड कहाँ सुरु र समाप्त हुन्छ भनी बताउँछ।