JWT हस्ताक्षरकर्ता और सत्यापनकर्ता
अपनी कुंजी से टोकन पर हस्ताक्षर करें, उसे किसी रहस्य, PEM, JWK या लाइव JWKS के विरुद्ध सत्यापित करें — और वह कुंजी सेट बनाएँ जो आपका API प्रकाशित करता है। सारी क्रिप्टोग्राफी आपके ब्राउज़र में चलती है।
JWT उतना ही भरोसेमंद है जितना उसका हस्ताक्षर। कोई भी टोकन पढ़ सकता है — डिकोड करना कुछ साबित नहीं करता — इसलिए यह टूल वह काम करता है जो डिकोडर नहीं कर सकता: यह आपकी कुंजी से टोकनों पर हस्ताक्षर करता है (HS256/384/512, RS256/384/512, ES256/384/512, EdDSA), उन्हें किसी रहस्य, PEM या JWK सार्वजनिक कुंजी, चिपकाई गई JWKS या kid मिलान वाली लाइव JWKS URL के विरुद्ध सत्यापित करता है, और वह JWKS बनाता है जो आपका अपना API प्रकाशित करता है। साथी गाइड JWT पर हस्ताक्षर करना और उन्हें सत्यापित करना समझाती है कि डिकोड करना सत्यापित करना क्यों नहीं है, एल्गोरिदम-कन्फ़्यूज़न हमला कैसे काम करता है, और "सत्यापित" क्या साबित करता है — और क्या नहीं। बिना कुंजी के टोकन पढ़ने के लिए JWT डिकोडर का उपयोग करें; कुंजियों के लिए SSH Key Suite में बनाना और बदलना मिलता है।
अंतिम अपडेट:
टोकन पर हस्ताक्षर करें
यह रहस्य 32 अक्षरों से छोटा है। छोटे रहस्य ऑफ़लाइन अनुमान से जल्दी टूट जाते हैं — किसी असली काम के लिए लंबा यादृच्छिक रहस्य उपयोग करें।
टोकन सत्यापित करें
“सत्यापित” का अर्थ है कि हस्ताक्षर इस कुंजी से मेल खाता है और टोकन अपनी वैधता अवधि के भीतर है। इसका अर्थ यह नहीं है कि जारीकर्ता भरोसेमंद है — वह इस पर निर्भर है कि कुंजी कहाँ से आई।
JWKS बनाएँ और मान्य करें
JWKS बनाएँ
बनाई गई कुंजी, PEM या चिपकाई गई JWK से कुंजियाँ जोड़ें। हर प्रविष्टि को kid मिलता है — जहाँ गणना हो सके वहाँ RFC 7638 थंबप्रिंट, अन्यथा एक यादृच्छिक id जिसे पेज ऐसा ही बताता है।
इस सेट की कुंजियाँ
अभी कोई कुंजी नहीं है। ऊपर से एक बनाएँ या PEM या JWK चिपकाएँ।
JWKS मान्य करें
कुंजी बदलें (PEM ⇄ JWK)
हस्ताक्षर टैब पर कुंजी चिपकाएँ, वहाँ एक बनाएँ, या नीचे बदलें। HMAC रहस्यों का कोई PEM रूप नहीं होता — oct JWK ही पूरी कुंजी है।
🔒 हस्ताक्षर और सत्यापन WebCrypto से स्थानीय रूप से होते हैं। रहस्य और निजी कुंजियाँ कभी भेजी, संग्रहीत या लॉग नहीं की जातीं — पेज रीफ़्रेश करते ही वे चली जाती हैं।
आपकी कुंजियाँ कभी इस पेज को नहीं छोड़तीं
हस्ताक्षर और सत्यापन आपके ब्राउज़र के WebCrypto से, उन कुंजियों पर होते हैं जिन्हें आप चिपकाते हैं या यहाँ बनाते हैं। रहस्य और निजी कुंजियाँ केवल पेज की मेमोरी में रहती हैं: वे अपलोड नहीं होतीं, localStorage या कुकीज़ में नहीं लिखी जातीं, और कभी URL में नहीं आतीं। पेज रीफ़्रेश या बंद करते ही वे चली जाती हैं। एकमात्र अपवाद JWKS URL फ़ेच है, जो आप स्वयं शुरू करते हैं: वह केवल वह URL भेजता है जो आपने लिखा था, सार्वजनिक कुंजियाँ लाने के लिए — कभी कोई रहस्य नहीं। उत्पादन कुंजी कहीं भी चिपकाने से पहले JWT पर हस्ताक्षर करना और उन्हें सत्यापित करना पढ़ें।
ईमानदार सीमाएँ
EdDSA के लिए आधुनिक ब्राउज़र चाहिए: पुराने ब्राउज़रों में WebCrypto Ed25519 नहीं होता, और यह पेज हस्ताक्षर गढ़ने के बजाय यह बात साफ़ कहता है। ECDSA P-256 वह विकल्प है जो हर जगह काम करता है।
एन्क्रिप्टेड PEM (पासफ़्रेज़ से बंद निजी कुंजी) संस्करण 1 में समर्थित नहीं है। पेज इसे खुलकर मना करता है — पहले openssl pkcs8 -topk8 -nocrypt से डिक्रिप्ट करें, और पासफ़्रेज़ कभी किसी वेब पेज में न चिपकाएँ।
JWKS URL फ़ेच इस बात पर निर्भर है कि वह सर्वर CORS हेडर भेजता है या नहीं। कई पहचान प्रदाता भेजते हैं; जब कोई नहीं भेजता, तो फ़ेच ईमानदारी से विफल होता है और पेज आपसे JWKS चिपकाने को कहता है। केवल सार्वजनिक कुंजियाँ ही फ़ेच की जाती हैं — JWKS URL में कभी कोई रहस्य नहीं होता।
हस्ताक्षर करना डिकोड करने से कब बेहतर है
JWT को डिकोड करना उसे पढ़ना है: हेडर और पेलोड base64url हैं, और टोकन जिसके पास भी है वह दोनों देख सकता है। इसीलिए अकेला डिकोडर वह एकमात्र सवाल कभी नहीं सुलझा सकता जो मायने रखता है — क्या जारीकर्ता ने सच में इस पर हस्ताक्षर किए थे? हस्ताक्षर करना काम का दूसरा आधा हिस्सा है: जिसके पास निजी कुंजी (या HMAC रहस्य) है वही हस्ताक्षर बनाता है, और सत्यापन सार्वजनिक कुंजी से वही गणित दोहराता है। यह पेज दोनों हिस्से आपके ब्राउज़र में रखता है, क्योंकि शामिल कुंजियाँ वे सबसे संवेदनशील इनपुट हैं जिन्हें कोई वेब टूल कभी छूता है।
यह बँटवारा असममित एल्गोरिदम के लिए सबसे ज़्यादा मायने रखता है। HS256 में जो रहस्य सत्यापित करता है वही हस्ताक्षर करता है — जो कोई आपके टोकन जाँच सकता है वह उन्हें बना भी सकता है, जो एक ही सेवा के भीतर ठीक है और बाकी हर जगह एक लीक है। RS256, ES256 या EdDSA में हस्ताक्षर कुंजी जारीकर्ता के पास रहती है और केवल सार्वजनिक कुंजी यात्रा करती है: आपका API अपनी JWKS प्रकाशित कर सकता है, नया kid जोड़कर कुंजियाँ घुमा सकता है, और दुनिया का हर सत्यापनकर्ता बिना जालसाज़ी की शक्ति रखे टोकन जाँच सकता है।
यह टूल क्या करने से मना करता है
दो मना जानबूझकर हैं। पहला है alg: none: जो टोकन दावा करता है कि उसे किसी हस्ताक्षर की ज़रूरत नहीं, उसे कारण सहित सीधे खारिज कर दिया जाता है — जो सत्यापनकर्ता उसे स्वीकार करता है वह जालसाज़ी स्वीकार करता है। दूसरा है एल्गोरिदम कन्फ़्यूज़न: HMAC रहस्य के साथ पेश किया गया RS256 टोकन (या उल्टा) स्पष्ट चेतावनी के साथ विफल होता है, कुंजी को दूसरे परिवार में चुपचाप फिर से समझने से कभी नहीं। दोनों क्लासिक JWT हमले हैं, और दोनों यहाँ संरचनात्मक रूप से रोके गए हैं — कुंजी का परिवार टोकन के alg परिवार से मेल खाना चाहिए, वरना सत्यापन विफल होता है।
तीसरी मना और भी सूक्ष्म है: यह पेज आपको कभी नहीं बताता कि कोई टोकन "भरोसेमंद" है। वैध हस्ताक्षर साबित करता है कि टोकन किसी कुंजी से हस्ताक्षरित था, और समाप्ति जाँच साबित करती है कि वह अपनी अवधि के भीतर है — बस इतना ही। उस कुंजी पर भरोसा करना है या नहीं, यह इस बात का निर्णय है कि वह कहाँ से आई: आपके पहचान प्रदाता की well-known URL से फ़ेच की गई JWKS, आपने स्वयं पिन की हुई सार्वजनिक कुंजी, आपने बनाया हुआ रहस्य। गाइड JWT पर हस्ताक्षर करना और उन्हें सत्यापित करना बताती है कि "सत्यापित" क्या साबित करता है और क्या नहीं।
JWT शब्द, सटीक रूप से
JWT. JSON Web Token (RFC 7519): पक्षों के बीच दावे ले जाने का सघन, URL-सुरक्षित तरीका — header.payload.signature, प्रत्येक base64url-एन्कोडेड। पेलोड कोई भी पढ़ सकता है; केवल हस्ताक्षर रहस्य पर निर्भर है।
JWS. JSON Web Signature (RFC 7515): JWT के नीचे का हस्ताक्षर प्रारूप। JWT वह JWS है जिसका पेलोड JSON दावों का सेट है।
JWK. JSON Web Key (RFC 7517): एक क्रिप्टोग्राफ़िक कुंजी को दर्शाने वाला JSON ऑब्जेक्ट — kty, और कुंजी सामग्री (RSA के लिए n/e, EC के लिए x/y, Ed25519 के लिए x, साझा रहस्य के लिए k)।
JWKS. JSON Web Key Set: "keys" ऐरे वाला ऑब्जेक्ट — जारीकर्ता द्वारा अपनी सार्वजनिक कुंजियाँ प्रकाशित करने का मानक तरीका, आमतौर पर /.well-known/jwks.json पर।
kid. कुंजी ID: वह हेडर दावा जो बताता है कि टोकन पर किस कुंजी ने हस्ताक्षर किए। सत्यापनकर्ता उसे JWKS से मिलाता है; उसके बिना, एक कुंजी वाले सेट का उपयोग होता है और पेज ऐसा ही कहता है।
alg. हस्ताक्षर एल्गोरिदम का नाम बताने वाला हेडर दावा (HS256, RS256, ES256, EdDSA…)। सत्यापनकर्ता को स्वीकार्य एल्गोरिदम तय करने चाहिए — टोकन के अपने alg दावे पर भरोसा करना ही कन्फ़्यूज़न हमला है।
HMAC. Hash-based Message Authentication Code: सममित हस्ताक्षर — एक ही रहस्य हस्ताक्षर करता और सत्यापित करता है। तेज़ और सरल; रहस्य रखने वाला हर कोई टोकन बना सकता है।
RSASSA-PKCS1-v1_5. RS256/384/512 के पीछे की RSA हस्ताक्षर योजना: हैश को लपेटकर निजी घातांक से उठाया जाता है। नियतात्मक — एक ही इनपुट हमेशा एक ही हस्ताक्षर बाइट देता है।
EdDSA. Edwards-curve Digital Signature Algorithm: यहाँ Ed25519 — छोटी कुंजियाँ, तेज़ सत्यापन, नियतात्मक हस्ताक्षर। WebCrypto समर्थन के लिए आधुनिक ब्राउज़र चाहिए।
अक्सर पूछे जाने वाले प्रश्न
क्या इस पेज में निजी कुंजी चिपकाना सुरक्षित है?
इस पेज पर कुंजी कभी आपका ब्राउज़र नहीं छोड़ती: हस्ताक्षर WebCrypto से पेज की मेमोरी में होता है, कुछ भी अपलोड, संग्रहीत या लॉग नहीं होता, और रीफ़्रेश उसे मिटा देता है। असुरक्षित तरीका सर्वर-पक्ष हस्ताक्षरकर्ता है, जहाँ आपकी निजी कुंजी नेटवर्क पार करती है। स्थानीय रूप से भी, भरोसेमंद डिवाइस का उपयोग करें — और साझा मशीन पर चिपकाई गई उत्पादन कुंजी को उजागर मानें। असली कुंजियाँ चिपकाने के बजाय यहाँ परीक्षण कुंजियाँ बनाएँ।
मेरा RS256 टोकन मेरे रहस्य से सत्यापित क्यों नहीं होता?
क्योंकि रहस्य और RSA कुंजी अलग परिवार हैं, और पेज उन्हें मिलाने से मना करता है — यही मना एल्गोरिदम-कन्फ़्यूज़न सुरक्षा है। RS256 टोकन को जारीकर्ता की RSA सार्वजनिक कुंजी (PEM, JWK या JWKS) चाहिए; रहस्य केवल HS256/384/512 सत्यापित कर सकता है। यदि आपकी सार्वजनिक कुंजी गलत रूप में है, तो उसे बदलें: JWKS टैब PEM ⇄ JWK बदलता है।
JWKS URL फ़ेच असल में क्या भेजता है?
आपके लिखे URL पर एक GET अनुरोध, JSON माँगते हुए। उसके साथ कोई कुंजी, कोई रहस्य, कोई टोकन और कोई पहचानकर्ता नहीं जाता — जवाब सार्वजनिक कुंजियों का सेट है। यदि सर्वर CORS हेडर नहीं भेजता, तो ब्राउज़र पढ़ना रोक देता है और पेज आपसे JWKS चिपकाने को कहता है।
मेरा टोकन यहाँ सत्यापित होता है पर API उसे अस्वीकार कर देता है। क्यों?
यहाँ सत्यापन आपकी दी हुई कुंजी के विरुद्ध हस्ताक्षर और समय अवधि जाँचता है। API दावे भी जाँचता है: वह जारीकर्ता (iss) जिसकी वह अपेक्षा करता है, वह ऑडियंस (aud) जिसकी वह सेवा करता है, और क्या कुंजी id (kid) वह है जिस पर वह अभी भरोसा करता है। घुमाई जा चुकी कुंजी से हस्ताक्षरित टोकन, या किसी दूसरी ऑडियंस के लिए बना टोकन, गणितीय रूप से सत्यापित होता है और फिर भी अस्वीकार किया जाता है — सही ही।
EdDSA मेरे ब्राउज़र में काम नहीं करता। अब क्या करें?
Ed25519 के लिए आधुनिक ब्राउज़र चाहिए — पुराने ब्राउज़रों में WebCrypto Ed25519 बिल्कुल नहीं होता, और यह पेज गढ़ने के बजाय ऐसा ही कहता है। विकल्प के रूप में ES256 (ECDSA P-256) उपयोग करें: यह हर जगह समर्थित है जहाँ WebCrypto मौजूद है, और पेज आपके लिए कुंजी बना सकता है। यदि Ed25519 ही चाहिए, तो ब्राउज़र अपडेट करें।