Node.js API में JWT प्रमाणीकरण को पेशेवर तरीके से लागू करें

होम » अजगर » Node.js API में JWT प्रमाणीकरण को पेशेवर तरीके से लागू करें

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

इस गाइड में हम Node.js API में Express, MongoDB और jsonwebtoken, bcrypt, Joi और dotenv जैसे टूल्स का उपयोग करके JWT-आधारित प्रमाणीकरण को लागू करने का तरीका जानेंगे, और हम यह भी देखेंगे कि अधिक उद्यम-उन्मुख परिदृश्यों में प्राधिकरण सर्वर से JWKS एंडपॉइंट का उपयोग करके टोकन को कैसे मान्य किया जाए। आप सीखेंगे कि प्रोजेक्ट संरचना को कैसे डिजाइन किया जाए, मॉडल और रूट कैसे बनाए जाएं, टोकन कैसे जनरेट और वेरिफाई किए जाएं, ऑथेंटिकेशन मिडलवेयर कैसे जोड़ा जाए और सब कुछ इस तरह से कैसे जोड़ा जाए ताकि केवल प्रमाणित उपयोगकर्ता ही सुरक्षित संसाधनों तक पहुंच सकें।

JSON वेब टोकन (JWT) आपके Node.js API में क्या लाभ लाते हैं?

JSON वेब टोकन (JWT) कॉम्पैक्ट, URL-सुरक्षित टोकन होते हैं जो दावों का एक सेट ले जाते हैं और दो पक्षों को सर्वर-साइड सत्र स्थिति को बनाए रखे बिना प्रमाणित जानकारी का आदान-प्रदान करने की अनुमति देते हैं। Node.js API के संदर्भ में इसका मतलब यह है कि एक बार जब कोई उपयोगकर्ता साइन इन कर लेता है और आप एक JWT जारी करते हैं, तो प्रत्येक बाद के अनुरोध को आपके बैकएंड द्वारा केवल टोकन और एक गुप्त या सार्वजनिक कुंजी का उपयोग करके सत्यापित किया जा सकता है, जो पारंपरिक सर्वर सत्रों की तुलना में कहीं बेहतर स्केल करता है।

एक सामान्य JWT तीन भागों से मिलकर बना होता है: एक हेडर, एक पेलोड और एक सिग्नेचर, ये सभी Base64URL में एन्कोड किए गए होते हैं और डॉट्स द्वारा अलग किए जाते हैं, उदाहरण के लिए। xxxxx.yyyyy.zzzzz. हेडर में आमतौर पर एल्गोरिदम और टोकन प्रकार निर्दिष्ट होते हैं, पेलोड में उपयोगकर्ता से संबंधित दावे जैसे कि आईडी, भूमिकाएं या अनुमतियां शामिल होती हैं, और हस्ताक्षर अखंडता सुनिश्चित करता है ताकि टोकन के साथ छेड़छाड़ का पता न चल सके।

Node.js API में JWT को लागू करते समय, आप आमतौर पर टोकन को बियरर टोकन के रूप में उपयोग करते हैं। Authorization HTTP हेडर, जैसे Authorization: Bearer <token>और फिर इसे अपने एक्सप्रेस मिडलवेयर या रूट हैंडलर के अंदर डिकोड और वैलिडेट करें। यदि टोकन वैध है, तो आप डिकोड किए गए पेलोड को अनुरोध ऑब्जेक्ट से जोड़ सकते हैं और बाद में इसका उपयोग प्राधिकरण संबंधी निर्णयों के लिए या प्रतिक्रिया को वैयक्तिकृत करने के लिए कर सकते हैं।

JWT का एक शक्तिशाली पहलू यह है कि वे भाषा-स्वतंत्र हैं और विभिन्न पारिस्थितिकी प्रणालियों में व्यापक रूप से समर्थित हैं, जो उन्हें React, Vue, मोबाइल ऐप्स या किसी भी तृतीय-पक्ष क्लाइंट द्वारा उपयोग किए जाने वाले API को सुरक्षित करने के लिए एक उत्कृष्ट विकल्प बनाता है। ठोस सत्यापन और उचित कुंजी प्रबंधन के साथ मिलकर, वे Node.js सेवाओं को OAuth 2.0 और OpenID Connect आधारित आर्किटेक्चर में सुचारू रूप से भाग लेने की अनुमति देते हैं।

प्रोजेक्ट का संक्षिप्त विवरण: JWT प्रमाणीकरण के साथ Node.js API

आइए एक सरल लेकिन व्यावहारिक Node.js API की कल्पना करें जहां उपयोगकर्ता वैध JWT प्रस्तुत करने के बाद ही पंजीकरण कर सकते हैं, लॉग इन कर सकते हैं और सुरक्षित एंडपॉइंट्स तक पहुंच सकते हैं। हम राउटिंग के लिए एक्सप्रेस, मोंगोडीबी इंटीग्रेशन के लिए मोंगोस, टोकन बनाने और सत्यापित करने के लिए jsonwebtoken, सुरक्षित पासवर्ड हैशिंग के लिए bcrypt, इनपुट सत्यापन के लिए Joi और कॉन्फ़िगरेशन प्रबंधन के लिए dotenv पर निर्भर रहेंगे।

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

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

इसी पैटर्न को अधिक जटिल प्रणालियों तक बढ़ाया जा सकता है, जिनमें वे प्रणालियाँ भी शामिल हैं जो एक बाहरी प्राधिकरण सर्वर के साथ एकीकृत होती हैं और OAuth 2.0 क्लाइंट से आने वाले एक्सेस टोकन को मान्य करने के लिए JWKS एंडपॉइंट का उपयोग करती हैं। यह दूसरा परिदृश्य विशेष रूप से तब आम होता है जब आप प्रमाणीकरण को पहचान प्रदाताओं को सौंपते हैं या कई सेवाओं में एकल साइन-ऑन का समर्थन करने की आवश्यकता होती है।

इससे पहले कि हम कार्यान्वयन की बारीकियों में उतरें, आइए उस वातावरण के प्रमुख हिस्सों की रूपरेखा तैयार कर लें जिन पर हम निर्भर रहेंगे और नोड.जेएस में सुरक्षित जेडब्ल्यूटी हैंडलिंग के लिए प्रत्येक निर्भरता क्यों महत्वपूर्ण है।

Node.js में JWT प्रमाणीकरण के लिए मुख्य निर्भरताएँ

एक्सप्रेस कई Node.js API की रीढ़ की हड्डी है, जो रूटिंग, मिडलवेयर और HTTP हैंडलिंग के लिए एक न्यूनतम लेकिन लचीला ढांचा प्रदान करती है। हमारे मामले में, एक्सप्रेस एक ऐसे प्लेटफॉर्म के रूप में काम करेगा जहां हम मार्गों को पंजीकृत करेंगे जैसे /api/users or /api/authऔर यहीं पर हम JWT सत्यापन मिडलवेयर को प्लग इन करते हैं जो संवेदनशील एंडपॉइंट्स की सुरक्षा करता है।

Mongoose एक ऑब्जेक्ट डेटा मॉडलिंग (ODM) लाइब्रेरी है जो सीधे रॉ क्वेरी के साथ काम करने के बजाय स्कीमा और मॉडल के माध्यम से MongoDB के साथ इंटरैक्ट करना आसान बनाती है। हम इसका उपयोग परिभाषित करने के लिए करेंगे User नाम, ईमेल और पासवर्ड जैसी विशेषताओं वाले मॉडल का निर्माण करना और इन दस्तावेजों को डेटाबेस से टाइप-सेफ तरीके से सहेजना या पुनः प्राप्त करना।

RSI jsonwebtoken Node.js में गुप्त या सार्वजनिक कुंजी का उपयोग करके JWT बनाने और सत्यापित करने के लिए लाइब्रेरी एक मानक विकल्प है। लॉगिन के दौरान हम एक टोकन पर हस्ताक्षर करेंगे जिसमें उपयोगकर्ता आईडी (और हमें आवश्यक कोई अन्य दावे) शामिल होंगे, और बाद में हम संरक्षित मार्गों पर उस टोकन को सत्यापित करेंगे, और किसी भी ऐसे अनुरोध को अस्वीकार कर देंगे जिसमें अमान्य, गलत तरीके से बना या समाप्त हो चुका टोकन हो।

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

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

अंत में, dotenv हमें एक स्रोत से पर्यावरण चर लोड करने की अनुमति देता है। .env एक फाइल में JWT साइनिंग कुंजी, डेटाबेस URL या कॉन्फ़िगरेशन सेटिंग्स जैसे गुप्त डेटा को सोर्स कोड से बाहर रखा जाता है। इससे संवेदनशील मानों को हार्डकोड करने से बचने में मदद मिलती है, और यह विकास, स्टेजिंग और उत्पादन कॉन्फ़िगरेशन के बीच बेहतर अलगाव को बढ़ावा देता है।

एक्सप्रेस सर्वर और वातावरण स्थापित करना

हमारे एपीआई का प्रवेश बिंदु आमतौर पर एक होता है index.js यह वह फ़ाइल है जहाँ हम एक्सप्रेस को बूटस्ट्रैप करते हैं, मिडलवेयर को रजिस्टर करते हैं और अपनी रूट परिभाषाओं को माउंट करते हैं। इस फाइल में हमें अपने डेटाबेस कॉन्फ़िगरेशन, अपने रूट मॉड्यूल और JSON बॉडी पार्सिंग या CORS जैसे किसी भी ग्लोबल मिडलवेयर की आवश्यकता होगी।

डिपेंडेंसी लोड करने के तुरंत बाद, कॉल करना एक अच्छा विचार है। require("dotenv").config() इसलिए पर्यावरण चर .env फ़ाइल इसके माध्यम से उपलब्ध हो जाती है process.env. इसमें चाबियां शामिल हैं जैसे JWT_PRIVATE_KEY, MONGO_URI या वह पोर्ट जिस पर सर्वर सुनेगा, जिससे कॉन्फ़िगरेशन लचीला और सुरक्षित बना रहता है।

एक्सप्रेस ऐप स्वयं आमतौर पर उपयोग करेगा app.use(express.json()) JSON अनुरोध निकायों को पार्स करने के लिए और विशिष्ट URL उपसर्गों के लिए राउटर माउंट करेगा, जैसे कि app.use("/api/users", usersRouter) और app.use("/api/auth", authRouter). यह पृथक्करण प्रमाणीकरण संबंधी मार्गों और उपयोगकर्ता प्रबंधन संबंधी चिंताओं को एपीआई के अन्य भागों से अलग रखता है।

वातावरण कॉन्फ़िगर हो जाने और एक्सप्रेस के चलने के बाद, अगला चरण एक समर्पित मॉड्यूल के माध्यम से MongoDB डेटाबेस को जोड़ना है, जो अक्सर एक db.js वह फ़ाइल, जहाँ हम कनेक्शन लॉजिक सेट करते हैं।

Mongoose के साथ MongoDB को कॉन्फ़िगर करना

में db.js मॉड्यूल में, हम आमतौर पर Mongoose को इम्पोर्ट करते हैं और कॉल करते हैं mongoose.connect() MongoDB कनेक्शन स्ट्रिंग को एक पर्यावरण चर में संग्रहीत किया जाता है। हम उत्पादन वातावरण में स्थिर व्यवहार सुनिश्चित करने के लिए रिट्राई लॉजिक, यूनिफाइड टोपोलॉजी या कनेक्शन पूलिंग जैसे विकल्पों को भी कॉन्फ़िगर कर सकते हैं।

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

एक बार db.js फ़ाइल कार्यान्वित हो चुकी है, हम इसे आयात करते हैं index.js और एप्लिकेशन स्टार्टअप के दौरान ही इसे कॉल करें, यह सुनिश्चित करते हुए कि किसी भी अनुरोध को संसाधित करने से पहले हमारा एपीआई डेटाबेस से जुड़ा हुआ है। यह पृथक्करण कॉन्फ़िगरेशन को पृथक और पुन: प्रयोज्य बनाए रखता है, जबकि index.js एक्सप्रेस की चिंताओं पर ध्यान केंद्रित रहता है।

डेटाबेस के सही ढंग से जुड़ जाने के बाद, हम उस डेटा को मॉडल करने की ओर बढ़ सकते हैं जो हमारे प्रमाणीकरण सिस्टम को संचालित करता है, जिसकी शुरुआत उपयोगकर्ता स्कीमा और मॉडल की परिभाषा से होती है।

JWT समर्थन के साथ उपयोगकर्ता मॉडल का निर्माण

RSI User मॉडल, जिसे आमतौर पर रखा जाता है /models/user.jsयह MongoDB में संग्रहीत उपयोगकर्ता दस्तावेज़ों की संरचना को परिभाषित करता है और प्रमाणीकरण से संबंधित व्यवहार को समाहित करता है। कम से कम, हम निम्नलिखित जैसी संपत्तियों को शामिल करेंगे: name, email और passwordऔर आवश्यकतानुसार हम टाइमस्टैम्प, भूमिकाएं या अन्य मेटाडेटा भी जोड़ सकते हैं।

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

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

Joi-आधारित सत्यापन सहायकों के संयोजन में, उपयोगकर्ता मॉडल पहचान से संबंधित हर चीज के लिए केंद्रीय हिस्सा बन जाता है: उपयोगकर्ता डेटा के स्वरूप का वर्णन करना, आने वाले पेलोड को मान्य करना और एपीआई के बाकी हिस्सों द्वारा उपयोग किए जाने वाले टोकन उत्पन्न करना।

यहां से, हम उपयोगकर्ता मॉडल, बीक्रिप्ट और जॉई का एक साथ उपयोग करके नए खाते पंजीकृत करने और मौजूदा उपयोगकर्ताओं को प्रमाणित करने के लिए जिम्मेदार मार्गों को लागू कर सकते हैं।

पंजीकरण मार्ग बनाना

पंजीकरण लॉजिक आमतौर पर एक रूट मॉड्यूल में मौजूद होता है जैसे /routes/users.jsजहां हम एक अंतिम बिंदु को परिभाषित करते हैं जैसे कि POST /api/users आने वाले पंजीकरण अनुरोधों को संभालने के लिए। यह रूट Joi का उपयोग करके पेलोड को मान्य करेगा, जांच करेगा कि ईमेल पहले से उपयोग में है या नहीं, पासवर्ड को हैश करेगा, उपयोगकर्ता बनाएगा और उसे डेटाबेस में सहेजेगा।

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

यदि ईमेल पहले से मौजूद नहीं है, तो हम एक बीक्रिप्ट सॉल्ट उत्पन्न करते हैं और पासवर्ड को हैश करते हैं, उपयोगकर्ता ऑब्जेक्ट में मूल पासवर्ड को उसके हैश किए गए संस्करण से बदल देते हैं। यह हैश्ड वैल्यू ही अंततः MongoDB में स्टोर होती है, जिससे संभावित डेटा लीक के प्रभाव को काफी हद तक सीमित किया जा सकता है।

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

एक बार पंजीकरण हो जाने के बाद, लॉगिन करने का सहायक मार्ग सत्यापन संबंधी उसी तर्क का पुन: उपयोग कर सकता है, जबकि क्रेडेंशियल को सत्यापित करने और टोकन जारी करने पर ध्यान केंद्रित करता है।

लॉगिन रूट और टोकन जनरेशन को लागू करना

लॉगिन प्रक्रिया को आमतौर पर इसमें संभाला जाता है /routes/auth.js, एक ऐसे एंडपॉइंट के साथ जैसे POST /api/auth जो अनुरोध निकाय में ईमेल और पासवर्ड प्राप्त करता है। यह रूट उपयोगकर्ता को प्रमाणित करने का प्रयास करने से पहले यह सुनिश्चित करने के लिए फिर से Joi का उपयोग करता है कि दोनों फ़ील्ड मौजूद हैं और ठीक से संरचित हैं।

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

सफल प्रमाणीकरण के क्षण में, हम उपयोगकर्ता मॉडल पर परिभाषित टोकन-उत्पन्न करने वाली विधि को कॉल करते हैं, जो उपयोगकर्ता के पहचानकर्ता (और संभवतः अन्य दावों) को एम्बेड करने वाला एक JWT बनाता है और इसे एक गुप्त कुंजी के साथ हस्ताक्षरित करता है। इस टोकन को फिर क्लाइंट को भेजा जा सकता है, अक्सर रिस्पॉन्स बॉडी या कस्टम हेडर में, जहां फ्रंटएंड या बाहरी उपभोक्ता इसे स्टोर करता है और भविष्य के अनुरोधों के लिए इसका पुन: उपयोग करता है।

क्लाइंट साइड के दृष्टिकोण से, संरक्षित एंडपॉइंट्स पर की जाने वाली प्रत्येक बाद की कॉल में यह JWT शामिल होगा। Authorization हेडर को बियरर टोकन के रूप में, जो कि बिल्कुल वही है जिसकी तलाश हमारा मिडलवेयर करेगा। सर्वर साइड पर, एक समर्पित प्रमाणीकरण मिडलवेयर होने से यह सुनिश्चित होता है कि हम प्रत्येक रूट में टोकन सत्यापन लॉजिक को दोहराते नहीं हैं।

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

राउट्स की सुरक्षा के लिए ऑथ मिडलवेयर का निर्माण

ऑथ मिडलवेयर, जिसे अक्सर लागू किया जाता है /middleware/auth.jsयह प्रमाणीकरण की आवश्यकता वाले किसी भी मार्ग के लिए द्वारपाल के रूप में कार्य करता है, और अनुरोधों को मार्ग हैंडलर तक पहुंचने से पहले ही रोक देता है। इसका मुख्य कार्य JWT को पढ़ना है। Authorization हेडर को सत्यापित करें और डिकोड किए गए पेलोड को बाद में उपयोग के लिए अनुरोध ऑब्जेक्ट में इंजेक्ट करें।

मिडिलवेयर सबसे पहले यह जांच करता है कि Authorization हेडर मौजूद है और अपेक्षित का पालन करता है Bearer <token> प्रारूप; यदि टोकन अनुपस्थित है या गलत तरीके से बना है, तो यह तुरंत एक अनधिकृत स्थिति कोड के साथ प्रतिक्रिया करता है। इससे यह सुनिश्चित होता है कि असुरक्षित अनुरोध गलती से भी सुरक्षित एंडपॉइंट्स तक न पहुंच जाएं।

जब कोई टोकन मौजूद होता है, तो मिडलवेयर कॉल करता है jwt.verify() (से jsonwebtoken लाइब्रेरी में टोकन और हस्ताक्षर के लिए उपयोग की जाने वाली गुप्त या सार्वजनिक कुंजी पास करना। यदि समय सीमा समाप्त होने, हस्ताक्षर बेमेल होने या किसी अन्य समस्या के कारण सत्यापन विफल हो जाता है, तो मिडलवेयर एक त्रुटि के साथ प्रतिक्रिया करता है; अन्यथा, यह डिकोड किए गए पेलोड को कैप्चर कर लेता है।

कई कार्यान्वयन इस डिकोड किए गए पेलोड को संलग्न करते हैं req.user या इसी तरह की कोई अन्य प्रॉपर्टी, ताकि डाउनस्ट्रीम रूट हैंडलर टोकन को दोबारा पार्स या सत्यापित किए बिना उपयोगकर्ता से संबंधित दावों तक पहुंच सकें। अंत में, मिडलवेयर कॉल करता है next() एक्सप्रेस पाइपलाइन में अगले फ़ंक्शन को नियंत्रण सौंपने के लिए।

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

JWT के साथ संरक्षित संसाधनों तक पहुंचना

प्रमाणीकरण लागू करने के बाद एक सामान्य उपयोग का मामला एक ऐसा रूट प्रदान करना है जो वर्तमान उपयोगकर्ता प्रोफ़ाइल या उपयोगकर्ताओं की सूची प्राप्त करता है, जो केवल वैध टोकन प्रस्तुत करने वाले कॉल करने वालों के लिए ही सुलभ होता है। उदाहरण के लिए, में /routes/users.jsवहाँ हो सकता है GET /api/users/me वह एंडपॉइंट जो लॉग-इन किए हुए उपयोगकर्ता के बारे में जानकारी लौटाता है।

इस रूट की सुरक्षा के लिए, हम ऑथेंटिकेशन मिडलवेयर को अटैच करते हैं ताकि इस पर आने वाले किसी भी अनुरोध में एक वैध JWT होना आवश्यक हो; अन्यथा, मिडलवेयर वास्तविक हैंडलर के निष्पादित होने से पहले ही अनुरोध को समाप्त कर देगा। क्योंकि डिकोड किया गया पेलोड पहले से ही जुड़ा हुआ है req.userहैंडलर टोकन से सीधे यूजर आईडी प्राप्त कर सकता है और तदनुसार डेटाबेस से क्वेरी कर सकता है।

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

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

इस बिंदु पर हमने अपने द्वारा संग्रहीत एक गुप्त कोड का उपयोग करके एक स्व-निहित JWT सेटअप को कवर किया है। .env न केवल फाइल, बल्कि कई प्रोडक्शन सिस्टम बाहरी ऑथराइजेशन सर्वर के साथ भी एकीकृत होते हैं और टोकन को मान्य करने के लिए JWKS एंडपॉइंट का उपयोग करते हैं; यहीं पर OAuth-सुरक्षित API के लिए एक्सप्रेस मिडलवेयर काम आता है।

Node.js में JWT को मान्य करने के लिए JWKS एंडपॉइंट का उपयोग करना

अधिक उन्नत आर्किटेक्चर में, विशेष रूप से वे जो OAuth 2.0 और OpenID Connect पर निर्भर करते हैं, Node.js API अक्सर JWT स्वयं उत्पन्न करने के बजाय एक बाहरी प्राधिकरण सर्वर द्वारा जारी किए गए एक्सेस टोकन प्राप्त करते हैं। इस मामले में, एपीआई को असममित कुंजियों, आमतौर पर आरएसए या ईसी, के साथ हस्ताक्षरित टोकन को मान्य करना होगा, जहां केवल प्राधिकरण सर्वर के पास निजी कुंजी होती है।

एक सामान्य समाधान यह है कि एक्सप्रेस मिडलवेयर लाइब्रेरी का उपयोग किया जाए जो ऑथराइजेशन सर्वर द्वारा उजागर किए गए कॉन्फ़िगर किए गए एंडपॉइंट से JSON वेब की सेट (JWKS) प्राप्त करती है। वह JWKS एंडपॉइंट सार्वजनिक कुंजियों को एक मानक प्रारूप में उजागर करता है, जिससे एपीआई को निजी कुंजियों को प्रबंधित किए बिना आने वाले JWT हस्ताक्षरों को सत्यापित करने की अनुमति मिलती है।

उदाहरण के लिए, आप एक पैकेज इंस्टॉल कर सकते हैं जैसे कि express-oauth-jwt और इसे JWKS URL के साथ कॉन्फ़िगर करें, जैसे https://idsvr.example.com/oauth/v2/oauth-anonymous/jwksऔर फिर मिडलवेयर को अपने Node.js API रूट्स में प्लग इन करें। एक बार एकीकृत हो जाने के बाद, मिडलवेयर स्वचालित रूप से अधिकांश निम्न-स्तरीय टोकन सत्यापन कार्यों को संभालता है।

उस कॉन्फ़िगरेशन के लागू होने के बाद, लाइब्रेरी खोज करती है kid यह JWT हेडर से (कुंजी आईडी) प्राप्त करता है, JWKS एंडपॉइंट से उपयुक्त सार्वजनिक कुंजी डाउनलोड करता है (यदि यह पहले से कैश में संग्रहीत नहीं है) और उस कुंजी का उपयोग करके हस्ताक्षर को सत्यापित करता है। यह टोकन की समाप्ति तिथि, जारीकर्ता, उपयोगकर्ता और अन्य मानक क्षेत्रों की भी जांच करता है, यह इस बात पर निर्भर करता है कि आप इसके विकल्पों को कैसे कॉन्फ़िगर करते हैं।

सफल सत्यापन के बाद, पार्स किया गया JWT और उसके दावे एक्सप्रेस पर उपलब्ध हो जाते हैं। request यह ऑब्जेक्ट आपके हैंडलर्स को प्राधिकरण और लॉगिंग उद्देश्यों के लिए स्कोप, उपयोगकर्ता पहचानकर्ता या कस्टम विशेषताओं का निरीक्षण करने में सक्षम बनाता है। यदि कुछ गलत होता है (उदाहरण के लिए, टोकन की समय सीमा समाप्त हो गई है या हस्ताक्षर मेल नहीं खाता है), तो मिडलवेयर उचित HTTP त्रुटि कोड के साथ प्रतिक्रिया करता है और उसमें कारण भी शामिल करता है। WWW-Authenticate हैडर.

आपके API में स्कोप, क्लेम और ऑथराइजेशन लॉजिक

एक बार जब आपका Node.js API किसी JWT पर भरोसा कर लेता है, चाहे उसने इसे सीधे साइन किया हो या JWKS-आधारित मिडलवेयर ने इसे मान्य किया हो, तो अगला कदम इसके क्लेम और स्कोप का उपयोग करके प्राधिकरण को लागू करना है। यहां आप साधारण प्रमाणीकरण से आगे बढ़कर उपयोगकर्ता को क्या करने की अनुमति है, इसके आधार पर पहुंच प्रदान करना या अस्वीकार करना शुरू करते हैं।

स्कोप आमतौर पर मोटे तौर पर दी गई अनुमतियों का प्रतिनिधित्व करते हैं, जैसे कि read:users or write:ordersऔर इन्हें आमतौर पर JWT में इस तरह के दावे के तहत शामिल किया जाता है। scope or scopes. एपीआई किसी विशिष्ट व्यावसायिक डेटा से संबंधित अनुरोध को संसाधित करने से पहले यह जांच कर सकता है कि आवश्यक दायरा मौजूद है या नहीं, और यदि वह अनुपस्थित है तो निषिद्ध प्रतिक्रिया लौटा सकता है।

इसी प्रकार, उपयोगकर्ता आईडी, ईमेल, भूमिका या किरायेदार की जानकारी जैसे दावे आपको अधिक सूक्ष्म नियम लागू करने की अनुमति देते हैं; उदाहरण के लिए, यह सुनिश्चित करना कि उपयोगकर्ता केवल अपने स्वयं के रिकॉर्ड तक ही पहुंच सकें या प्रशासनिक कार्यों को विशिष्ट भूमिकाओं तक सीमित करना। एक्सप्रेस में, कस्टम मिडलवेयर लिखना आसान है जो इन दावों की जांच करते हैं। req.user और नीतिगत जांच लागू करें।

एक्सप्रेस के लिए कुछ JWT सत्यापन लाइब्रेरी अपने विकल्पों के हिस्से के रूप में आवश्यक स्कोप की जांच करने के लिए अंतर्निर्मित हुक प्रदान करती हैं, जिससे प्रत्येक रूट या राउटर को एक विशिष्ट अनुमति सेट के साथ संबद्ध करना सरल हो जाता है। यह दृष्टिकोण प्राधिकरण संबंधी चिंताओं को रूट परिभाषाओं के निकट रखता है, जिससे पठनीयता और रखरखाव में सुधार होता है।

डिजाइन के दृष्टिकोण से, आम तौर पर JWT स्कोप और क्लेम को अपने कोड में जगह-जगह हार्ड-कोडेड स्ट्रिंग्स बिखेरने के बजाय एक डिक्लेरेटिव पॉलिसी के हिस्से के रूप में मानना ​​बेहतर होता है, ताकि विसंगतियों से बचा जा सके और आपके सुरक्षा मॉडल में भविष्य में होने वाले बदलावों को आसान बनाया जा सके।

JWT-सुरक्षित Node.js API का परीक्षण और समस्या निवारण

एक बार सब कुछ ठीक से जुड़ जाने के बाद, आप यह सुनिश्चित करने के लिए कि एक्सेस कंट्रोल अपेक्षा के अनुरूप काम कर रहा है, वैध JWT के साथ और उसके बिना अपने Node.js API को कॉल करके परीक्षण करना चाहेंगे। curl, HTTPie या Postman जैसे सरल उपकरण इसके लिए एकदम सही हैं, जो आपको हेडर और पेलोड आसानी से सेट करने की सुविधा देते हैं।

एक सामान्य परीक्षण प्रक्रिया में सबसे पहले लॉगिन एंडपॉइंट को कॉल करके टोकन प्राप्त करना और फिर संरक्षित रूट पर दूसरा अनुरोध भेजना शामिल होता है। Authorization: Bearer <token> हेडर सेट। यदि आपका कार्यान्वयन सही है, तो अधिकृत अनुरोध सफल होने चाहिए जबकि बिना टोकन वाले या अमान्य टोकन वाले कॉल अस्वीकार कर दिए जाने चाहिए।

जब JWKS एंडपॉइंट के साथ एकीकृत एक्सप्रेस JWT सत्यापन लाइब्रेरी का उपयोग किया जाता है, तो टोकन में किसी भी समस्या का संकेत अक्सर एक त्रुटि संदेश के साथ दिया जाता है। 401 Unauthorized प्रतिक्रिया और विस्तृत जानकारी में WWW-Authenticate प्रतिक्रिया शीर्षलेख। उदाहरण के लिए, यदि एक्सेस टोकन की समय सीमा समाप्त हो गई है, तो उस हेडर में आमतौर पर विशिष्ट त्रुटि कोड और विवरण दर्शाया जाएगा।

ये विस्तृत त्रुटि संदेश विकास और डिबगिंग के दौरान बहुत सहायक होते हैं, लेकिन आपको इस बात का ध्यान रखना चाहिए कि उत्पादन लॉग या प्रतिक्रियाओं में अत्यधिक संवेदनशील आंतरिक जानकारी लीक न हो। अक्सर यह एक अच्छा विचार होता है कि लॉगिंग को केंद्रीकृत किया जाए और कुछ संदेशों को छिपाया जाए या सामान्यीकृत किया जाए, जबकि ऑपरेटरों को समस्याओं का निदान करने के लिए पर्याप्त संदर्भ भी बनाए रखा जाए।

स्वचालित परीक्षण और मॉक किए गए JWT आपके आत्मविश्वास को और बढ़ा सकते हैं, जिससे आप यह सत्यापित कर सकते हैं कि रूट बदलने, स्कोप जोड़ने या मिडलवेयर लॉजिक को रिफैक्टर करने पर प्राधिकरण व्यवहार स्थिर रहता है।

इन सभी को मिलाकर देखें तो, एक Node.js API जो Express, MongoDB, bcrypt, Joi और JWT को जोड़ता है—और वैकल्पिक रूप से JWKS-आधारित सत्यापन लाइब्रेरी द्वारा समर्थित है—आपको एंडपॉइंट्स को सुरक्षित करने के लिए एक मजबूत आधार प्रदान करता है, साथ ही आधुनिक फ्रंटएंड फ्रेमवर्क, मोबाइल ऐप्स और एंटरप्राइज आइडेंटिटी प्रोवाइडर्स के साथ एकीकृत होने के लिए पर्याप्त लचीलापन भी बनाए रखता है।