JWT क्या है? JSON Web Tokens के लिए एक स्पष्ट गाइड

सरल भाषा में JWT

एक JWT (JSON Web Token) एक कॉम्पैक्ट, URL-सुरक्षित स्ट्रिंग है जो एक सेट सूचना (अक्सर उपयोगकर्ता या सत्र के बारे में) को ऐसे तरीके से दर्शाती है जिसे सिस्टम्स के बीच पास किया जा सकता है। आप इसे अक्सर eyJ... जैसी किसी लंबी वैल्यू के रूप में देखेंगे, जो HTTP हेडर में भेजी जाती है, जैसे Authorization: Bearer <token>.

टोकन का उपयोग क्यों करें?

पारंपरिक लॉगिन अक्सर सर्वर सत्रों पर निर्भर होते हैं: साइन-इन के बाद सर्वर सत्र डेटा स्टोर करता है और ब्राउज़र को एक सत्र ID कूकी देता है। हर अनुरोध उस कूकी के साथ आता है, और सर्वर सत्र देखता है।

टोकन-आधारित ऑथ में सर्वर हर उपयोगकर्ता अनुरोध के लिए सत्र स्टेट रखने से बच सकता है। इसके बजाय, क्लाइंट एक टोकन (जैसे JWT) रखता है और इसे API कॉल्स में शामिल करता है। यह APIs में लोकप्रिय है क्योंकि:

• यह कई सेवाओं (API गेटवे, माइक्रोसर्विसेज) में अच्छी तरह काम करता है
• मोबाइल और single-page apps (SPAs) के लिए उपयुक्त है जो सीधे API कॉल करते हैं
• सर्वरों के बीच साझा सत्र स्टोरेज की ज़रूरत घट जाती है

महत्वपूर्ण सूक्ष्मता: “स्टेटलेस” का मतलब यह नहीं कि कभी सर्वर-साइड जाँच नहीं होती। कई वास्तविक सिस्टम अभी भी उपयोगकर्ता की स्थिति, कुंजी रोटेशन, या रिवोकेशन मैकेनिज्म के खिलाफ टोकन को मान्य करते हैं।

प्रमाणीकरण बनाम प्राधिकरण (साधारण शब्दों में)

• प्रमाणीकरण (Authentication) पूछता है: आप कौन हैं? (आप साइन इन करते हैं और अपनी पहचान साबित करते हैं।)
• प्राधिकरण (Authorization) पूछता है: आप क्या कर सकते हैं? (आप इनवॉइस पढ़ सकते हैं, प्रोजेक्ट्स संपादित कर सकते हैं, एडमिन पेज एक्सेस कर सकते हैं, इत्यादि.)

JWT अक्सर प्रमाणीकरण का प्रमाण (आप साइन इन हैं) और बुनियादी प्राधिकरण संकेत (रोल्स, परमिशन्स, स्कोप्स) दोनों को ढोते हैं—पर आपके सर्वर को फिर भी प्राधिकरण नियम लागू करना चाहिए।

JWT किसमें दिखते हैं

आप आमतौर पर JWTs को एक्सेस टोकन के रूप में इन जगहों पर देखेंगे:

• वेब APIs
• SPAs
• मोबाइल ऐप्स
• OAuth 2.0 या OpenID Connect (OIDC) का उपयोग करने वाले सिस्टम

JWT संरचना: हैडर, पेलोड और सिग्नेचर

एक JWT एक कॉम्पैक्ट स्ट्रिंग है जो तीन भागों से बनी होती है, प्रत्येक base64url-एन्कोडेड और डॉट से अलग:

header.payload.signature

उदाहरण (रेडेटैक्टेड):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNzAwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c…

1) हैडर

हैडर बताता है कि टोकन कैसे बनाया गया—सबसे महत्वपूर्ण है साइनिंग एल्गोरिद्म (उदाहरण: HS256, RS256/ES256) और टोकन प्रकार।

आम फ़ील्ड्स:

• typ: अक्सर "JWT" (अमल में अक्सर अनदेखा किया जाता है)
• alg: प्रयुक्त साइनिंग एल्गोरिद्म
• kid: की-आइडेंटिफायर जो सत्यापनकर्ता को रोटेशन के दौरान सही कुंजी चुनने में मदद करता है

सुरक्षा नोट: हैडर पर अंधविश्वास न करें। उन एल्गोरिद्म की allowlist लागू करें जो आप वास्तव में उपयोग करते हैं, और alg: "none" स्वीकार न करें।

2) पेलोड

पेलोड में “क्लेम्स” (फ़ील्ड्स) होते हैं जो उपयोगकर्ता और टोकन संदर्भ के बारे में बताते हैं: किसके लिए है, किसने जारी किया, और कब यह समाप्त होता है।

महत्वपूर्ण: JWTs डिफ़ॉल्ट रूप से एन्क्रिप्ट नहीं होते। Base64url एन्कोडिंग टोकन को URL-सुरक्षित बनाती है; यह डेटा छुपाती नहीं है। जो कोई भी टोकन प्राप्त करे, हेडर और पेलोड डिकोड कर पढ़ सकता है।

इसलिए संवेदनशील जानकारी (पासवर्ड्स, API कुंजियाँ) JWT में न रखें।

3) सिग्नेचर

सिग्नेचर हैडर + पेलोड को एक कुंजी से साइन करके बनाया जाता है:

• HS256: एक साझा सिक्रेट साइन और वेरीफाई करता है
• RS256/ES256: प्राइवेट की साइन करती है; पब्लिक की वेरीफाई

सिग्नेचर इंटीग्रिटी प्रदान करता है: सर्वर यह सत्यापित कर सकता है कि टोकन संशोधित नहीं हुआ और भरोसेमंद सिग्नर ने ही इसे जारी किया। यह गोपनीयता नहीं देता।

साइज विचार

क्योंकि JWT में हैडर और पेलोड हर अनुरोध में शामिल होते हैं जहाँ यह भेजा जाता है, बड़े टोकन का मतलब अधिक बैंडविड्थ और ओवरहेड है। क्लेम्स को संकुचित रखें और घूमम-फ़ालतू डेटा की बजाय पहचानकर्ता उपयोग करें।

पेलोड और क्लेम्स: आप क्या रख सकते/नहीं रख सकते

क्लेम्स सामान्यतः दो बकेट्स में आते हैं: registered (मानकीकृत नाम) और custom (आपके ऐप के फ़ील्ड)।

सामान्य registered क्लेम्स

• iss (issuer): किसने टोकन बनाया
• sub (subject): टोकन किसके बारे में है (अक्सर उपयोगकर्ता ID)
• aud (audience): टोकन किसके लिए है (उदा. कोई विशिष्ट API)
• exp (expiration time): कब टोकन स्वीकार करना बंद कर देना चाहिए
• iat (issued at): कब टोकन बनाया गया
• nbf (not before): टोकन कब से स्वीकार करना चाहिए

कस्टम क्लेम्स: इन्हें न्यूनतम रखें

केवल वही शामिल करें जिसकी प्राप्त करने वाली सेवा को वास्तव में आवश्यकता है ताकि वह प्राधिकरण निर्णय ले सके।

अच्छे उदाहरण:

• एक स्थिर आंतरिक उपयोगकर्ता पहचानकर्ता (user_id)
• रोल्स/परमिशन्स का छोटा सेट (जब तक आप उन्हें अपडेट कर पाते हों)
• मल्टी-टेनेंट ऐप्स में टेनेंट/ऑर्गनाइज़ेशन ID

उन “सुविधा” वाले क्लेम्स से बचें जो बहुत सारा प्रोफ़ाइल डेटा डुप्लिकेट करते हैं—वे टोकन को बढ़ाते हैं, जल्दी पुराने हो जाते हैं, और लीक होने पर प्रभाव बढ़ाते हैं।

JWT पेलोड में कभी क्या न रखें

क्योंकि पेलोड पठनीय है, न रखें:

• पासवर्ड्स, API कीज़, रिफ्रेश टोकन या कोई भी सीक्रेट वैल्यू
• पेमेंट विवरण, सरकारी IDs, या संवेदनशील व्यक्तिगत डेटा
• कुछ भी जो आप ब्राउज़र, प्रॉक्सी, या लॉग से कॉपी नहीं करवाना चाहेंगे

यदि आपको संवेदनशील जानकारी चाहिए, तो उसे सर्वर-साइड स्टोर करें और टोकन में केवल एक संदर्भ (जैसे ID) डालें—या जहाँ उपयुक्त हो एन्क्रिप्टेड टोकन फॉर्मेट (JWE) का उपयोग करें।

सिग्नेचर कैसे काम करता है (और क्या गारंटी देता है)

साइनिंग एन्क्रिप्शन नहीं है।

• साइनिंग एक पत्र को सील करने जैसा है: लोग उसे पढ़ सकते हैं, पर वे देख सकते हैं कि उसे बदला गया है या नहीं।
• एन्क्रिप्शन पत्र को लॉक करने जैसा है: सिर्फ कुंजी रखने वाला उसे पढ़ सकता है।

जब JWT जारी होता है, सर्वर हेडर + पेलोड को साइन करता है। जब टोकन बाद में पेश किया जाता है, सर्वर सिग्नेचर फिर से गणना करके तुलना करता है। अगर कोई भी कैरेक्टर बदला (उदा. "role":"user" से "role":"admin") तो सत्यापन विफल होगा और टोकन अस्वीकार कर दिया जाएगा।

JWT बनाम OAuth, OpenID Connect, और टोकन प्रकार

JWT एक टोकन फॉर्मेट है। OAuth 2.0 और OpenID Connect (OIDC) ऐसे प्रोटोकॉल हैं जो बतलाते हैं कि ऐप्स टोकन कैसे अनुरोध, जारी और उपयोग करें।

OAuth 2.0 और access/refresh टोकन

OAuth 2.0 मुख्य रूप से प्राधिकरण के बारे में है: किसी ऐप को उपयोगकर्ता की ओर से API एक्सेस करने देना बिना उपयोगकर्ता का पासवर्ड साझा किए।

• Access token: API को प्रस्तुत किया जाता है; यह JWT या opaque हो सकता है
• Refresh token: नए एक्सेस टोकन पाने के लिए लंबे समय तक जीवित टोकन

Access tokens आमतौर पर शॉर्ट-लाइव्ड होते हैं (मिनटों में)। छोटी अवधि टोकन लीक होने पर नुकसान सीमित करते हैं।

OpenID Connect (OIDC) और ID टोकन

OIDC, OAuth 2.0 पर प्रमाणीकरण जोड़ता है और एक ID token लाता है, जो आमतौर पर JWT होता है।

• ID token: क्लाइंट ऐप के लिए उपयोगकर्ता की पहचान पुष्टि करने हेतु
• Access token: API को अनुरोध अधिकृत करने हेतु

एक मुख्य नियम: ID token का उपयोग API कॉल के लिए न करें।

यदि आप व्यावहारिक फ्लोज़ पर अधिक जानकारी चाहते हैं, देखें /blog/jwt-authentication-flow।

सामान्य JWT प्रमाणीकरण फ्लो

एक सामान्य फ्लो इस प्रकार होता है:

1) लॉगिन

उपयोगकर्ता साइन इन करता है (ईमेल/पासवर्ड, SSO, आदि)। सफल होने पर सर्वर एक JWT बनाता है (अक्सर एक एक्सेस टोकन) जिसमें विषय और एक्सपायर करने का समय जैसे आवश्यक क्लेम्स होते हैं।

2) टोकन निर्गमन

सर्वर टोकन को साइन करके क्लाइंट (वेब ऐप, मोबाइल ऐप, या दूसरी सर्विस) को लौटाता है।

3) API कॉल्स

सुरक्षित एंडपॉइंट्स के लिए, क्लाइंट JWT को Authorization हेडर में शामिल करता है:

Authorization: Bearer <JWT>

4) सत्यापन

अनुरोध परोसने से पहले, API आम तौर पर चेक करता है:

• सिग्नेचर (अखंडता + भरोसेमंद जारीकर्ता)
• exp (समाप्ति)
• iss (अपेक्षित जारीकर्ता)
• aud (यह API लक्षित है)

यदि सभी जाँच पास होती हैं, API उपयोगकर्ता को authenticated मानता है और प्राधिकरण नियम लागू करता है (उदा. रिकॉर्ड-स्तरीय परमिशन्स)।

5) क्लॉक स्क्यू पर एक त्वरित नोट

क्योंकि सिस्टम क्लॉक्स भिन्न हो सकते हैं, कई सिस्टम समय-आधारित क्लेम्स (exp, कभी-कभी nbf) के सत्यापन में थोड़ा क्लॉक स्क्यू की अनुमति देते हैं। स्क्यू छोटा रखें ताकि टोकन वैधता अनावश्यक रूप से न बढ़े।

JWTs को सुरक्षित रूप से कहाँ स्टोर करें

स्टोरेज विकल्प यह निर्धारित करते हैं कि कौन-सा अटैकर क्या चुरा सकता है और कितनी आसानी से वे टोकन को रीप्ले कर सकेंगे।

ब्राउज़र ऐप्स: मेमोरी बनाम localStorage बनाम कूकीज़

इन-मेमोरी स्टोरेज (SPAs के लिए अक्सर अनुशंसित) एक्सेस टोकन को JS स्टेट में रखता है। यह रीफ्रेश पर मिट जाता है और “बाद में पकड़ लो” चोरी को घटाता है, पर एक XSS बग सक्रिय होने पर JS के माध्यम से अभी भी पढ़ा जा सकता है। इसे छोटे-समय एक्सेस टोकन और रिफ्रेश फ्लो के साथ जोडें।

localStorage/sessionStorage आसान हैं पर जोखिम भरे: कोई भी XSS भेद्यता वेब स्टोरेज से टोकन निकाल सकती है। यदि आप इनका उपयोग कर रहे हैं, तो XSS रोकथाम अनिवार्य की तरह मानें (CSP, आउटपुट एस्केपिंग, डिपेंडेंसी हाइजीन) और टोकन को शॉर्ट-लाइव रखें।

Secure cookies (आमतौर पर वेब के लिए सबसे सुरक्षित डिफ़ॉल्ट) टोकन को HttpOnly कूकी में स्टोर करती हैं ताकि JavaScript उन्हें न पढ़ सके—इससे XSS के असर से बचाव होता है। व्यापार-off है CSRF जोखिम, क्योंकि ब्राउज़र कुकीज़ स्वतः जोड़ता है।

यदि आप कूकीज़ का उपयोग करते हैं, सेट करें:

• HttpOnly
• Secure (केवल HTTPS)
• SameSite=Lax या SameSite=Strict (कुछ क्रॉस-साइट फ्लोज़ के लिए SameSite=None; Secure चाहिए हो सकता है)

राज्य-परिवर्तन अनुरोधों के लिए CSRF टोकन्स पर भी विचार करें।

मोबाइल ऐप्स: OS सिक्योर स्टोरेज पसंद करें

iOS/Android पर, टोकन प्लेटफ़ॉर्म के सुरक्षित स्टोरेज (Keychain / Keystore-backed storage) में रखें। साधारण फ़ाइलों या प्रेफरेंसेस से बचें। यदि आपका थ्रेट मॉडल रूटेड/जेलब्रोकन डिवाइस शामिल करता है, तो एक्स्ट्रैक्शन संभव मानें और छोटे-समय टोकन व सर्वर-साइड नियंत्रणों पर भरोसा करें।

न्यूनतम विशेषाधिकार (Least privilege)

टोकन की शक्तियाँ सीमित रखें: स्कोप्स/क्लेम्स कम रखें, एक्सेस टोकन शॉर्ट-लाइव रखें, और संवेदनशील डेटा एम्बेड करने से बचें।

सामान्य JWT सुरक्षा गलतियाँ जिनसे बचें

JWT सुविधाजनक हैं, पर कई घटनाएँ अनुमानित गलती के कारण होती हैं। एक JWT को नकदी की तरह समझें: जिसने इसे प्राप्त कर लिया, अक्सर वह इसे खर्च कर सकता है।

1) अत्यधिक लंबा एक्सपायर समय

यदि टोकन दिनों या हफ़्तों तक प्रभावी रहे, तो लीक होने पर हमलावर को पूरा विंडो मिल जाता है।

शॉर्ट-लाइव्ड एक्सेस टोकन (मिनटों) और सुरक्षित रिफ्रेश मैकेनिज्म पसंद करें। यदि “मुझे याद रखो” जरूरी है, तो उसे रिफ्रेश टोकन्स और सर्वर-साइड नियंत्रणों के साथ करें।

2) issuer और audience चेक छोड़ना

सिग्नेचर वैध होना काफी नहीं है। iss और aud सत्यापित करें, और समय-आधारित क्लेम्स जैसे exp और nbf की जाँच करें।

3) डिकोडेड पेलोड पर भरोसा करना

डिकोड करना सत्यापन नहीं है। हमेशा सर्वर पर सिग्नेचर सत्यापित करें और सर्वर-साइड पर परमिशन्स लागू करें।

4) एल्गोरिद्म भ्रम और कुंजी गड़बड़ी

• टोकन के दावा किए गए एल्गोरिद्म को स्वीकार मत करिए—अपेक्षित एल्गोरिदम की allowlist रखें।
• सममित कुंजी (HS256) और असममित कुंजी (RS256/ES256) को मिला कर न रखें।
• कुंजियों को पर्यावरण के अनुसार अलग रखें और रोटेशन कम-से- कम विस्फोट-क्षेत्र कम कर देता है।

5) URLs, लॉग्स, और रेफरर्स के माध्यम से टोकन लीक

JWTs को क्वेरी पैरामीटर्स में न रखें। वे ब्राउज़र इतिहास, सर्वर लॉग, एनालिटिक्स टूल्स, और रेफ़रर हेडर्स में पहुँच सकते हैं।

Authorization: Bearer ... का उपयोग करें।

6) कुंजी रोटेशन या रिवोकेशन योजना का अभाव

मानें कि कुंजियाँ और टोकन लीक हो सकते हैं। साइनिंग कुंजियों को रोटेट करें, kid का उपयोग स्मूथ रोटेशन के लिए करें, और रिवोकेशन की रणनीति रखें (छोटे एक्सपायरेशन + खाते/सत्र अक्षम करने की क्षमता)। स्टोरेज मार्गदर्शन के लिए देखें /blog/where-to-store-jwts-safely।

कब JWT उपयोग करें (और कब नहीं)

JWT उपयोगी हैं, पर वे हर स्थिति में सर्वश्रेष्ठ विकल्प नहीं होते। असल सवाल यह है कि क्या आपको एक self-contained टोकन से लाभ होता है जिसे हर अनुरोध पर डेटाबेस लुकअप के बिना सत्यापित किया जा सके।

JWT के लिए अच्छा फिट

• स्केल पर स्टेटलेस APIs: लोकल सत्यापन (सिग्नेचर + expiry) बिना प्रति-रिक्वेस्ट सत्र लुकअप के
• कई सेवाएँ / माइक्रोसर्विसेज: साझा सत्यापन नियम और पब्लिक कीज़
• SPAs और मोबाइल ऐप्स: क्लाइंट सीधे APIs को कॉल करते हैं
• शॉर्ट-लाइव्ड एक्सेस टोकन: चोरी के प्रभाव को कम करता है

जब JWT खराब विकल्प हो सकते हैं

• तुरंत रिवोक अनिवार्य हो: “अब सब जगह लॉगआउट” जैसी ज़रूरतों के लिए सत्र सरलीकृत करते हैं यदि आप अतिरिक्त इन्फ्रास्ट्रक्चर नहीं रखना चाहते
• आप संवेदनशील डेटा ले जाना चाहते हैं: सामान्य JWTs साइन होते हैं, एन्क्रिप्ट नहीं
• लॉन्ग-लाइव्ड टोकन: ये हाई-वैल्यू होते हैं और चुराए जाने पर जिम्मेदारी ज्यादा होती है

जब सरल सत्र कूकीज़ बेहतर हों

पारंपरिक सर्वर-रेंडर किए गए वेब ऐप्स के लिए जहाँ सुलभ इनवैलिडेशन मायने रखता है, सर्वर-साइड सत्र्स और HttpOnly कूकीज़ अक्सर सरल और सुरक्षित डिफ़ॉल्ट होते हैं।

त्वरित निर्णय चेकलिस्ट

यदि आपको सर्विसेज़ के बीच स्टेटलेस सत्यापन चाहिए और आप टोकन को शॉर्ट-लाइव रख सकते हैं तो JWT चुनें।

यदि आपको तत्काल रिवोकेशन चाहिए, टोकन में संवेदनशील डेटा रखने का इरादा है, या आप बिना झंझट के सत्र कूकीज़ का उपयोग कर सकते हैं तो JWT से बचें।

व्यावहारिक चेकलिस्ट और FAQs

सत्यापन चेकलिस्ट (हर बार क्या जाँचना चाहिए)

1. सिग्नेचर वैध है

सही कुंजी और अपेक्षित एल्गोरिद्म का उपयोग कर सत्यापित करें। अस्वीकृत सिग्नेचरों को रोका जाए—कोई अपवाद नहीं।

2. exp (समाप्ति)

सुनिश्चित करें कि टोकन समाप्त नहीं हुआ है।

3. nbf (नोट बिफोर)

यदि मौजूद हो, तो सुनिश्चित करें कि टोकन बहुत जल्दी उपयोग नहीं हो रहा।

4. aud (ऑडियन्स)

पुष्टि करें कि टोकन आपकी API/सर्विस के लिए था।

5. iss (इशूअर)

पुष्टि करें कि टोकन अपेक्षित जारीकर्ता से आया था।

6. सैनिटी चेक्स (अनुशंसित)

टोकन फ़ॉर्मेट वैलिडेट करें, अधिकतम आकार लागू करें, और अप्रत्याशित क्लेम प्रकार अस्वीकार करें ताकि एज-केस बग घटें।

HS256 बनाम RS256/ES256 चुनना

• HS256 (सिमेट्रिक की): एक साझा सीक्रेट साइन और वेरीफाई करता है.

  • अच्छा: एकल ऐप/API जिसे एक टीम नियंत्रित करती है.
  • सावधानी: कोई भी वेरीफायर जिसके पास सीक्रेट है, टोकन भी बना सकता है.

• RS256 / ES256 (असिमेट्रिक कुंजियाँ): प्राइवेट की साइन करती है; पब्लिक की वेरीफाई.

  • अच्छा: कई सर्विसेज़ को टोकन सत्यापित करने की ज़रूरत हो; सार्वजनिक कुंजियाँ बांट सकते हैं बिना साइन करने की अनुमति दिए।
  • ऑपरेशनल नोट: रोटेशन अक्सर सुरक्षित होता है क्योंकि सिर्फ साइन करने वाला प्राइवेट की रखता है।

रूल ऑफ थम्ब: यदि कई स्वतंत्र सिस्टम्स को टोकन सत्यापित करना है (या आप हर वेरीफायर पर भरोसा नहीं करते), तो RS256/ES256 पसंद करें।

मॉनिटरिंग और लॉगिंग (बिना टोकन लीक किए)

• कच्चे टोकन लॉग न करें (हेडर्स, कूकीज़, क्वेरी स्ट्रिंग्स)।
• यदि आपको करलेशन चाहिए, तो टोकन फिंगरप्रिंट (उदा. हैश) या सुरक्षित मेटाडेटा लॉग करें (iss, aud, और नीति की अनुमति होने पर उपयोगकर्ता ID)।
• अनोमलीज़ पर नजर रखें: सिग्नेचर फेलियर, एक्स्पायर्ड टोकन में स्पाइक, असामान्य ऑडियन्स/इशूअर्स, और संदिग्ध रिफ्रेश पैटर्न।

FAQs

क्या JWT एन्क्रिप्टेड है?

डिफ़ॉल्ट रूप से नहीं। अधिकांश JWTs साइन होते हैं, एन्क्रिप्टेड नहीं। इसका अर्थ है कि सामग्री किसी भी टोकन धारक द्वारा पढ़ी जा सकती है। गोपनीयता के लिए JWE या संवेदनशील डेटा को JWT से बाहर रखें।

क्या मैं JWT रिवोक कर सकता/सकती हूँ?

यदि आप केवल self-contained access tokens पर निर्भर हैं तो नहीं आसानी से। आम दृष्टिकोण: शॉर्ट-लाइव्ड एक्सेस टोकन, हाई-रिस्क घटनाओं के लिए deny-lists, या रोटेटिंग refresh टोकन्स।

exp कितनी लंबी होनी चाहिए?

जितना आपकी UX और आर्किटेक्चर अनुमति देती है उतना छोटा रखें। कई APIs access tokens के लिए मिनटों का उपयोग करते हैं और लंबी सत्रों के लिए refresh tokens का उपयोग करते हैं।

Koder.ai के साथ JWT-प्रोटेक्टेड ऐप तेज़ी से बनाना

यदि आप किसी नए API या SPA में JWT ऑथ इम्प्लीमेंट कर रहे हैं, तो कई काम दोहराव वाले होते हैं: मिडलवेयर वाइर करना, iss/aud/exp को वैलिडेट करना, कूकी फ्लैग सेट करना, और लॉग से टोकन हैंडलिंग को हटाना।

Koder.ai के साथ, आप एक वेब ऐप (React), बैकएंड सेवाएँ (Go + PostgreSQL), या Flutter मोबाइल ऐप को चैट-ड्रिवन वर्कफ़्लो के ज़रिये तेज़ी से कोड कर सकते हैं—फिर सुरक्षा, कुंजी रोटेशन रणनीति और डिप्लॉयमेंट सेटिंग्स को नियंत्रित रखते हुए इटेरेट कर सकते हैं।