FlowingDev

JWT, समझाया गया: वो टोकन जो अपना पासपोर्ट खुद लेकर चलता है

JSON वेब टोकन (JWT) के बारे में जानें, जो पार्टियों के बीच JSON ऑब्जेक्ट के रूप में जानकारी को सुरक्षित रूप से प्रसारित करने का एक कॉम्पैक्ट, सेल्फ-कन्टेन्ड मानक है।

टूल आज़माएँ: JWT व्यूअर

एक वाक्य में

एक JSON वेब टोकन (JWT) दो पार्टियों के बीच ट्रांसफर किए जाने वाले दावों (claims) को दर्शाने का एक कॉम्पैक्ट, URL-सुरक्षित तरीका है, जिसका उपयोग आमतौर पर ऑथेंटिकेशन और ऑथराइजेशन के लिए इस तरह से किया जाता है जिसे वेरिफाई और ट्रस्ट किया जा सके।

यह क्या समस्या हल करता है

पुराने ज़माने में—मतलब, 2000 के दशक की शुरुआत में—अगर आप किसी वेबसाइट में लॉग इन करते, तो सर्वर आपके लिए एक "सेशन" बनाता। यह सर्वर पर एक छोटी सी फाइल की तरह था जिसमें लिखा होता, "User 123 लॉग इन है और उसने अपनी शॉपिंग कार्ट में एक रबर का मुर्गा डाला है।" सर्वर आपके ब्राउज़र को सेशन आईडी के साथ एक छोटी सी कुकी देता, जैसे कोट चेक करने वाली टिकट। हर अगले रिक्वेस्ट पर, आपका ब्राउज़र वह टिकट दिखाता, सर्वर उसे देखता, आपकी फाइल ढूंढता, और याद रखता कि आप कौन हैं।

यह एक अकेले, मोनोलिथिक सर्वर के लिए ठीक काम करता था। लेकिन फिर वेब में धमाका हो गया। हमारे पास माइक्रोसर्विसेज, सिंगल-पेज एप्लिकेशन (SPAs), और मोबाइल ऐप्स आ गए जो सभी एक ही बैकएंड से बात करते थे। अब, आपका लॉगिन रिक्वेस्ट शायद सर्वर A पर जाए, लेकिन आपकी प्रोफाइल लाने का अगला रिक्वेस्ट सर्वर B पर जा सकता है। सर्वर B को सर्वर A पर रखी सेशन फाइल के बारे में कैसे पता चलेगा?

आप उपयोगकर्ता को हमेशा एक ही सर्वर से बात करने के लिए मजबूर कर सकते हैं ("स्टिकी सेशंस"), लेकिन यह एक अड़चन (bottleneck) है। आप एक सेंट्रलाइज्ड सेशन डेटाबेस (जैसे Redis) बना सकते हैं जिसे सभी सर्वर साझा करें, लेकिन यह मैनेज करने के लिए एक और इंफ्रास्ट्रक्चर और फेल होने का एक और पॉइंट है।

मूल समस्या है स्टेटफुलनेस। सर्वर को आपको याद रखना पड़ता है।

JWTs (उच्चारण "जॉट्स") ने इस विचार को सिर के बल खड़ा कर दिया। क्या हो अगर उपयोगकर्ता अपनी पहचान का सबूत खुद लेकर चल सके, जैसे पासपोर्ट? टोकन में ही वह सारी जानकारी होगी जिसकी सर्वर को जरूरत है: उपयोगकर्ता कौन है, वे क्या करने के लिए अधिकृत हैं, और उनकी पहुंच कब समाप्त होती है। सर्वर को रिक्वेस्ट के बीच कुछ भी याद रखने की जरूरत नहीं है। यह स्टेटलेस ऑथेंटिकेशन है, और यह स्केलेबल, डिस्ट्रिब्यूटेड सिस्टम बनाने की कुंजी है। सर्वर को बस यह जांचना है कि पासपोर्ट (JWT) वैध है और नकली नहीं है।

यह अंदर से कैसे काम करता है

एक JWT अनाप-शनाप बकवास का एक अबोधगम्य गोला नहीं है। यह एक बहुत ही विशिष्ट, संरचित स्ट्रिंग है जो तीन भागों से बनी होती है, जिन्हें डॉट्स (.) से अलग किया जाता है।

xxxxx.yyyyy.zzzzz

आइए हर हिस्से को तोड़कर देखें।

द हेडर (The Header - "टाइप" टैग)

पहला भाग हेडर है। यह एक सरल JSON ऑब्जेक्ट है जिसमें टोकन के बारे में मेटाडेटा होता है, मुख्य रूप से उपयोग किया गया साइनिंग एल्गोरिथ्म और टोकन का प्रकार।

{
  "alg": "HS256",
  "typ": "JWT"
}
  • alg: साइनिंग एल्गोरिथ्म। HS256 का मतलब है कि यह टोकन HMAC-SHA256 के साथ साइन किया गया है, जो एक सिमेट्रिक एल्गोरिथ्म है (इस पर थोड़ी देर में और बात करेंगे)। अन्य सामान्य विकल्पों में RS256 (RSA पब्लिक/प्राइवेट की-पेयर का उपयोग करके) शामिल है।
  • typ: टोकन का प्रकार। JWTs के लिए, यह बस "JWT" होता है।

इस JSON को फिर Base64Url एन्कोड किया जाता है ताकि टोकन का पहला भाग बन सके। Base64 एक एन्कोडिंग स्कीम है, एन्क्रिप्शन नहीं। यह सिर्फ बाइनरी डेटा को एक टेक्स्ट स्ट्रिंग में बदल देता है जिसे वेब पर ट्रांसमिट करना सुरक्षित है। इसे ऐसे सोचें जैसे पोस्टकार्ड के पीछे "THIS IS A POSTCARD" लिखना—जो कोई भी इसे रोकेगा, वह इसे पढ़ सकता है।

द पेलोड (The Payload - "क्लेम्स" डिपार्टमेंट)

दूसरा भाग पेलोड है। यह है काम की चीज़। यह एक और JSON ऑब्जेक्ट है जिसमें "क्लेम्स" (claims) होते हैं, जो उपयोगकर्ता ("सब्जेक्ट") और अन्य उपयोगी डेटा के बारे में कथन हैं।

{
  "sub": "10987-23456-98765",
  "name": "Grace Hopper",
  "admin": true,
  "iat": 1516239022,
  "exp": 1516242622
}

Claims तीन तरह के होते हैं:

  • रजिस्टर्ड क्लेम्स (Registered Claims): ये इंटरऑपरेबिलिटी प्रदान करने के लिए पूर्वनिर्धारित, अनुशंसित क्लेम्स का एक सेट हैं। वे अनिवार्य नहीं हैं, लेकिन वे बहुत उपयोगी हैं।
क्लेम नाम विवरण
iss Issuer टोकन किसने जारी किया (जैसे, https://api.mycoolsite.com)।
sub Subject वह उपयोगकर्ता या इकाई जिसके बारे में टोकन है (जैसे, एक यूजर आईडी)।
aud Audience टोकन किसके लिए है (जैसे, https://api.mycoolsite.com)।
exp Expiration Time टोकन कब समाप्त होता है। एक न्यूमेरिक यूनिक्स टाइमस्टैम्प (epoch के बाद से सेकंड)।
iat Issued At टोकन कब जारी किया गया था। यह भी एक यूनिक्स टाइमस्टैम्प है।
  • पब्लिक क्लेम्स (Public Claims): ये आपके द्वारा बनाए गए कस्टम क्लेम्स हैं, लेकिन नामों के टकराव (naming collisions) से बचने के लिए, उन्हें IANA JSON वेब टोकन क्लेम्स रजिस्ट्री में परिभाषित किया जाना चाहिए या एक URI होना चाहिए जिसमें टकराव-प्रतिरोधी नेमस्पेस हो।
  • प्राइवेट क्लेम्स (Private Claims): ये सबसे आम कस्टम क्लेम्स हैं, जो उन पार्टियों के बीच जानकारी साझा करने के लिए बनाए गए हैं जो उनका उपयोग करने पर सहमत हैं (जैसे हमारे उदाहरण में admin: true)। यहीं पर आप अपना एप्लिकेशन-विशिष्ट डेटा डालते हैं।

हेडर की तरह, पूरे पेलोड JSON को Base64Url एन्कोड किया जाता है ताकि JWT का दूसरा भाग बन सके। फिर से, यह एन्क्रिप्टेड नहीं है। पेलोड में कभी भी पासवर्ड जैसी संवेदनशील जानकारी न डालें।

द सिग्नेचर (The Signature - छेड़छाड़-रोधी सील)

यह वह हिस्सा है जो सुरक्षा प्रदान करता है। सिग्नेचर का उपयोग यह वेरिफाई करने के लिए किया जाता है कि JWT का प्रेषक वही है जो वह कहता है और यह सुनिश्चित करने के लिए कि संदेश को रास्ते में बदला नहीं गया था।

यह एन्कोडेड हेडर, एन्कोडेड पेलोड, एक सीक्रेट कुंजी लेकर और उन्हें हेडर में निर्दिष्ट एल्गोरिथ्म के माध्यम से चलाकर बनाया जाता है। हमारे HS256 उदाहरण के लिए, प्रक्रिया कुछ इस तरह दिखती है:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your-256-bit-secret
)

पंचलाइन यह है: एक secret का उपयोग किया जाता है जिसे केवल सर्वर जानता है। जब सर्वर को एक JWT मिलता है, तो वह उसे मिले हेडर और पेलोड के साथ ठीक यही गणना फिर से करता है। यदि उसके द्वारा उत्पन्न सिग्नेचर टोकन पर मौजूद सिग्नेचर से मेल खाता है, तो सर्वर दो बातें जानता है:

  1. प्रामाणिकता (Authenticity): टोकन किसी ऐसे व्यक्ति द्वारा बनाया गया था जो सीक्रेट कुंजी जानता है (यानी, सर्वर स्वयं)।
  2. अखंडता (Integrity): हेडर और पेलोड के साथ छेड़छाड़ नहीं की गई है। यदि कोई हमलावर पेलोड में "admin": false को "admin": true" में बदल देता, तो सिग्नेचर अब मेल नहीं खाता।

यह सिग्नेचर हमारे पासपोर्ट पर टैम्पर-प्रूफ होलोग्राफिक सील की तरह है।

असल दुनिया की कहानियाँ

माइक्रोसर्विसेज की भूलभुलैया

एक तेजी से बढ़ती ई-कॉमर्स कंपनी, "ScaleFast," ने अपने विशाल, मोनोलिथिक बैकएंड को माइक्रोसर्विसेज के एक बेड़े में तोड़ने का फैसला किया: एक यूजर्स के लिए, एक ऑर्डर्स के लिए, एक इन्वेंट्री के लिए, आदि। पुरानी प्रणाली एक सर्वर-साइड सेशन का उपयोग करती थी। लेकिन नई दुनिया में, OrderService को कैसे पता चलेगा कि एक रिक्वेस्ट वास्तव में एक लॉग-इन उपयोगकर्ता से आया है, बिना हर एक रिक्वेस्ट पर UserService को कॉल किए? यह धीमा होगा और डिकपलिंग के उद्देश्य को विफल कर देगा।

समाधान था JWT। जब कोई उपयोगकर्ता लॉग इन करता है, तो नया AuthService एक JWT जारी करता है जिसमें userId और उनके roles होते हैं। उपयोगकर्ता का ब्राउज़र फिर इस JWT को अन्य माइक्रोसर्विसेज के हर रिक्वेस्ट के Authorization हेडर में शामिल करता है। OrderService और InventoryService को AuthService से बात करने की आवश्यकता नहीं है; उन्हें बस साझा सीक्रेट कुंजी जानने की जरूरत है। वे स्वतंत्र रूप से JWT के सिग्नेचर को वेरिफाई कर सकते हैं, अंदर के userId पर भरोसा कर सकते हैं, और रिक्वेस्ट को प्रोसेस कर सकते हैं।

सबक: JWTs माइक्रोसर्विस ऑथेंटिकेशन की lingua franca (यानी आम भाषा) हैं, जो सेवाओं को स्टेटलेस और स्वतंत्र रूप से वेरिफाई करने योग्य बनाती हैं।

सिंगल-पेज ऐप की गाथा

एलेक्स नाम का एक डेवलपर एक शानदार React डैशबोर्ड बना रहा था। फ्रंटएंड एक सिंगल-पेज एप्लिकेशन (SPA) था जो एक स्टैटिक होस्ट से सर्व किया जाता था, और यह एक अलग बैकएंड API से बात करता था। एलेक्स पुराने ज़माने के कुकी-आधारित ऑथेंटिकेशन से जूझ रहा था, और क्रॉस-ऑरिजिन रिसोर्स शेयरिंग (CORS) की समस्याओं के बुरे सपने में फंस गया था क्योंकि फ्रंटएंड और बैकएंड अलग-अलग डोमेन पर थे।

टीम ने JWT पर स्विच किया। अब, जब कोई उपयोगकर्ता अपने यूजरनेम और पासवर्ड से लॉग इन करता है, तो API एक JWT वापस भेजता है। एलेक्स का React ऐप इस टोकन को मेमोरी में स्टोर करता है और इसे हर API कॉल के साथ अटैच करता है: Authorization: Bearer <the-jwt>। API बैकएंड स्टेटलेस है; यह बस हर आने वाले रिक्वेस्ट पर बियरर टोकन की जांच करता है। अब CORS कुकी वाले सिरदर्द से छुटकारा।

सबक: JWTs एक स्वच्छ, पोर्टेबल क्रेडेंशियल प्रदान करते हैं जो आधुनिक फ्रंटएंड एप्लिकेशन को बैकएंड APIs से अलग करने के लिए खूबसूरती से काम करता है।

आम गलतियाँ और जाल

  • पेलोड में संवेदनशील डेटा डालना। रुकिए! पेलोड Base64Url एन्कोडेड होता है, जो मामूली रूप से रिवर्सिबल है। यह एन्क्रिप्टेड नहीं है। कोई भी जिसे टोकन मिलता है, वह पेलोड पढ़ सकता है। इसे एक पोस्टकार्ड की तरह समझें, सीलबंद चिट्ठी की तरह नहीं।
  • सिग्नेचर को वेरिफाई करना भूल जाना। पासपोर्ट की सुरक्षा सुविधाओं का क्या मतलब है अगर बॉर्डर एजेंट उनकी जाँच ही न करे? सिर्फ पेलोड को डीकोड करना और सिग्नेचर को वेरिफाई किए बिना उसकी सामग्री पर भरोसा करना एक बहुत बड़ी सुरक्षा चूक (catastrophic security vulnerability) है। एक हमलावर अपनी पसंद का कोई भी पेलोड बना सकता है।
  • alg हेडर पर आँख बंद करके भरोसा करना। एक प्रसिद्ध पिछली वल्नेरेबिलिटी में हमलावरों द्वारा एक टोकन बनाना और हेडर को {"alg": "none"} में बदलना शामिल था। कुछ गलत कॉन्फ़िगर की गई लाइब्रेरी "none" देखतीं और सिग्नेचर को "वेरिफाई" करतीं, खैर, कुछ भी न करके, और जाली टोकन को वैध मान लेतीं। हमेशा अपने सर्वर को एक विशिष्ट, अपेक्षित एल्गोरिथ्म (जैसे, HS256) लागू करने के लिए सेट करें।
  • अपनी सिमेट्रिक सीक्रेट कुंजी लीक करना। HS256 जैसे HMAC एल्गोरिदम के लिए, सीक्रेट कुंजी सल्तनत की चाबियाँ हैं। यदि यह लीक हो जाती है, तो कोई भी किसी भी उपयोगकर्ता के लिए किसी भी अनुमति के साथ टोकन बना सकता है। इसे एक पासवर्ड की तरह सुरक्षित रखें।
  • एक्सपायरेशन (exp) क्लेम सेट न करना। एक टोकन जो हमेशा के लिए रहता है, एक बहुत बड़ी देनदारी (liability) है। यदि यह कभी कॉम्प्रोमाइज हो जाता है, तो एक हमलावर इसे अनिश्चित काल तक उपयोग कर सकता है। हमेशा एक यथोचित रूप से छोटी समाप्ति अवधि निर्धारित करें और लंबी अवधि के सेशन के लिए एक रिफ्रेश टोकन मैकेनिज्म का उपयोग करें।

यह आपके राडार पर क्यों होना चाहिए

जब भी आप एक डिस्ट्रिब्यूटेड एनवायरनमेंट में ऑथेंटिकेशन या ऑथराइजेशन से निपट रहे हों, तो आपको "JWT" के बारे में सोचना चाहिए।

  • आप एक सिंगल-पेज ऐप (SPA) या मोबाइल क्लाइंट के लिए एक API बना रहे हैं।
  • आप एक माइक्रोसर्विस आर्किटेक्चर डिजाइन कर रहे हैं जहां सेवाओं को एक-दूसरे से आने वाले रिक्वेस्ट पर भरोसा करने की आवश्यकता है।
  • आपको स्टेटलेस ऑथेंटिकेशन की आवश्यकता है जो बिना साझा सेशन स्टोर के हॉरिजॉन्टली स्केल हो सके।
  • आप वन-टाइम-यूज़ ऑथराइजेशन फ्लो लागू कर रहे हैं, जैसे पासवर्ड रीसेट लिंक या ईमेल वेरिफ़िकेशन, जहाँ एक सेल्फ-कन्टेन्ड, एक्सपायरेबल टोकन एक आदर्श फिट है।

यह क्लेम्स को सुरक्षित रूप से दर्शाने का आधुनिक मानक है, और इसकी ताकतों—और कमजोरियों—को समझना आज के डेवलपर के लिए अनिवार्य है।

और गहराई में जाएं

  • RFC 7519: JSON वेब टोकन (JWT) के लिए आधिकारिक स्पेसिफिकेशन। यही सत्य का स्रोत है।
  • jwt.io: एक शानदार रिसोर्स जिसमें एक लाइव डीबगर और लगभग हर भाषा के लिए लाइब्रेरी की सूची है।
  • OWASP JWT Cheat Sheet: JWTs का उपयोग करने की सुरक्षा सर्वोत्तम प्रथाओं और नुकसानों के लिए एक आवश्यक गाइड (यह सलाह भाषा-अज्ञेयवादी है)।
  • MDN Web Docs: Authorization header: Bearer ऑथेंटिकेशन स्कीम के बारे में जानें जो आमतौर पर JWTs को प्रसारित करने के लिए उपयोग की जाती है।
  • Wikipedia: JSON Web Token: कॉन्सेप्ट और उसके इतिहास का एक अच्छा हाई-लेवल ओवरव्यू।

थ्योरी हो गई। अब हाथ आज़माइए — 100% आपके ब्राउज़र में।

टूल आज़माएँ: JWT व्यूअर