इस्तेमाल करने का तरीका

HS256, HS384 या HS512 चुनें।
पेलोड claims संपादित करें, और वर्तमान समय व समाप्ति जोड़ने के लिए “Set iat and exp” पर क्लिक करें।
एक परीक्षण सीक्रेट दर्ज करें, या एक यादृच्छिक 256-बिट सीक्रेट जनरेट करें।
साइन किया गया टोकन कॉपी करें। किसी टोकन की जाँच करने के लिए, “Verify signature” पर स्विच करें, उसे पेस्ट करें और सीक्रेट दर्ज करें।

यह कैसे काम करता है

एक JSON Web Token (RFC 7519) में तीन Base64URL-एन्कोडेड भाग होते हैं: एक हेडर, क्लेम का पेलोड और एक सिग्नेचर। HMAC एल्गोरिदम HS256, HS384 और HS512 के साथ, सिग्नेचर “header.payload” पर SHA-256, SHA-384 या SHA-512 का उपयोग करके एक HMAC होता है, जिसे साझा सीक्रेट से कुंजीबद्ध किया जाता है। सीक्रेट वाला कोई भी व्यक्ति टोकन बना और सत्यापित कर सकता है।

यह टूल हेडर और पेलोड को कॉम्पैक्ट JSON के रूप में सीरियलाइज़ करता है, उन्हें एन्कोड करता है, और crypto.subtle (आपके ब्राउज़र में निर्मित Web Crypto API) से हस्ताक्षर करता है। हेडर में alg फ़ील्ड हमेशा चुने गए एल्गोरिदम से मेल खाता है, typ डिफ़ॉल्ट रूप से JWT होता है, और kid जैसे अन्य हेडर फ़ील्ड बनाए रखे जाते हैं। “Set iat and exp” वर्तमान समय को iat (issued at) के रूप में लिखता है और चुने गए जीवनकाल को exp के रूप में जोड़ता है, दोनों 1 जनवरी 1970 UTC से सेकंडों में। परिणाम अन्य JWT लाइब्रेरीज़ से मेल खाता है; उदाहरण के लिए, क्लासिक jwt.io नमूना टोकन बिल्कुल पुन: प्रस्तुत किया जाता है।

सीक्रेट सादा टेक्स्ट (इसके UTF-8 बाइट्स कुंजी हैं) या Base64/Base64URL-एन्कोडेड बाइट्स हो सकता है, जिनका उपयोग कई फ्रेमवर्क करते हैं। रैंडम सीक्रेट बटन crypto.getRandomValues से 32 रैंडम बाइट्स बनाता है। HS256 के लिए, कम से कम 32 रैंडम बाइट्स का उपयोग करें; छोटे मानव-चुने सीक्रेट को किसी भी टोकन से ऑफ़लाइन अनुमान लगाया जा सकता है।

सत्यापन टोकन को डिकोड करता है, जाँचता है कि यह HMAC एल्गोरिदम का उपयोग करता है, और crypto.subtle.verify के साथ सिग्नेचर की पुनर्गणना करता है। यह यह भी दिखाता है कि exp या nbf का अर्थ है कि टोकन समाप्त हो गया है या अभी तक मान्य नहीं है। RS256, ES256 और अन्य सार्वजनिक-कुंजी एल्गोरिदम समर्थित नहीं हैं, और यहाँ सत्यापन issuer, audience या आपके एप्लिकेशन द्वारा आवश्यक अन्य क्लेम की जाँच नहीं करता है।

उदाहरण

स्थानीय रूप से API का परीक्षण करना

आपका डेवलपमेंट सर्वर “dev-secret-change-me” से हस्ताक्षरित HS256 टोकन की अपेक्षा करता है। sub को एक परीक्षण उपयोगकर्ता ID पर सेट करें, 1 घंटे के साथ “Set iat and exp” पर क्लिक करें, सीक्रेट दर्ज करें और टोकन को Authorization: Bearer हेडर में भेजें।

किस सीक्रेट से टोकन साइन हुआ, यह जाँचें

एक स्टेजिंग टोकन अस्वीकृत होता है। इसे “Verify signature” में पेस्ट करें और स्टेजिंग सीक्रेट आज़माएँ: “Signature not valid” बताता है कि टोकन किसी दूसरे सीक्रेट से साइन किया गया था या सीक्रेट अलग फ़ॉर्मेट में है (टेक्स्ट बनाम Base64)।

jwt.io उदाहरण दोहराना

हेडर {"alg":"HS256","typ":"JWT"}, पेलोड {"sub":"1234567890","name":"John Doe","iat":1516239022} और सीक्रेट “your-256-bit-secret” के साथ, टोकन SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c पर समाप्त होता है, जैसा jwt.io पर होता है।

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

क्या मेरा सीक्रेट आपके सर्वर पर भेजा जाता है?

नहीं। साइनिंग और सत्यापन आपके ब्राउज़र में Web Crypto API के साथ चलते हैं, और सीक्रेट कहीं संग्रहीत या भेजा नहीं जाता। फिर भी हम केवल परीक्षण सीक्रेट उपयोग करने की सलाह देते हैं, क्योंकि असली साइनिंग सीक्रेट को किसी वेबसाइट में कभी टाइप नहीं करना चाहिए।

सीक्रेट सही होने के बावजूद सिग्नेचर अमान्य क्यों है?

सीक्रेट का फ़ॉर्मेट जाँचें। कुछ सिस्टम सीक्रेट के टेक्स्ट का उपयोग करते हैं, अन्य पहले इसे Base64 से डिकोड करते हैं, जिससे अलग key bytes मिलते हैं। यह भी जाँचें कि टोकन बदला नहीं गया है और वह उसी एल्गोरिदम का उपयोग करता है।

क्या RS256 या ES256 टोकन बनाए जा सकते हैं?

इस टूल से नहीं। यह केवल साझा-सीक्रेट HMAC एल्गोरिदम HS256, HS384 और HS512 का समर्थन करता है।

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

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

गोपनीयता

टोकन केवल आपके ब्राउज़र में Web Crypto API के साथ बनाए और सत्यापित किए जाते हैं। हेडर, पेलोड, टोकन और सीक्रेट अपलोड, संग्रहीत या एनालिटिक्स में शामिल नहीं किए जाते।