प्रोडक्शन में आपकी ऑथेंटिकेशन अचानक टूट गई। यूज़र्स को “Invalid Token” एरर्स आ रहे हैं, और आपको जल्दी से पता लगाना है कि क्यों। आप JWT खोलते हैं, तो वह बेतुकी अक्षर-पुंज जैसा दिखता है: बिंदुओं से अलग हुए तीन ब्लॉक जिनमें बेतरतीब कैरेक्टर हैं। डेटा वहाँ मौजूद है, लेकिन बिना पार्सर के आप उसे पढ़ नहीं सकते।
एक JWT Parser एक विशेष टूल है जो JSON Web Token के तीन हिस्सों — Header, Payload और Signature — को RFC 7519 स्टैंडर्ड के अनुसार तोड़ता है। अप्रैल 2026 तक, ये पार्सर Base64URL-एन्कोडेड डेटा को डिकोड करते हैं और सीक्रेट या पब्लिक कीज़ का उपयोग करके सिग्नेचर वेरिफाई करते हैं, ताकि यह सुनिश्चित हो सके कि टोकन के साथ छेड़छाड़ नहीं की गई है, और “alg: none” जैसे खतरों को रोकते हैं।
एक JWT Parser वास्तव में क्या करता है
JWT पार्सर को एक अनुवादक की तरह सोचें। यह एक लंबी, अपारदर्शी स्ट्रिंग लेता है और उसे वापस पढ़ने योग्य JSON ऑब्जेक्ट्स में बदल देता है। आधुनिक एप्लिकेशन्स में यूज़र पहचान को प्रबंधित करने और डेटा एक्सचेंज को सुरक्षित बनाने के लिए यह बुनियादी है।
आंतरिक रूप से, पार्सर उन दो बिंदुओं (.) को खोजता है जो टोकन को तीन खंडों में बांटते हैं:
| खंड | उद्देश्य | एन्कोडेड? | बिना की के पढ़ने योग्य? |
|---|---|---|---|
| Header | मेटाडेटा: साइनिंग एल्गोरिदम (HS256, RS256) | Base64URL | हाँ |
| Payload | क्लेम्स: यूज़र डेटा, एक्सपायरी, रोल्स | Base64URL | हाँ |
| Signature | प्रामाणिकता सिद्ध करने वाली डिजिटल सील | HMAC/RSA | नहीं — की चाहिए |
डिकोडिंग स्टेप-बाय-स्टेप: अंदर क्या होता है
आइए एक वास्तविक टोकन का ट्रेस करें। इस उदाहरण JWT को लें:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4iLCJpYXQiOjE3MDAwMDAwMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Step 1: बिंदुओं पर स्प्लिट करें
[0] eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
[1] eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4iLCJpYXQiOjE3MDAwMDAwMDB9
[2] SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Step 2: खंड [0] (Header) को Base64URL-डिकोड करें
{
"alg": "HS256",
"typ": "JWT"
}
Step 3: खंड [1] (Payload) को Base64URL-डिकोड करें
{
"sub": "1234567890",
"name": "John",
"iat": 1700000000
}
Step 4: खंड [2] (Signature) वेरिफाई करें — सीक्रेट की चाहिए
पार्सर Base64URL-एन्कोडेड header + “.” + payload लेता है, फिर सीक्रेट का उपयोग करके एक HMAC-SHA256 निकालता है। यदि परिणाम खंड [2] से मेल खाता है, तो टोकन प्रामाणिक है।
महत्वपूर्ण सुरक्षा नोट: Base64URL एन्क्रिप्शन नहीं है
नए डेवलपर्स के लिए एक आम जाल यह मान लेना है कि एन्कोडेड header और payload एन्क्रिप्टेड होते हैं। ऐसा नहीं है। जैसा JustUse.me बताता है, Base64URL एन्कोडिंग केवल JSON को URLs और headers के जरिए भेजने के लिए सुरक्षित बनाती है। जिसके पास भी टोकन है, वह बिना पासवर्ड या की के payload डिकोड कर सकता है।
JWT payload में कभी संवेदनशील डेटा (पासवर्ड, SSNs, API कीज़) स्टोर न करें। यह उस किसी को भी दिखाई देता है जो टोकन को इंटरसेप्ट करता है।
सिग्नेचर वेरिफिकेशन: सुरक्षा गेट
हालांकि कोई भी टोकन का डेटा पढ़ सकता है, सिग्नेचर वेरिफिकेशन ही वास्तव में आपके सिस्टम को सुरक्षित रखता है। एक JWT पार्सर केवल जानकारी पढ़ता ही नहीं — यह सिद्ध करता है कि वह कहाँ से आया।
पार्सर header, payload और एक की का उपयोग करके सिग्नेचर को फिर से निकालता है, फिर जांचता है कि परिणाम टोकन पर मौजूद सिग्नेचर से मेल खाता है या नहीं। यदि वे मेल नहीं खाते, तो टोकन के साथ छेड़छाड़ की गई है।
दो एल्गोरिदम परिवार
| एल्गोरिदम | की प्रकार | कैसे काम करता है | आम उपयोग केस |
|---|---|---|---|
| HS256 (HMAC) | सिमेट्रिक — साइन और वेरिफाई के लिए एक ही सीक्रेट की | दोनों पक्ष एक सीक्रेट साझा करते हैं | सिंगल-सर्विस ऑथ, एक टीम के भीतर माइक्रोसर्विसेज |
| RS256 (RSA) | असिमेट्रिक — प्राइवेट की साइन करती है, पब्लिक की वेरिफाई करती है | भेजने वाला प्राइवेट की रखता है; पब्लिक की वाला कोई भी वेरिफाई कर सकता है | OAuth2 प्रोवाइडर्स, थर्ड-पार्टी API इंटीग्रेशन |
| ES256 (ECDSA) | असिमेट्रिक — RSA जैसा ही मॉडल लेकिन एलिप्टिक कर्व्स के साथ | छोटी कीज़, तेज़ वेरिफिकेशन | मोबाइल ऐप्स, परफॉरमेंस-सेंसिटिव सर्विसेज |
“alg: none” अटैक
यह सबसे खतरनाक JWT कमजोरियों में से एक है। एक हमलावर header को बदलकर "alg": "none" का दावा करता है और सिग्नेचर हटा देता है। एक खराब तरीके से लागू पार्सर इसे स्वीकार कर सकता है, और बिना किसी वेरिफिकेशन के टोकन को मान्य मान सकता है।
रक्षा: आपके पार्सर को किसी भी ऐसे टोकन को स्पष्ट रूप से अस्वीकार करना होगा जिसमें एल्गोरिदम “none” हो या आपके अपेक्षित एल्गोरिदम से मेल नहीं खाता। Stas Persiianenko, जिन्होंने Apify JWT टूल विकसित किया, इस बात पर जोर देते हैं कि हालांकि टोकन डिज़ाइन के अनुसार पारदर्शी होते हैं, उनकी सुरक्षा इस बात पर निर्भर करती है कि पार्सर अनसाइन्ड या छेड़छाड़ वाले टोकन्स को सख्ती से अस्वीकार करे।
decoded = jwt.decode(token, key, algorithms=None) # NEVER do this
decoded = jwt.decode(token, key, algorithms=["HS256"])
स्टैंडर्ड JWT क्लेम्स: हर फ़ील्ड का क्या अर्थ है
एक JWT पार्सर payload से “क्लेम्स” निकालता है। ये क्रॉस-सिस्टम संगतता के लिए JOSE (JSON Object Signing and Encryption) फ्रेमवर्क का पालन करते हैं।
| क्लेम | पूरा नाम | उद्देश्य | उदाहरण मान |
|---|---|---|---|
iss |
Issuer | टोकन किसने जारी किया | "auth.example.com" |
sub |
Subject | वह यूज़र या एंटिटी जिसे टोकन दर्शाता है | "user:12345" |
aud |
Audience | टोकन का इच्छित प्राप्तकर्ता | "api.example.com" |
exp |
Expiration Time | टोकन कब अमान्य हो जाता है | 1700000000 (Unix timestamp) |
iat |
Issued At | टोकन कब बनाया गया | 1699999999 |
nbf |
Not Before | इस समय से पहले टोकन मान्य नहीं | 1699999999 |
jti |
JWT ID | टोकन के लिए विशिष्ट पहचानकर्ता | "a1b2c3d4" |
असिमेट्रिक सिग्नेचर का उपयोग करते समय, पार्सर अक्सर एक JWK (JSON Web Key) का संदर्भ लेते हैं — जो पब्लिक की दर्शाने वाली एक JSON संरचना है। पार्सर टोकन वेरिफाई करने के लिए जारीकर्ता के मेटाडेटा एंडपॉइंट से सही JWK को स्वचालित रूप से प्राप्त करता है।
लागूकरण: प्रोडक्शन के लिए वास्तविक कोड
PHP के साथ lcobucci/jwt
PHP इकोसिस्टम का स्टैंडर्ड lcobucci/jwt है। Packagist के अनुसार अप्रैल 2026 तक इसकी 322 मिलियन से अधिक इंस्टॉल हो चुकी हैं, जो इसे Laravel और Symfony प्रोजेक्ट्स के लिए पसंदीदा विकल्प बनाती है।
use Lcobucci\JWT\Configuration;
use Lcobucci\JWT\Signer\Hmac\Sha256;
use Lcobucci\JWT\Signer\Key\InMemory;
$config = Configuration::forSymmetricSigner(
new Sha256(),
InMemory::plainText('your-secret-key')
);
// Parsing and validating a token
$token = $config->parser()->parse($jwtString);
// Verify constraints: expiration, issuer, etc.
$constraints = [
new \Lcobucci\JWT\Validation\Constraint\IssuedBy('auth.example.com'),
new \Lcobucci\JWT\Validation\Constraint\PermittedFor('api.example.com'),
new \Lcobucci\JWT\Validation\Constraint\SignedWith(
$config->signer(),
$config->signingKey()
),
];
$isValid = $config->validator()->validate($token, ...$constraints);
Hono (Edge/Serverless) Web Crypto के साथ
हल्के एज एप्लिकेशन्स के लिए, Hono JWT Helper एक न्यूनतम decode() फंक्शन देता है जो सर्वरलेस प्लेटफॉर्म्स के लिए एकदम सही है जहाँ आप तेज़ कोल्ड स्टार्ट और न्यूनतम डिपेंडेंसीज़ चाहते हैं।
import { jwt } from 'hono/jwt'
// Middleware to verify JWT on every request
app.use('/api/*', jwt({ secret: 'your-secret' }))
// Access decoded claims in your handler
app.get('/api/profile', (c) => {
const payload = c.get('jwtPayload')
return c.json({ user: payload.sub })
})
MCP के साथ AI-चालित JWT विश्लेषण
2026 तक, Model Context Protocol (MCP) Claude Code या Cursor जैसे AI सहायकों को सीधे JWT टूल्स से बात करने देता है। एक MCP सर्वर सेटअप करें, और एक डेवलपर AI से कह सकता है कि “इन लॉग्स में सभी JWTs को एक्सपायरी एरर्स के लिए जांचें” — एजेंट कमांड लाइन के जरिए पार्सिंग संभाल लेता है।
Apify के अनुसार, 2026 तक बल्क प्रोसेसिंग की लागत लगभग $11.50 प्रति 10,000 टोकन है। यह ऑटोमेशन AI एजेंट्स को एक्सपायर हुए टोकन्स खोजने और तुरंत ऐप की सुरक्षा सेटिंग्स के लिए कोड फिक्स सुझाने देती है।
निष्कर्ष
JWT पार्सर केवल एक डिबगिंग सुविधा से कहीं बढ़कर है — यह एक महत्वपूर्ण सुरक्षा चौकी है। यह सिग्नेचर जांचों के जरिए सुनिश्चित करता है कि टोकन प्रामाणिक हैं और क्लेम वेरिफिकेशन से वैध हैं। दो सबसे महत्वपूर्ण नियम याद रखें: Base64URL एन्क्रिप्शन नहीं है, इसलिए payload में कभी सीक्रेट न रखें। और हमेशा स्पष्ट रूप से अनुमत एल्गोरिदम निर्दिष्ट करें ताकि “alg: none” अटैक रुक सकें।
प्रोडक्शन ऐप्स के लिए, अपना खुद का पार्सर बनाने के बजाय lcobucci/jwt या Hono के JWT हेल्पर जैसी सिद्ध लाइब्रेरीज़ का उपयोग करें। डिबगिंग और बल्क विश्लेषण के लिए, AI-चालित MCP टूल्स सुरक्षा ऑडिट्स को स्वचालित और व्यापक रखने का आधुनिक तरीका हैं।
FAQ
क्या मेरे ब्राउज़र में मिले JWT टोकन को डिकोड करना कानूनी है?
हाँ, यह पूरी तरह कानूनी है। JWTs पारदर्शी होने के लिए डिज़ाइन किए गए हैं — header और payload ट्रांसपोर्ट के लिए एन्कोड किए जाते हैं, गोपनीयता के लिए एन्क्रिप्ट नहीं। टोकन रखने का अर्थ है कि आपके पास उसके क्लेम्स में डेटा तक पहुँच है। हालांकि, जब टोकन्स में व्यक्तिगत जानकारी हो, तो हमेशा GDPR जैसे स्थानीय डेटा संरक्षण कानूनों का पालन करें।
मेरा JWT पार्सर अभी-अभी बनाए टोकन के लिए isExpired: true क्यों दिखाता है?
यह आमतौर पर टोकन बनाने वाले सर्वर और उसे पार्स करने वाले सिस्टम के बीच क्लॉक ड्रिफ्ट के कारण होता है। यदि दोनों सिस्टम्स के घड़ियाँ सिंक्रनाइज़्ड नहीं हैं (UTC/NTP के जरिए), तो exp या nbf क्लेम्स अमान्य दिख सकते हैं। इसे ठीक करने के लिए सुनिश्चित करें कि दोनों सिस्टम समय सिंक्रनाइज़ेशन के लिए NTP का उपयोग करें, या अपनी पार्सिंग लाइब्रेरी में एक छोटा “leeway” (आमतौर पर 60 seconds) जोड़ें ताकि मामूली विचलन का हिसाब रहे।
क्या मैं सीक्रेट या पब्लिक की के बिना JWT डिकोड कर सकता हूँ?
हाँ, आप हमेशा बिना की के Header और Payload डिकोड करके पढ़ सकते हैं क्योंकि वे केवल Base64URL-एन्कोडेड JSON हैं। हालांकि, आप संबंधित सीक्रेट (HS256 के लिए) या पब्लिक की (RS256 के लिए) के बिना Signature वेरिफाई नहीं कर सकते या यह भरोसा नहीं कर सकते कि डेटा प्रामाणिक है। वेरिफिकेशन के बिना, डेटा को अनवेरिफाइड और संभावित रूप से छेड़छाड़ वाला मानें।
“alg: none” अटैक क्या है और मैं इसे कैसे रोकूँ?
“alg: none” अटैक उन पार्सर्स का फायदा उठाता है जो बिना वैलिडेशन के टोकन header में निर्दिष्ट एल्गोरिदम को स्वीकार कर लेते हैं। एक हमलावर header को बदलकर "alg": "none" कर देता है और सिग्नेचर हटा देता है, जिससे एक संवेदनशील पार्सर टोकन को मान्य मान लेता है। इसे रोकने के लिए अपने वेरिफिकेशन कोड में हमेशा स्पष्ट रूप से अनुमत एल्गोरिदम निर्दिष्ट करें — कभी “none” स्वीकार न करें और टोकन को यह तय करने की अनुमति न दें कि कौन-सा एल्गोरिदम उपयोग हो।
