JWT: JSON Web Token क्या है, संरचना और उपयोग

JWT क्या है?

JSON Web Token (JWT) एक खुला मानक (RFC 7519) है जो पक्षों के बीच JSON ऑब्जेक्ट के रूप में जानकारी प्रसारित करने का एक कॉम्पैक्ट और स्व-निहित तरीका परिभाषित करता है। JWT में जानकारी को claims कहा जाता है — विषय (उपयोगकर्ता) और अतिरिक्त विशेषताओं के बारे में कथन। प्रत्येक claim एक कुंजी-मूल्य जोड़ी है: उपयोगकर्ता पहचानकर्ता, भूमिका, समाप्ति समय, जारीकर्ता।

JWT को स्व-निहित इसलिए कहा जाता है क्योंकि सत्यापन के लिए सभी आवश्यक जानकारी टोकन के अंदर ही होती है। सर्वर को टोकन की वैधता सत्यापित करने के लिए डेटाबेस या बाह्य भंडारण तक पहुंचने की आवश्यकता नहीं है — केवल हस्ताक्षर की जांच करनी होती है। यह गुण JWT को वितरित सिस्टम और माइक्रोसर्विस आर्किटेक्चर के लिए आदर्श बनाता है, जहां कई सेवाओं को साझा सत्र भंडारण के बिना अनुरोधों को प्रमाणित करना होता है।

Auth0, 2025 के अनुसार, 65% से अधिक मोबाइल और वेब एप्लिकेशन API प्रमाणीकरण के लिए JWT को प्राथमिक टोकन प्रारूप के रूप में उपयोग करते हैं, जो अपारदर्शी टोकन और सत्र पहचानकर्ताओं से आगे निकल गए हैं।

JWT संरचना: header, payload और signature

JWT तीन भागों से बना होता है जो बिंदुओं द्वारा अलग किए जाते हैं: header.payload.signature। प्रत्येक भाग Base64url-एन्कोडेड JSON है। आइए प्रत्येक भाग की विस्तार से जांच करें।

Header — एल्गोरिदम और टोकन प्रकार

Header में दो अनिवार्य फ़ील्ड होते हैं: alg (algorithm — हस्ताक्षर एल्गोरिदम) और typ (type — टोकन प्रकार, हमेशा “JWT”)। एल्गोरिदम सममित (HS256 — SHA-256 के साथ HMAC) या असममित (RS256 — SHA-256 के साथ RSA, ES256 — P-256 के साथ ECDSA) हो सकता है। असममित एल्गोरिदम बेहतर हैं क्योंकि वे क्लाइंट को गुप्त कुंजी के बिना हस्ताक्षर सत्यापित करने की अनुमति देते हैं।

डिकोड किए गए header का उदाहरण:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-id-1"
}

Payload — claims और डेटा

Payload में claims होते हैं — विषय के बारे में कथन। Claims तीन प्रकारों में विभाजित होते हैं: पंजीकृत (iss, sub, aud, exp, nbf, iat, jti), सार्वजनिक (डेवलपर द्वारा IANA रजिस्ट्री में परिभाषित), और निजी (पक्षों के बीच सहमत)। sub (subject) अद्वितीय उपयोगकर्ता पहचानकर्ता है। exp (expiration) टोकन समाप्ति टाइमस्टैम्प है। iss (issuer) टोकन जारीकर्ता है।

{
  "sub": "user-abc-123",
  "iss": "https://auth.example.com",
  "aud": "my-mobile-app",
  "exp": 1812345678,
  "iat": 1812342078,
  "role": "premium_user"
}

Signature — अखंडता सत्यापन

Signature गुप्त या निजी कुंजी का उपयोग करके header और payload के संयोजन पर हस्ताक्षर एल्गोरिदम लागू करके बनाई जाती है। सूत्र: HMAC के लिए HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret), या असममित एल्गोरिदम के लिए RSASHA256(...)। प्राप्तकर्ता उसी तरह हस्ताक्षर की गणना करता है और प्राप्त हस्ताक्षर से तुलना करता है — यदि वे मेल खाते हैं, तो डेटा में बदलाव नहीं किया गया है।

JWT कैसे काम करता है: निर्माण और सत्यापन

JWT के साथ कार्यप्रवाह दो चरणों में होता है: प्रमाणीकरण सर्वर द्वारा टोकन निर्माण (जारी करना) और क्लाइंट या संसाधन सर्वर द्वारा टोकन सत्यापन। प्रमाणीकरण सर्वर उपयोगकर्ता की साख प्राप्त करता है, claims के साथ payload बनाता है और उस पर हस्ताक्षर करता है। परिणामी JWT लॉगिन अनुरोध के उत्तर में या OAuth 2.0 / OpenID Connect प्रतिक्रिया निकाय में क्लाइंट को भेजा जाता है।

मोबाइल प्रमाणीकरण में JWT

मोबाइल एप्लिकेशन में, JWT का उपयोग इस प्रकार किया जाता है: सफल लॉगिन के बाद, उपयोगकर्ता को JWT प्रारूप में एक एक्सेस टोकन प्राप्त होता है। एप्लिकेशन इसे एक सुरक्षित भंडारण (iOS पर Keychain, Android पर EncryptedSharedPreferences) में संग्रहीत करता है। प्रत्येक API अनुरोध के साथ, एप्लिकेशन Authorization: Bearer <token> हेडर जोड़ता है। API सर्वर JWT हस्ताक्षर सत्यापित करता है, claims निकालता है और उनके आधार पर पहुंच निर्णय लेता है — डेटाबेस क्वेरी किए बिना।

Google Codelabs, 2025 के अनुसार, Firebase Authentication में JWT का उपयोग सत्र टोकन की तुलना में प्रमाणीकरण सर्वर पर अनुरोधों की संख्या को 40–60% तक कम कर देता है, क्योंकि डेटा प्रत्येक माइक्रोसर्विस पर स्थानीय रूप से सत्यापित किया जाता है। यह उच्च-लोड आर्किटेक्चर के लिए विशेष रूप से महत्वपूर्ण है, जहां विलंबता का प्रत्येक मिलीसेकंड उपयोगकर्ता अनुभव को प्रभावित करता है। प्रति मिनट 50,000 अनुरोधों पर, JWT पर स्विच करने से इंट्रोस्पेक्शन अनुरोधों को संभालने वाले 10 सर्वर इंस्टेंस तक बचाए जा सकते हैं।

JWT बनाम Session Token

JWT और Session Token एक ही समस्या को हल करते हैं — अनुरोध प्रमाणीकरण — लेकिन आर्किटेक्चर में मौलिक रूप से भिन्न होते हैं। Session Token एक यादृच्छिक पहचानकर्ता स्ट्रिंग है जो सर्वर पर संग्रहीत सत्र डेटा को संदर्भित करता है (stateful)। JWT एक स्व-निहित टोकन है जिसमें सभी डेटा स्वयं के भीतर होता है (stateless)।

JWT के लाभ और हानि

JWT वितरित सिस्टम में बेहतर है: माइक्रोसर्विसेज़ बिना साझा भंडारण के स्थानीय रूप से टोकन सत्यापित कर सकती हैं। उदाहरण के लिए, पांच माइक्रोसर्विसेज़ वाले आर्किटेक्चर में, प्रत्येक सेवा बिना नेटवर्क कॉल के 1–2 मिलीसेकंड में JWT सत्यापित करती है, जबकि session token को प्रत्येक अनुरोध पर केंद्रीय Redis क्वेरी की आवश्यकता होती है, जिसमें 10–30 मिलीसेकंड की विलंबता जुड़ती है। हालांकि, JWT को रद्द करना कठिन है — एक बार जारी होने के बाद, यह समाप्ति तक वैध रहता है। Session Token को DB या Redis से रिकॉर्ड हटाकर आसानी से रद्द किया जा सकता है।

मोबाइल एप्लिकेशन के लिए, एक संयुक्त दृष्टिकोण — छोटी आयु (15–30 मिनट) वाला JWT और Refresh Token — प्रदर्शन और सुरक्षा के बीच संतुलन प्रदान करता है। JWT का उपयोग API एक्सेस के लिए किया जाता है, जबकि refresh token (आमतौर पर अपारदर्शी) का उपयोग नए JWT प्राप्त करने के लिए किया जाता है। यदि JWT से समझौता होता है, तो हमलावर के पास 15–30 मिनट तक पहुंच होती है; यदि refresh token से समझौता होता है, तो रोटेशन और पुन: उपयोग का पता लगाने के माध्यम से सत्र अवरुद्ध कर दिया जाता है।

JWT सुरक्षा

JWT की सुरक्षा सही कार्यान्वयन पर निर्भर करती है। सबसे आम भेद्यता “alg none” हमला है: हमलावर टोकन के header को “alg”: “none” में बदल देता है, और सर्वर, एल्गोरिदम सत्यापित किए बिना, जाली टोकन स्वीकार कर लेता है। सुरक्षा: हमेशा जांचें कि header में एल्गोरिदम अपेक्षित (RS256, ES256) से मेल खाता है, और alg: none वाले टोकन को अस्वीकार करें।

सामान्य भेद्यताएं

JWT भेद्यताओं में शामिल हैं: HMAC के लिए कमजोर गुप्त कुंजी (मिनटों में ब्रूट-फोर्स), निजी कुंजी लीक (सर्वर की ओर से किसी भी डेटा पर हस्ताक्षर करना), payload में संवेदनशील डेटा संग्रहीत करना (JWT एन्क्रिप्ट नहीं करता, केवल हस्ताक्षर करता है), JWK header इंजेक्शन हमला (कस्टम सार्वजनिक कुंजी इंजेक्ट करना)। विश्वसनीय लाइब्रेरी — Nimbus JOSE + JWT, jjwt (io.jsonwebtoken), PyJWT — का उपयोग इन भेद्यताओं के शोषण के जोखिम को कम करता है।

एक अतिरिक्त सुरक्षा उपाय है JWK Thumbprint (RFC 7638): header में थंबप्रिंट के माध्यम से सार्वजनिक कुंजी को टोकन से बांधना। यदि सर्वर प्रत्येक क्लाइंट के लिए अपेक्षित थंबप्रिंट संग्रहीत करता है, तो JWK header इंजेक्शन असंभव हो जाता है — सर्वर किसी भी कुंजी को अस्वीकार करता है जो पंजीकृत से मेल नहीं खाती। OAuth Security Workshop 2025 वित्तीय और चिकित्सा अनुप्रयोगों में उपयोग किए जाने वाले सभी JWT के लिए JWK Thumbprint को अनिवार्य सुरक्षा के रूप में अनुशंसित करता है।

कोड उदाहरण: Kotlin में JWT के साथ काम करना

jjwt लाइब्रेरी (auth0/java-jwt) Android एप्लिकेशन में कुछ पंक्तियों में JWT बनाने और सत्यापित करने की अनुमति देती है। नीचे दिए गए उदाहरण में, सर्वर sub और role के साथ एक टोकन उत्पन्न करता है, और क्लाइंट हस्ताक्षर सत्यापित करता है। सर्वर पर गुप्त कुंजी के सुरक्षित भंडारण के लिए, पर्यावरण चर या HSM (हार्डवेयर सुरक्षा मॉड्यूल) का उपयोग करें — कोड या कॉन्फ़िगरेशन फ़ाइल में कुंजी संग्रहीत करना एक गंभीर सुरक्षा त्रुटि है।

JWT जनरेशन

val secret = "my-256-bit-secret-key-here"
val token = JWT.create()
    .withSubject("user-abc-123")
    .withIssuer("auth.example.com")
    .withClaim("role", "premium_user")
    .withExpiresAt(Date(System.currentTimeMillis() + 3600000))
    .sign(Algorithm.HMAC256(secret))

// क्लाइंट को टोकन भेजना
println("JWT: $token")

JWT सत्यापन

fun verifyToken(token: String): Boolean {
    return try {
        val decoded = JWT.require(Algorithm.HMAC256(secret))
            .withIssuer("auth.example.com")
            .build()
            .verify(token)
        // हस्ताक्षर मान्य है, claims निकाले गए
        println("Subject: ${decoded.subject}")
        true
    } catch (e: Exception) {
        println("टोकन अमान्य: ${e.message}")
        false
    }
}