JWT जनरेटर और जाँचकर्ता: HS256, HS384 और HS512 के लिए

इसका इस्तेमाल कैसे करें

हेडर (JSON) और पेलोड (JSON) लिखें। समय भरने के लिए iat को अभी पर सेट करें, nbf को अभी पर सेट करें या exp को इतने बाद सेट करें इस्तेमाल करें।
एल्गोरिदम चुनें और सीक्रेट लिखें। अगर सीक्रेट Base64 में लिखा है, तो सीक्रेट की एन्कोडिंग में Base64 चुनें।
टोकन कॉपी करें। उसके तीन भाग बिंदुओं से अलग होते हैं: हेडर, पेलोड और सिग्नेचर।
कोई टोकन जाँचने वाला टोकन में चिपकाएँ, ताकि देखें कि उसका सिग्नेचर ऊपर के सीक्रेट से मेल खाता है या नहीं।

JWT कैसे साइन होता है

JSON Web Token (RFC 7519) एक हेडर और एक पेलोड है, जो हर एक JSON के रूप में लिखा जाता है और Base64url (RFC 7515) में कोड होता है, और एक बिंदु से जुड़ता है। सिग्नेचर इन दो भागों का HMAC है, जो सीक्रेट से बनता है (RFC 7518, खंड 3.2)। हेडर अपने alg फ़ील्ड में एल्गोरिदम का नाम लिखता है, और यह पेज वह फ़ील्ड उसी एल्गोरिदम पर सेट करता है जो आप चुनते हैं।

पेज हर JSON ऑब्जेक्ट को कोड करने से पहले उसके कॉम्पैक्ट रूप में लिखता है, इसलिए साइन किए गए बाइट वह कॉम्पैक्ट रूप हैं जो आपने लिखा, स्पेस और लाइन-ब्रेक वाला टेक्स्ट नहीं। जो भी पक्ष टोकन जाँचता है, वह उन्हीं बाइट से काम करता है जो उसे मिले, इसलिए टोकन दोनों तरह से वैध है।

साइनिंग इनपुट = BASE64URL(हेडर) . BASE64URL(पेलोड)
सिग्नेचर      = HMAC-SHA-256(सीक्रेट, साइनिंग इनपुट)
               (HS384 और HS512 HMAC-SHA-384 और HMAC-SHA-512 इस्तेमाल करते हैं)
टोकन         = साइनिंग इनपुट . BASE64URL(सिग्नेचर)

पेलोड में समय

क्लेम iat (जारी किया गया), nbf (इससे पहले नहीं) और exp (समाप्ति का समय) NumericDate हैं: 1 जनवरी 1970 की 00:00 UTC से गिनी गई सेकंड (RFC 7519, खंड 2 और 4.1)। टोकन exp पर या उसके बाद, और nbf से पहले स्वीकार नहीं होता। बटन आपके डिवाइस की घड़ी से समय लिखते हैं, इसलिए गलत घड़ी गलत समय देती है।

जाँच क्या करती है और क्या नहीं

जाँच हेडर और पेलोड का HMAC ठीक उसी रूप में फिर से निकालती है जैसे वे चिपकाए गए थे, और उसे सिग्नेचर से मिलाती है। वह alg none और HS256, HS384 और HS512 के सिवा हर एल्गोरिदम को मना करती है, ताकि टोकन खुद कमजोर जाँच न चुन सके।

वह यह जाँच नहीं करती कि क्लेम का मतलब क्या है: कि iss वही जारीकर्ता है जिसकी आप उम्मीद करते हैं, या aud आपकी सेवा का नाम है। ये जाँचें आपके एप्लिकेशन को करनी होंगी, जैसा RFC 8725 सलाह देता है।

उदाहरण: सीक्रेट your-256-bit-secret के साथ HS256

हेडर {"alg": "HS256", "typ": "JWT"}, पेलोड {"sub": "1234567890", "name": "Ada Lovelace", "iat": 1516239022} और UTF-8 सीक्रेट your-256-bit-secret के साथ पेज यह टोकन बनाता है:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTUxNjIzOTAyMn0.nmm0qepYRjhNji3O-jq8Pvcr7l_me1_bomw4EJucQCU

उसी सीक्रेट से जाँचने पर सिग्नेचर वैध निकलता है। टोकन में exp या nbf क्लेम नहीं है, इसलिए कोई समय उसे अमान्य नहीं बना सकता। किसी दूसरे सीक्रेट से जाँचने पर बताया जाता है कि सिग्नेचर मेल नहीं खाता।

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

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

नहीं। टोकन आपके ब्राउज़र में ब्राउज़र के अपने SubtleCrypto से साइन होता है। सीक्रेट सिर्फ तब तक रहता है जब तक पेज खुला है: वह न भेजा जाता है, न सहेजा जाता है, न लॉग होता है।

पेज कहता है कि सिग्नेचर मेल खाता है, फिर भी मेरी लाइब्रेरी टोकन क्यों ठुकराती है?

लाइब्रेरी exp या nbf समय, audience या issuer जाँच सकती है, या वह सीक्रेट दूसरी एन्कोडिंग में पढ़ती हो। सीक्रेट को उसी तरह UTF-8 या Base64 में पढ़ें जैसे आपकी लाइब्रेरी पढ़ती है, और समय को सही घड़ी से मिलाएँ।

alg none क्यों मना है?

alg none वाले टोकन का कोई सिग्नेचर नहीं होता, इसलिए उसे कोई भी लिख सकता है। सेवा को उसे ठुकराना चाहिए। यह पेज जाँच में उसे मना करता है, और उसकी साइनिंग हमेशा कोई HMAC एल्गोरिदम लिखती है।

सीक्रेट कितना लंबा होना चाहिए?

कम से कम हैश के परिणाम जितना: HS256 के लिए 32 बाइट, HS384 के लिए 48 और HS512 के लिए 64 (RFC 7518, खंड 3.2)। सीक्रेट छोटा हो तो पेज चेतावनी देता है।

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

नहीं। वह सिर्फ साझा सीक्रेट से साइन और जाँच करता है, HS256, HS384 या HS512 से। प्राइवेट RSA या ECDSA कुंजी से साइन किए टोकन को वह कुंजी चाहिए, जो यह पेज नहीं लेता।

सीक्रेट के लिए Base64 कब चुनना चाहिए?

तभी जब सीक्रेट Base64 में लिखा हो, जैसे JSON Web Key का k मान। नहीं तो सीक्रेट UTF-8 टेक्स्ट के रूप में वैसे ही पढ़ा जाता है जैसे आपने लिखा, स्पेस समेत।

स्रोत

आँकड़े और टेक्स्ट आखिरी बार मंगलवार, 10 नवंबर 2026 को जाँचे गए।