यदि आप JWT को डिकोड कर सकते हैं, तो वे कैसे सुरक्षित हैं?

302

अगर मुझे JWT मिलता है और मैं पेलोड को डीकोड कर सकता हूं, तो यह कैसे सुरक्षित है? क्या मैं सिर्फ हेडर से डिकोड नहीं कर सकता, पेलोड में उपयोगकर्ता की जानकारी को डीकोड कर सकता हूं और बदल सकता हूं, और इसे उसी सही एन्कोडेड सीक्रेट के साथ वापस भेज सकता हूं?

मुझे पता है कि वे सुरक्षित होना चाहिए, लेकिन मैं वास्तव में प्रौद्योगिकियों को समझना चाहूंगा। मैं क्या खो रहा हूँ?

security jwt express-jwt

— PixMach
स्रोत

1

md5('original messaged' + secret) != md5('changed message' + secret)इस प्रकार यदि कोई संदेश बदलता है तो आप इसका पता लगा सकते हैं

— पिथिकोस

एक आदर्श मामले के लिए सच है, हालांकि, md5 में टक्कर है। @Pikikos

— यश कुमार वर्मा

@ यशकुमार वर्मा, हाँ, यह सिर्फ इसका सार प्रदर्शित करना है क्योंकि हर कोई md5 जानता है।

— पिथिकोस

@Pikikos आप मूल संदेश को कैसे जानते हैं?

— user1955934

1

@ user1955934 यह base64 एनकोडेड है, एन्क्रिप्टेड नहीं है । आप बस इसे किसी भी बेस 64 डिकोडर से डिकोड कर सकते हैं।

— पिथिकोस

386

JWTs पर हस्ताक्षर किए, एन्क्रिप्ट किए गए या दोनों हो सकते हैं। यदि एक टोकन पर हस्ताक्षर किए गए हैं, लेकिन एन्क्रिप्ट नहीं किए गए हैं, तो हर कोई इसकी सामग्री पढ़ सकता है, लेकिन जब आपको निजी कुंजी नहीं पता है, तो आप इसे बदल नहीं सकते हैं। अन्यथा, रिसीवर नोटिस करेगा कि हस्ताक्षर अब मेल नहीं खाएगा।

आपकी टिप्पणी का उत्तर: मुझे यकीन नहीं है कि अगर मैं आपकी टिप्पणी को सही तरीके से समझता हूं। बस यह सुनिश्चित करने के लिए: क्या आप डिजिटल हस्ताक्षरों को जानते और समझते हैं? मैं केवल एक संस्करण (HMAC, जो सममित है, को समझाऊंगा, लेकिन कई अन्य हैं)।

मान लेते हैं कि ऐलिस बॉब को JWT भेजना चाहता है। वे दोनों कुछ साझा रहस्य जानते हैं। मैलोरी उस रहस्य को नहीं जानती, लेकिन JWT को हस्तक्षेप करना और बदलना चाहती है। इसे रोकने के लिए, ऐलिस Hash(payload + secret)हस्ताक्षर के रूप में इसकी गणना और संलग्न करता है।

संदेश प्राप्त करते समय, बॉब यह Hash(payload + secret)जांचने के लिए भी गणना कर सकता है कि हस्ताक्षर मेल खाते हैं या नहीं। हालांकि, यदि मालोरी सामग्री में कुछ बदलता है, तो वह मिलान हस्ताक्षर (जो होगा Hash(newContent + secret)) की गणना करने में सक्षम नहीं है । वह रहस्य नहीं जानती और इसका पता लगाने का कोई तरीका नहीं है। इसका मतलब है कि अगर वह कुछ बदलती है, तो हस्ताक्षर अब मेल नहीं खाएगा, और बॉब बस जेडब्ल्यूटी को स्वीकार नहीं करेगा।

मान लीजिए, मैं एक अन्य व्यक्ति को संदेश भेजता हूं {"id":1}और उसके साथ हस्ताक्षर करता हूं Hash(content + secret)। (+ यहाँ सिर्फ सहमति है)। मैं SHA256 हैश फ़ंक्शन का उपयोग करता हूं, और मुझे जो हस्ताक्षर मिलता है वह है 330e7b0775561c6e95797d4dd306a150046e239986f0a1373230fda0235bda8c:। अब आपकी बारी है: मैलोरी की भूमिका निभाएं और संदेश पर हस्ताक्षर करने का प्रयास करें {"id":2}। आप नहीं कर सकते क्योंकि आप नहीं जानते कि मैंने कौन सा रहस्य इस्तेमाल किया। अगर मुझे लगता है कि प्राप्तकर्ता रहस्य जानता है, तो वह किसी भी संदेश के हस्ताक्षर की गणना कर सकता है और जांच कर सकता है कि क्या यह सही है।

— Misch
स्रोत

8

तो पेलोड बदलने पर हस्ताक्षर बदल जाता है? मैं इस धारणा के तहत था कि टोकन प्रारूप [हैडर] में था। [पेलोड]। [हस्ताक्षर] पेलोड और गुप्त के संयोजन द्वारा गणना की गई हस्ताक्षर है? अगर ऐसा होता, तो एक अलग आईडी वाला पेलोड उस रहस्य के लिए समान नहीं होता? जैसे अगर डेटा {आईडी: 1} था और इसका उपयोग गुप्त के साथ टोकन के हस्ताक्षर वाले हिस्से की गणना करने के लिए किया जाता है, तो इसका मतलब यह नहीं होगा कि {आईडी: 2} उपयोगकर्ता 2 के लिए मान्य होगा, और इसलिए उपयोगकर्ता 1 बदल सकता है आईडी टू और टोकन एक ही होगा?

— 21

7

मैंने आपको चीजों को अभी भी स्पष्ट करने के लिए एक उदाहरण दिया है, लेकिन मैं आपको डिजिटल हस्ताक्षर और एचएमएसी की पूरी अवधारणा आपको नहीं समझाऊंगा। कृपया उन चीजों के बारे में पढ़ें, इसे समझाने के लिए बहुत सारी सामग्री है।

— Misch

11

ओह अब मुझे समझ आ गया। मुझे नहीं पता कि मुझे यह क्यों याद आ रहा था कि गुप्त हैश सही नहीं होगा जब आप पेलोड को बदल देंगे क्योंकि गुप्त हैश को पुनर्गणना करना होगा। किसी कारण से मैं अभी भी सोच रहा था कि यह स्वतंत्र था। कि पिछले बिट वास्तव में यह मेरे लिए घर drilled। मुझे इसके माध्यम से चलने के लिए धन्यवाद।

— 16

30

मेरा एक संबंधित प्रश्न है। कॉपी किए गए JWT के साथ ऐलिस को लगाने से क्या किसी को रोका जा सकता है?

— मॉरिसलेस

25

अगर किसी के पास JWT है तो वे ऐलिस को प्रतिरूपित कर सकते हैं। इसलिए आपको सावधान रहना होगा कि आप इसे कैसे स्टोर और भेजते हैं। आपको पेलोड में इसके लिए एक एक्सपायरी भी सेट करनी चाहिए। इस तरह अगर कोई JWT चुराता है तो उसके पास इसका उपयोग करने के लिए एक सीमित समय सीमा होती है। तूफ़ान

— गेरिएंट एंडरसन

134

आप जा सकते हैं jwt.io, अपना टोकन पेस्ट कर सकते हैं और सामग्री पढ़ सकते हैं। यह शुरू में बहुत सारे लोगों के लिए परेशान है।

संक्षिप्त उत्तर यह है कि JWT एन्क्रिप्शन के साथ ही चिंता नहीं करता है। यह सत्यापन की परवाह करता है। यह कहना है, यह हमेशा के लिए "इस टोकन हेरफेर की सामग्री है" के लिए जवाब मिल सकता है? इसका अर्थ है कि JWT टोकन का उपयोगकर्ता हेरफेर निरर्थक है क्योंकि सर्वर को टोकन का पता चल जाएगा और उसकी अवहेलना होगी। क्लाइंट को टोकन जारी करते समय सर्वर पेलोड के आधार पर एक हस्ताक्षर जोड़ता है। बाद में यह पेलोड और मिलान हस्ताक्षर की पुष्टि करता है।

तार्किक सवाल यह है कि एन्क्रिप्टेड सामग्री के साथ खुद के विषय में नहीं करने के लिए प्रेरणा क्या है?

सबसे सरल कारण है क्योंकि यह मानता है कि यह अधिकांश भाग के लिए एक हल की गई समस्या है। यदि उदाहरण के लिए वेब ब्राउज़र जैसे क्लाइंट के साथ काम करते हैं, तो आप JWT टोकन को कुकी में संग्रहीत कर सकते हैं secure(जो HTTP के माध्यम से प्रसारित नहीं किया जाता है, केवल HTTPS के माध्यम से) और httpOnly(जावास्क्रिप्ट द्वारा नहीं पढ़ा जा सकता) और सर्वर पर बात करता है एक एन्क्रिप्टेड चैनल (HTTPS)। एक बार जब आपको पता चल जाता है कि आपके पास सर्वर और क्लाइंट के बीच एक सुरक्षित चैनल है, तो आप JWT या जो भी आप चाहते हैं, सुरक्षित रूप से एक्सचेंज कर सकते हैं।
यह बात सरल रखता है। एक सरल कार्यान्वयन अपनाने को आसान बनाता है, लेकिन यह प्रत्येक परत को वह करने देता है जो इसे सबसे अच्छा करता है (एचटीटीपीएस को एन्क्रिप्शन को संभालने दें)।
JWT का मतलब संवेदनशील डेटा को स्टोर करना नहीं है। एक बार जब सर्वर JWT टोकन प्राप्त करता है और इसे सत्यापित करता है, तो यह उस उपयोगकर्ता के लिए अतिरिक्त जानकारी (जैसे अनुमतियां, पोस्टल एड्रेस आदि) के लिए अपने स्वयं के डेटाबेस में उपयोगकर्ता आईडी देखने के लिए स्वतंत्र है। यह JWT को आकार में छोटा रखता है और अनजाने सूचना रिसाव से बचता है क्योंकि हर कोई जानता है कि JWT में संवेदनशील डेटा नहीं रखा गया है।

यह बहुत अलग नहीं है कि कुकीज़ स्वयं कैसे काम करती हैं। कुकीज़ में अक्सर अनएन्क्रिप्टेड पेलोड होते हैं। अगर आप HTTPS का इस्तेमाल कर रहे हैं तो सब कुछ अच्छा है। यदि आप नहीं हैं, तो संवेदनशील कुकीज़ को स्वयं एन्क्रिप्ट करना उचित है। ऐसा नहीं करने का मतलब यह होगा कि एक आदमी के बीच में हमला संभव है - एक प्रॉक्सी सर्वर या आईएसपी कुकीज़ को पढ़ता है और फिर आपके होने का नाटक करने पर बाद में उन्हें फिर से पढ़ता है। इसी तरह के कारणों के लिए, JWT को हमेशा HTTPS जैसी सुरक्षित परत के ऊपर बदला जाना चाहिए।

— aleemb
स्रोत

4

ध्यान दो! जेडब्ल्यूटी को हमेशा एचटीटीपीएस

— कोडिमिरर

लेकिन अगर JWT केवल HTTPS पर सुरक्षित है, तो सिर्फ पेलोड क्यों नहीं भेजा जाए? POST -> उपयोगकर्ता नाम, पासवर्ड। यह अभी भी सही एन्क्रिप्टेड है?

— GeekPeek

@ GeekPeek के लिए आपको JWT बेसिक्स पर पढ़ना चाहिए लेकिन आप जैसा उल्लेख करते हैं, वैसे ही सेशन ऑथोरिटी आपको अक्सर चाहिए होती है। JWT कुछ अन्य लाभ प्रदान करता है, लेकिन कुछ ट्रेडऑफ webskeleton.com/webdev/2019/10/22/…

— aleemb

17

एक जासन वेब टोकन (JWT) की सामग्री स्वाभाविक रूप से सुरक्षित नहीं है, लेकिन टोकन प्रामाणिकता की पुष्टि करने के लिए एक अंतर्निहित सुविधा है। एक JWT पीरियड्स से अलग तीन हैश है। तीसरा है हस्ताक्षर। एक सार्वजनिक / निजी कुंजी प्रणाली में, जारीकर्ता एक निजी कुंजी के साथ टोकन हस्ताक्षर पर हस्ताक्षर करता है जिसे केवल इसकी संबंधित सार्वजनिक कुंजी द्वारा सत्यापित किया जा सकता है।

जारीकर्ता और सत्यापनकर्ता के बीच अंतर को समझना महत्वपूर्ण है। टोकन प्राप्त करने वाला इसे सत्यापित करने के लिए जिम्मेदार है।

वेब एप्लिकेशन में सुरक्षित रूप से JWT का उपयोग करने में दो महत्वपूर्ण चरण हैं: 1) उन्हें एक एन्क्रिप्टेड चैनल पर भेजें, और 2) इसे प्राप्त करने पर तुरंत हस्ताक्षर सत्यापित करें। सार्वजनिक कुंजी क्रिप्टोग्राफी की असममित प्रकृति JWT हस्ताक्षर सत्यापन को संभव बनाती है। एक सार्वजनिक कुंजी सत्यापित करता है कि एक JWT ने अपनी मिलान निजी कुंजी द्वारा हस्ताक्षरित किया था। चाबियों का कोई अन्य संयोजन इस सत्यापन को नहीं कर सकता है, इस प्रकार प्रतिरूपण प्रयासों को रोका जा सकता है। इन दो चरणों का पालन करें और हम गणितीय निश्चितता के साथ एक जेडब्ल्यूटी की प्रामाणिकता की गारंटी दे सकते हैं।

अधिक पढ़ना: एक सार्वजनिक कुंजी एक हस्ताक्षर को कैसे सत्यापित करती है?

— ThisClark
स्रोत

2

चलिए शुरू करते हैं,

JWT एक बहुत ही आधुनिक, सरल और सुरक्षित तरीका है जो Json Web टोकन के लिए विस्तारित होता है। Json वेब टोकन प्रमाणीकरण के लिए एक स्टेटलेस समाधान है। इसलिए सर्वर पर किसी भी सत्र राज्य को संग्रहीत करने की आवश्यकता नहीं है, जो निश्चित रूप से आरामदायक एपीआई के लिए एकदम सही है। रेस्टफुल एपीआई हमेशा स्टेटलेस होनी चाहिए, और JWTs के साथ ऑथेंटिकेशन के लिए सबसे ज्यादा इस्तेमाल किया जाने वाला ऑप्शन सिर्फ सेशन का इस्तेमाल कर यूजर के लॉग-इन स्टेट को सर्वर पर स्टोर करना है। लेकिन फिर निश्चित रूप से उस सिद्धांत का पालन नहीं करता है जो कहता है कि आराम करने वाले एपीआई स्टेटलेस होने चाहिए और यही कारण है कि जेडब्ल्यूटी जैसे समाधान लोकप्रिय और प्रभावी हो गए।

तो अब आइए जानते हैं कि जेनसन वेब टोकन के साथ वास्तव में प्रमाणीकरण कैसे काम करता है। यह मानते हुए कि हमारे डेटाबेस में पहले से ही एक पंजीकृत उपयोगकर्ता है। तो उपयोगकर्ता का उपयोगकर्ता नाम और पासवर्ड के साथ एक पोस्ट अनुरोध करने से शुरू होता है, एप्लिकेशन तब जांचता है कि क्या उपयोगकर्ता मौजूद है और यदि पासवर्ड सही है, तो एप्लिकेशन केवल उस उपयोगकर्ता के लिए एक अद्वितीय Json वेब टोकन उत्पन्न करेगा।

टोकन एक का उपयोग कर बनाई गई है गुप्त स्ट्रिंग है कि है एक सर्वर पर संग्रहीत । इसके बाद, सर्वर उस JWT को क्लाइंट को वापस भेज देता है जो इसे कुकी में या स्थानीय भंडारण में संग्रहीत करेगा।

बस इस तरह, उपयोगकर्ता को प्रमाणित किया जाता है और मूल रूप से सर्वर पर किसी भी राज्य को छोड़े बिना हमारे आवेदन में लॉग इन किया जाता है।

इसलिए सर्वर वास्तव में यह नहीं जानता है कि कौन सा उपयोगकर्ता वास्तव में लॉग इन है, लेकिन निश्चित रूप से, उपयोगकर्ता जानता है कि वह लॉग इन है क्योंकि उसके पास एक वैध जोंस वेब टोकन है जो कि आवेदन के संरक्षित भागों तक पहुंचने के लिए पासपोर्ट की तरह है।

तो फिर, बस यह सुनिश्चित करने के लिए कि आपको विचार मिला है। जैसे ही वह सर्वर पर कहीं भी सेव नहीं होता है, उसका यूनीक वैध जोंस वेब टोकन वापस मिल जाता है, जैसे ही कोई उपयोगकर्ता लॉग इन करता है। और इसलिए यह प्रक्रिया पूरी तरह से स्टेटलेस है।

फिर, जब भी कोई उपयोगकर्ता उदाहरण के लिए अपने उपयोगकर्ता प्रोफ़ाइल डेटा जैसे संरक्षित मार्ग का उपयोग करना चाहता है। वह अपने जसन वेब टोकन को एक अनुरोध के साथ भेजता है, इसलिए यह उस मार्ग तक पहुंचने के लिए अपना पासपोर्ट दिखाने जैसा है।

एक बार अनुरोध सर्वर को हिट कर देता है, तो हमारा ऐप यह सत्यापित करेगा कि क्या Json वेब टोकन वास्तव में वैध है और यदि उपयोगकर्ता वास्तव में कहता है कि वह कौन है, तो ठीक है, तो अनुरोधित डेटा क्लाइंट को भेजा जाएगा और यदि नहीं, तो वहाँ होगा उपयोगकर्ता को यह बताने में त्रुटि हो कि उसे उस संसाधन तक पहुंचने की अनुमति नहीं है।

यह सभी संचार https पर होने चाहिए, ताकि एन्क्रिप्ट किया गया Http सुरक्षित रहे ताकि किसी को भी पासवर्ड या Json Web टोकन तक पहुँच मिल सके। तभी हमारे पास वास्तव में सुरक्षित प्रणाली है।

तो एक Json Web Token इस स्क्रीनशॉट के बायें हिस्से की तरह दिखता है जिसे JWT डिबगर से jwt.ioSo पर अनिवार्य रूप से लिया गया था, यह तीन भागों से बना एन्कोडिंग स्ट्रिंग है। हेडर, पेलोड और सिग्नेचर अब हेडर केवल टोकन के बारे में कुछ मेटाडेटा है और पेलोड वह डेटा है जिसे हम टोकन में एनकोड कर सकते हैं, कोई भी डेटा जो हम वास्तव में चाहते हैं। तो जितना अधिक डेटा हम यहाँ JWT को बड़ा करना चाहते हैं। वैसे भी, ये दो हिस्से सिर्फ सादे पाठ हैं जो एन्कोडेड हो जाएंगे, लेकिन एन्क्रिप्टेड नहीं।

इसलिए कोई भी उन्हें डिकोड कर सकेगा और उन्हें पढ़ सकेगा , हम यहां कोई संवेदनशील डेटा संग्रहीत नहीं कर सकते। लेकिन यह एक समस्या नहीं है क्योंकि तीसरे भाग में, इसलिए हस्ताक्षर में, वह जगह है जहां चीजें वास्तव में दिलचस्प होती हैं। हस्ताक्षर हेडर, पेलोड और सर्वर पर सहेजे गए रहस्य का उपयोग करके बनाया जाता है।

और इस पूरी प्रक्रिया को तब Json Web Token पर हस्ताक्षर करना कहा जाता है । हस्ताक्षरित एल्गोरिथ्म हेडर, पेलोड और एक अद्वितीय हस्ताक्षर बनाने के लिए रहस्य लेता है। तो केवल यह डेटा और रहस्य ही इस हस्ताक्षर को बना सकता है, ठीक है? फिर हेडर और पेलोड के साथ, ये हस्ताक्षर JWT बनाते हैं, जो फिर क्लाइंट को भेजा जाता है।

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

तो, यह सत्यापन वास्तव में कैसे काम करता है? खैर, यह वास्तव में काफी सीधा है। एक बार JWT प्राप्त होने के बाद, सत्यापन अपने हेडर और पेलोड को ले जाएगा, और एक साथ उस रहस्य के साथ जो अभी भी सर्वर पर सहेजा गया है, मूल रूप से एक परीक्षण हस्ताक्षर बनाते हैं।

लेकिन जब JWT को पहली बार बनाया गया था तो मूल हस्ताक्षर टोकन में ही था, है ना? और यही इस सत्यापन की कुंजी है। क्योंकि अब हमें बस इतना करना है कि मूल हस्ताक्षर के साथ परीक्षण हस्ताक्षर की तुलना करें। और यदि परीक्षण हस्ताक्षर मूल हस्ताक्षर के समान है, तो इसका मतलब है कि पेलोड और हेडर को संशोधित नहीं किया गया है।

क्योंकि यदि उन्हें संशोधित किया गया था, तो परीक्षण हस्ताक्षर अलग होना होगा। इसलिए इस मामले में जहां डेटा में कोई फेरबदल नहीं किया गया है, तब हम उपयोगकर्ता को प्रमाणित कर सकते हैं। और हां, अगर दोनों हस्ताक्षर वास्तव में अलग-अलग हैं, तो इसका मतलब है कि किसी ने डेटा के साथ छेड़छाड़ की है। आमतौर पर पेलोड को बदलने की कोशिश करके। लेकिन पेलोड में हेरफेर करने वाले तीसरे पक्ष के पास निश्चित रूप से गुप्त तक पहुंच नहीं है, इसलिए वे जेडब्ल्यूटी पर हस्ताक्षर नहीं कर सकते। इसलिए मूल हस्ताक्षर हेरफेर किए गए डेटा के अनुरूप नहीं होंगे। और इसलिए, इस मामले में सत्यापन हमेशा विफल रहेगा। और इस पूरे सिस्टम को काम करने की कुंजी है। यह जादू है जो जेडब्ल्यूटी को इतना सरल बनाता है, लेकिन यह भी बहुत शक्तिशाली है।

— भगवान
स्रोत

1

केवल JWT के प्राइवेटके, जो आपके सर्वर पर है, एन्क्रिप्टेड JWT को डिक्रिप्ट करेगा। जो लोग PrivateKey जानते हैं, वे एन्क्रिप्टेड JWT को डिक्रिप्ट कर सकेंगे।

PrivateKey को अपने सर्वर में सुरक्षित स्थान पर छिपाएं और किसी को भी PrivateKey कभी न बताएं।

— sdfdsf sdf
स्रोत

1

JWTs हमेशा एन्क्रिप्टेड नहीं होते हैं। उन्हें साइन इन किया जा सकता है, एन्क्रिप्ट किया जा सकता है, साइन इन किया जा सकता है, फिर एन्क्रिप्ट किया जा सकता है या फिर एनक्रिप्ट किया जा सकता है।

— csauve

0

जो लोग मेरे जैसे महंगे डेटाबेस प्रश्नों को बर्दाश्त नहीं कर सकते हैं, संवेदनशील डेटा रखने के लिए एक विकल्प (उपयोगकर्ता priveledges आदि) है, जब JWT उत्पन्न करते हैं तो आप इस डेटा को एन्क्रिप्ट कर सकते हैं और इसे JWT टोकन के साथ संलग्न कर सकते हैं। (बैकएंड में एन्क्रिप्शन कुंजी रखें)

जब आप संवेदनशील जानकारी पढ़ना चाहते हैं तो आप JWT टोकन को बैकएंड पर भेज सकते हैं और इसे डिक्रिप्ट कर सकते हैं और जानकारी वापस पा सकते हैं। इस तरह, आपको DB लुकअप करने की आवश्यकता नहीं है या JWT टोकन के माध्यम से दृश्यपटल में संवेदनशील जानकारी नग्न है

— निरंजन सेल्वनाथन
स्रोत

-1

मैं विशेष एल्गोरिदम का उपयोग करते हुए जेडब्ल्यूई पर एक नज़र डालने का सुझाव दूंगा जो कि डिक्रिप्ट करने के लिए jwt.io में मौजूद नहीं है

संदर्भ लिंक: https://www.npmjs.com/package/node-webtokens

jwt.generate('PBES2-HS512+A256KW', 'A256GCM', payload, pwd, (error, token) => {
  jwt.parse(token).verify(pwd, (error, parsedToken) => {
    // other statements
  });
});

यह उत्तर बहुत देर हो सकती है या आपको पहले से ही पता चल गया होगा, लेकिन फिर भी, मुझे लगा कि यह आपके और दूसरों के लिए भी उपयोगी होगा।

एक सरल उदाहरण जो मैंने बनाया है: https://github.com/hansiemithun/jwe-example

— मिथुन श्रीवत्स
स्रोत