17 अक्टू॰ 2025·7 मिनट
JWT क्या है? JSON Web Tokens के लिए एक स्पष्ट गाइड
जानें JWT (JSON Web Token) क्या है, इसके तीन हिस्से कैसे काम करते हैं, यह कहाँ उपयोग होता है, और सामान्य टोकन गलतियों से बचने के प्रमुख सुरक्षा सुझाव।
जानें JWT (JSON Web Token) क्या है, इसके तीन हिस्से कैसे काम करते हैं, यह कहाँ उपयोग होता है, और सामान्य टोकन गलतियों से बचने के प्रमुख सुरक्षा सुझाव।
एक JWT (JSON Web Token) एक कॉम्पैक्ट, URL-सुरक्षित स्ट्रिंग है जो एक सेट सूचना (अक्सर उपयोगकर्ता या सत्र के बारे में) को ऐसे तरीके से दर्शाती है जिसे सिस्टम्स के बीच पास किया जा सकता है। आप इसे अक्सर eyJ... जैसी किसी लंबी वैल्यू के रूप में देखेंगे, जो HTTP हेडर में भेजी जाती है, जैसे Authorization: Bearer <token>.
पारंपरिक लॉगिन अक्सर सर्वर सत्रों पर निर्भर होते हैं: साइन-इन के बाद सर्वर सत्र डेटा स्टोर करता है और ब्राउज़र को एक सत्र ID कूकी देता है। हर अनुरोध उस कूकी के साथ आता है, और सर्वर सत्र देखता है।
टोकन-आधारित ऑथ में सर्वर हर उपयोगकर्ता अनुरोध के लिए सत्र स्टेट रखने से बच सकता है। इसके बजाय, क्लाइंट एक टोकन (जैसे JWT) रखता है और इसे API कॉल्स में शामिल करता है। यह APIs में लोकप्रिय है क्योंकि:
महत्वपूर्ण सूक्ष्मता: “स्टेटलेस” का मतलब यह नहीं कि कभी सर्वर-साइड जाँच नहीं होती। कई वास्तविक सिस्टम अभी भी उपयोगकर्ता की स्थिति, कुंजी रोटेशन, या रिवोकेशन मैकेनिज्म के खिलाफ टोकन को मान्य करते हैं।
JWT अक्सर प्रमाणीकरण का प्रमाण (आप साइन इन हैं) और बुनियादी प्राधिकरण संकेत (रोल्स, परमिशन्स, स्कोप्स) दोनों को ढोते हैं—पर आपके सर्वर को फिर भी प्राधिकरण नियम लागू करना चाहिए।
आप आमतौर पर JWTs को एक्सेस टोकन के रूप में इन जगहों पर देखेंगे:
एक JWT एक कॉम्पैक्ट स्ट्रिंग है जो तीन भागों से बनी होती है, प्रत्येक base64url-एन्कोडेड और डॉट से अलग:
header.payload.signature
उदाहरण (रेडेटैक्टेड):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNzAwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c…
हैडर बताता है कि टोकन कैसे बनाया गया—सबसे महत्वपूर्ण है साइनिंग एल्गोरिद्म (उदाहरण: HS256, RS256/ES256) और टोकन प्रकार।
आम फ़ील्ड्स:
typ: अक्सर "JWT" (अमल में अक्सर अनदेखा किया जाता है)alg: प्रयुक्त साइनिंग एल्गोरिद्मkid: की-आइडेंटिफायर जो सत्यापनकर्ता को रोटेशन के दौरान सही कुंजी चुनने में मदद करता हैसुरक्षा नोट: हैडर पर अंधविश्वास न करें। उन एल्गोरिद्म की allowlist लागू करें जो आप वास्तव में उपयोग करते हैं, और alg: "none" स्वीकार न करें।
पेलोड में “क्लेम्स” (फ़ील्ड्स) होते हैं जो उपयोगकर्ता और टोकन संदर्भ के बारे में बताते हैं: किसके लिए है, किसने जारी किया, और कब यह समाप्त होता है।
महत्वपूर्ण: JWTs डिफ़ॉल्ट रूप से एन्क्रिप्ट नहीं होते। Base64url एन्कोडिंग टोकन को URL-सुरक्षित बनाती है; यह डेटा छुपाती नहीं है। जो कोई भी टोकन प्राप्त करे, हेडर और पेलोड डिकोड कर पढ़ सकता है।
इसलिए संवेदनशील जानकारी (पासवर्ड्स, API कुंजियाँ) JWT में न रखें।
सिग्नेचर हैडर + पेलोड को एक कुंजी से साइन करके बनाया जाता है:
सिग्नेचर इंटीग्रिटी प्रदान करता है: सर्वर यह सत्यापित कर सकता है कि टोकन संशोधित नहीं हुआ और भरोसेमंद सिग्नर ने ही इसे जारी किया। यह गोपनीयता नहीं देता।
क्योंकि JWT में हैडर और पेलोड हर अनुरोध में शामिल होते हैं जहाँ यह भेजा जाता है, बड़े टोकन का मतलब अधिक बैंडविड्थ और ओवरहेड है। क्लेम्स को संकुचित रखें और घूमम-फ़ालतू डेटा की बजाय पहचानकर्ता उपयोग करें।
क्लेम्स सामान्यतः दो बकेट्स में आते हैं: registered (मानकीकृत नाम) और custom (आपके ऐप के फ़ील्ड)।
iss (issuer): किसने टोकन बनायाsub (subject): टोकन किसके बारे में है (अक्सर उपयोगकर्ता ID)aud (audience): टोकन किसके लिए है (उदा. कोई विशिष्ट API)exp (expiration time): कब टोकन स्वीकार करना बंद कर देना चाहिएiat (issued at): कब टोकन बनाया गयाnbf (not before): टोकन कब से स्वीकार करना चाहिएकेवल वही शामिल करें जिसकी प्राप्त करने वाली सेवा को वास्तव में आवश्यकता है ताकि वह प्राधिकरण निर्णय ले सके।
अच्छे उदाहरण:
user_id)उन “सुविधा” वाले क्लेम्स से बचें जो बहुत सारा प्रोफ़ाइल डेटा डुप्लिकेट करते हैं—वे टोकन को बढ़ाते हैं, जल्दी पुराने हो जाते हैं, और लीक होने पर प्रभाव बढ़ाते हैं।
क्योंकि पेलोड पठनीय है, न रखें:
यदि आपको संवेदनशील जानकारी चाहिए, तो उसे सर्वर-साइड स्टोर करें और टोकन में केवल एक संदर्भ (जैसे ID) डालें—या जहाँ उपयुक्त हो एन्क्रिप्टेड टोकन फॉर्मेट (JWE) का उपयोग करें।
साइनिंग एन्क्रिप्शन नहीं है।
जब JWT जारी होता है, सर्वर हेडर + पेलोड को साइन करता है। जब टोकन बाद में पेश किया जाता है, सर्वर सिग्नेचर फिर से गणना करके तुलना करता है। अगर कोई भी कैरेक्टर बदला (उदा. "role":"user" से "role":"admin") तो सत्यापन विफल होगा और टोकन अस्वीकार कर दिया जाएगा।
JWT एक टोकन फॉर्मेट है। OAuth 2.0 और OpenID Connect (OIDC) ऐसे प्रोटोकॉल हैं जो बतलाते हैं कि ऐप्स टोकन कैसे अनुरोध, जारी और उपयोग करें।
OAuth 2.0 मुख्य रूप से प्राधिकरण के बारे में है: किसी ऐप को उपयोगकर्ता की ओर से API एक्सेस करने देना बिना उपयोगकर्ता का पासवर्ड साझा किए।
Access tokens आमतौर पर शॉर्ट-लाइव्ड होते हैं (मिनटों में)। छोटी अवधि टोकन लीक होने पर नुकसान सीमित करते हैं।
OIDC, OAuth 2.0 पर प्रमाणीकरण जोड़ता है और एक ID token लाता है, जो आमतौर पर JWT होता है।
एक मुख्य नियम: ID token का उपयोग API कॉल के लिए न करें।
यदि आप व्यावहारिक फ्लोज़ पर अधिक जानकारी चाहते हैं, देखें /blog/jwt-authentication-flow।
एक सामान्य फ्लो इस प्रकार होता है:
उपयोगकर्ता साइन इन करता है (ईमेल/पासवर्ड, SSO, आदि)। सफल होने पर सर्वर एक JWT बनाता है (अक्सर एक एक्सेस टोकन) जिसमें विषय और एक्सपायर करने का समय जैसे आवश्यक क्लेम्स होते हैं।
सर्वर टोकन को साइन करके क्लाइंट (वेब ऐप, मोबाइल ऐप, या दूसरी सर्विस) को लौटाता है।
सुरक्षित एंडपॉइंट्स के लिए, क्लाइंट JWT को Authorization हेडर में शामिल करता है:
Authorization: Bearer <JWT>
अनुरोध परोसने से पहले, API आम तौर पर चेक करता है:
exp (समाप्ति)iss (अपेक्षित जारीकर्ता)aud (यह API लक्षित है)यदि सभी जाँच पास होती हैं, API उपयोगकर्ता को authenticated मानता है और प्राधिकरण नियम लागू करता है (उदा. रिकॉर्ड-स्तरीय परमिशन्स)।
क्योंकि सिस्टम क्लॉक्स भिन्न हो सकते हैं, कई सिस्टम समय-आधारित क्लेम्स (exp, कभी-कभी nbf) के सत्यापन में थोड़ा क्लॉक स्क्यू की अनुमति देते हैं। स्क्यू छोटा रखें ताकि टोकन वैधता अनावश्यक रूप से न बढ़े।
स्टोरेज विकल्प यह निर्धारित करते हैं कि कौन-सा अटैकर क्या चुरा सकता है और कितनी आसानी से वे टोकन को रीप्ले कर सकेंगे।
इन-मेमोरी स्टोरेज (SPAs के लिए अक्सर अनुशंसित) एक्सेस टोकन को JS स्टेट में रखता है। यह रीफ्रेश पर मिट जाता है और “बाद में पकड़ लो” चोरी को घटाता है, पर एक XSS बग सक्रिय होने पर JS के माध्यम से अभी भी पढ़ा जा सकता है। इसे छोटे-समय एक्सेस टोकन और रिफ्रेश फ्लो के साथ जोडें।
localStorage/sessionStorage आसान हैं पर जोखिम भरे: कोई भी XSS भेद्यता वेब स्टोरेज से टोकन निकाल सकती है। यदि आप इनका उपयोग कर रहे हैं, तो XSS रोकथाम अनिवार्य की तरह मानें (CSP, आउटपुट एस्केपिंग, डिपेंडेंसी हाइजीन) और टोकन को शॉर्ट-लाइव रखें।
Secure cookies (आमतौर पर वेब के लिए सबसे सुरक्षित डिफ़ॉल्ट) टोकन को HttpOnly कूकी में स्टोर करती हैं ताकि JavaScript उन्हें न पढ़ सके—इससे XSS के असर से बचाव होता है। व्यापार-off है CSRF जोखिम, क्योंकि ब्राउज़र कुकीज़ स्वतः जोड़ता है।
यदि आप कूकीज़ का उपयोग करते हैं, सेट करें:
HttpOnlySecure (केवल HTTPS)SameSite=Lax या SameSite=Strict (कुछ क्रॉस-साइट फ्लोज़ के लिए SameSite=None; Secure चाहिए हो सकता है)राज्य-परिवर्तन अनुरोधों के लिए CSRF टोकन्स पर भी विचार करें।
iOS/Android पर, टोकन प्लेटफ़ॉर्म के सुरक्षित स्टोरेज (Keychain / Keystore-backed storage) में रखें। साधारण फ़ाइलों या प्रेफरेंसेस से बचें। यदि आपका थ्रेट मॉडल रूटेड/जेलब्रोकन डिवाइस शामिल करता है, तो एक्स्ट्रैक्शन संभव मानें और छोटे-समय टोकन व सर्वर-साइड नियंत्रणों पर भरोसा करें।
टोकन की शक्तियाँ सीमित रखें: स्कोप्स/क्लेम्स कम रखें, एक्सेस टोकन शॉर्ट-लाइव रखें, और संवेदनशील डेटा एम्बेड करने से बचें।
JWT सुविधाजनक हैं, पर कई घटनाएँ अनुमानित गलती के कारण होती हैं। एक JWT को नकदी की तरह समझें: जिसने इसे प्राप्त कर लिया, अक्सर वह इसे खर्च कर सकता है।
यदि टोकन दिनों या हफ़्तों तक प्रभावी रहे, तो लीक होने पर हमलावर को पूरा विंडो मिल जाता है।
शॉर्ट-लाइव्ड एक्सेस टोकन (मिनटों) और सुरक्षित रिफ्रेश मैकेनिज्म पसंद करें। यदि “मुझे याद रखो” जरूरी है, तो उसे रिफ्रेश टोकन्स और सर्वर-साइड नियंत्रणों के साथ करें।
सिग्नेचर वैध होना काफी नहीं है। iss और aud सत्यापित करें, और समय-आधारित क्लेम्स जैसे exp और nbf की जाँच करें।
डिकोड करना सत्यापन नहीं है। हमेशा सर्वर पर सिग्नेचर सत्यापित करें और सर्वर-साइड पर परमिशन्स लागू करें।
JWTs को क्वेरी पैरामीटर्स में न रखें। वे ब्राउज़र इतिहास, सर्वर लॉग, एनालिटिक्स टूल्स, और रेफ़रर हेडर्स में पहुँच सकते हैं।
Authorization: Bearer ... का उपयोग करें।
मानें कि कुंजियाँ और टोकन लीक हो सकते हैं। साइनिंग कुंजियों को रोटेट करें, kid का उपयोग स्मूथ रोटेशन के लिए करें, और रिवोकेशन की रणनीति रखें (छोटे एक्सपायरेशन + खाते/सत्र अक्षम करने की क्षमता)। स्टोरेज मार्गदर्शन के लिए देखें /blog/where-to-store-jwts-safely।
JWT उपयोगी हैं, पर वे हर स्थिति में सर्वश्रेष्ठ विकल्प नहीं होते। असल सवाल यह है कि क्या आपको एक self-contained टोकन से लाभ होता है जिसे हर अनुरोध पर डेटाबेस लुकअप के बिना सत्यापित किया जा सके।
पारंपरिक सर्वर-रेंडर किए गए वेब ऐप्स के लिए जहाँ सुलभ इनवैलिडेशन मायने रखता है, सर्वर-साइड सत्र्स और HttpOnly कूकीज़ अक्सर सरल और सुरक्षित डिफ़ॉल्ट होते हैं।
यदि आपको सर्विसेज़ के बीच स्टेटलेस सत्यापन चाहिए और आप टोकन को शॉर्ट-लाइव रख सकते हैं तो JWT चुनें।
यदि आपको तत्काल रिवोकेशन चाहिए, टोकन में संवेदनशील डेटा रखने का इरादा है, या आप बिना झंझट के सत्र कूकीज़ का उपयोग कर सकते हैं तो JWT से बचें।
सही कुंजी और अपेक्षित एल्गोरिद्म का उपयोग कर सत्यापित करें। अस्वीकृत सिग्नेचरों को रोका जाए—कोई अपवाद नहीं।
exp (समाप्ति)सुनिश्चित करें कि टोकन समाप्त नहीं हुआ है।
nbf (नोट बिफोर)यदि मौजूद हो, तो सुनिश्चित करें कि टोकन बहुत जल्दी उपयोग नहीं हो रहा।
aud (ऑडियन्स)पुष्टि करें कि टोकन आपकी API/सर्विस के लिए था।
iss (इशूअर)पुष्टि करें कि टोकन अपेक्षित जारीकर्ता से आया था।
टोकन फ़ॉर्मेट वैलिडेट करें, अधिकतम आकार लागू करें, और अप्रत्याशित क्लेम प्रकार अस्वीकार करें ताकि एज-केस बग घटें।
HS256 (सिमेट्रिक की): एक साझा सीक्रेट साइन और वेरीफाई करता है.
RS256 / ES256 (असिमेट्रिक कुंजियाँ): प्राइवेट की साइन करती है; पब्लिक की वेरीफाई.
रूल ऑफ थम्ब: यदि कई स्वतंत्र सिस्टम्स को टोकन सत्यापित करना है (या आप हर वेरीफायर पर भरोसा नहीं करते), तो RS256/ES256 पसंद करें।
iss, aud, और नीति की अनुमति होने पर उपयोगकर्ता ID)।क्या JWT एन्क्रिप्टेड है?
डिफ़ॉल्ट रूप से नहीं। अधिकांश JWTs साइन होते हैं, एन्क्रिप्टेड नहीं। इसका अर्थ है कि सामग्री किसी भी टोकन धारक द्वारा पढ़ी जा सकती है। गोपनीयता के लिए JWE या संवेदनशील डेटा को JWT से बाहर रखें।
क्या मैं JWT रिवोक कर सकता/सकती हूँ?
यदि आप केवल self-contained access tokens पर निर्भर हैं तो नहीं आसानी से। आम दृष्टिकोण: शॉर्ट-लाइव्ड एक्सेस टोकन, हाई-रिस्क घटनाओं के लिए deny-lists, या रोटेटिंग refresh टोकन्स।
exp कितनी लंबी होनी चाहिए?
जितना आपकी UX और आर्किटेक्चर अनुमति देती है उतना छोटा रखें। कई APIs access tokens के लिए मिनटों का उपयोग करते हैं और लंबी सत्रों के लिए refresh tokens का उपयोग करते हैं।
यदि आप किसी नए API या SPA में JWT ऑथ इम्प्लीमेंट कर रहे हैं, तो कई काम दोहराव वाले होते हैं: मिडलवेयर वाइर करना, iss/aud/exp को वैलिडेट करना, कूकी फ्लैग सेट करना, और लॉग से टोकन हैंडलिंग को हटाना।
Koder.ai के साथ, आप एक वेब ऐप (React), बैकएंड सेवाएँ (Go + PostgreSQL), या Flutter मोबाइल ऐप को चैट-ड्रिवन वर्कफ़्लो के ज़रिये तेज़ी से कोड कर सकते हैं—फिर सुरक्षा, कुंजी रोटेशन रणनीति और डिप्लॉयमेंट सेटिंग्स को नियंत्रित रखते हुए इटेरेट कर सकते हैं।
A JWT (JSON Web Token) एक कॉम्पैक्ट, URL-सुरक्षित स्ट्रिंग है जो क्लेम्स (डेटा फ़ील्ड) को ढोती है और जिसे सर्वर सत्यापित कर सकता है। इसे सामान्यतः API अनुरोधों पर इस तरह भेजा जाता है:
Authorization: Bearer <token>मुख्य विचार: सर्वर टोकन की अखंडता (signature के माध्यम से) सत्यापित कर सकता है बिना हर उपयोगकर्ता के लिए सत्र रिकॉर्ड रखने के।
सत्र प्रमाणीकरण (session auth) आमतौर पर सर्वर पर स्टेट स्टोर करता है (कुकी/सेशन ID द्वारा संदर्भित)। JWT-आधारित प्रमाणीकरण में, क्लाइंट हर अनुरोध पर एक साइन किया हुआ टोकन प्रस्तुत करता है और API उसे सत्यापित करती है.
JWT APIs और बहु-सेवा आर्किटेक्चर में लोकप्रिय हैं क्योंकि सत्यापन लोकली होकर साझा सेशन स्टोरेज की आवश्यकता घट जाती है।
“स्टेटलेस” होने का यह मतलब नहीं कि सर्वर-साइड जाँचें पूरी तरह बंद हों—कई सिस्टम अभी भी रिवोकेशन लिस्ट, उपयोगकर्ता स्थिति चेक या कुंजी रोटेशन जैसी जाँच करते हैं।
एक JWT तीन Base64URL-एन्कोडेड भागों से बना होता है, जो डॉट द्वारा अलग होते हैं:
header.payload.signatureहैडर बताता है कैसे साइन किया गया था, पेलोड में क्लेम्स (जैसे sub, exp, aud) होते हैं, और सिग्नेचर छेड़छाड़ का पता लगाने के लिए होता है।
नहीं। सामान्य JWTs आमतौर पर साइन किए जाते हैं, एन्क्रिप्ट नहीं।
यदि गोपनीयता चाहिए तो JWE (एन्क्रिप्टेड टोकन) का उपयोग करें या संवेदनशील डेटा सर्वर-साइड रखें और JWT में केवल संदर्भ रखें।
सिग्नेचर सर्वर को बताता है कि टोकन बदला गया है या नहीं और किसने जारी किया।
यह साबित नहीं करता कि:
exp से पहले रिवोक हो गया होटोकन को एक क्रेडेंशियल की तरह समझें: यदि यह लीक हो जाए तो एक्सपायर होने तक अक्सर इसका दुर्विनियोग हो सकता है।
alg बताता है किस एल्गोरिद्म से साइन हुआ (जैसे HS256 बनाम RS256)। kid एक की-आइडेंटिफायर है जो कुंजी रोटेशन के दौरान सही सत्यापन कुंजी चुनने में मदद करता है।
सुरक्षा के तौर पर:
मानक क्लेम्स से शुरू करें और कस्टम क्लेम्स को न्यूनतम रखें।
आम रजिस्टर्ड क्लेम्स:
JWT एक टोकन फॉर्मेट है; OAuth 2.0 और OpenID Connect (OIDC) प्रोटोकॉल हैं।
सामान्य मैपिंग:
ब्राउज़र-आधारित ऐप्स के लिए सामान्य विकल्प:
जो भी विकल्प चुनें, एक्सेस टोकन छोटे रखें और टोकन-विशेषाधिकारों को सीमित रखें।
कम से कम, सत्यापित करें:
exp (समाप्ति)nbf (यदि मौजूद हो)aud (आपकी API/सर्विस के लिए है)iss (अपेक्षित जारीकर्ता)व्यावहारिक सुरक्षा के लिए:
साधारणतः नहीं—यदि आप केवल self-contained access tokens पर भरोसा करते हैं तो रिवोकेशन कठिन है। आम समाधान:
सामान्य पैटर्न: छोटे एक्सेस टोकन + सुरक्षित refresh फ्लो।
आम तौर पर जितना आपकी UX और आर्किटेक्चर अनुमति दे उतना छोटा रखें। कई APIs एक्सेस टोकन के लिए मिनटों का उपयोग करते हैं और लंबे सत्रों के लिए refresh tokens का सहारा लेते हैं।
algalg: "none" कभी स्वीकार न करें।kid मान से असुरक्षित कुंजी-लुकअप न होने दें।iss (issuer)sub (subject / user identifier)aud (audience / intended API)exp (expiration)iat (issued at)nbf (not before)पेलोड में गुप्त या संवेदनशील व्यक्तिगत डेटा न रखें, क्योंकि टोकन एक्सपोज़ होने पर इसे पढ़ा जा सकता है।
महत्वपूर्ण: ID token को API कॉल के लिए उपयोग न करें केवल इसलिए कि यह JWT जैसा दिखता है।