- JWT नोड.जेएस एपीआयसाठी स्टेटलेस, स्केलेबल ऑथेंटिकेशन सक्षम करते, एक्सप्रेस रूट्स आणि मिडलवेअरसह सहजतेने एकत्रित करते.
- एक्सप्रेस, मुंगूस, जेसनवेबटोकन, बीक्रिप्ट, जोई आणि डोटेनव्ह यांचे संयोजन वापरकर्ता प्रमाणीकरण प्रवाहांसाठी एक सुरक्षित, मॉड्यूलर पाया तयार करते.
- JWKS-आधारित JWT प्रमाणीकरण Node.js API ला बाह्य ऑथोरायझेशन सर्व्हरवर विश्वास ठेवू देते आणि स्कोप आणि दावे स्वच्छपणे लागू करू देते.
- JWT-संरक्षित एंडपॉइंट्स मजबूत ठेवण्यासाठी संपूर्ण प्रमाणीकरण, स्पष्ट त्रुटी हाताळणी आणि संरचित चाचणी आवश्यक आहे.
जर तुम्ही Node.js वापरून API बनवत असाल, तर JWT वापरून योग्य प्रमाणीकरण जोडणे ही सुरुवातीला भीतीदायक वाटू शकते, परंतु प्रत्यक्षात तसे असण्याची गरज नाही. काही निवडक ग्रंथालये, स्पष्ट रचना आणि प्रमाणीकरण आणि सुरक्षिततेबाबत काही चांगल्या पद्धतींसह, तुम्ही तुमचे अंतिम बिंदू संरक्षित करू शकता आणि तरीही तुमचा कोडबेस स्वच्छ आणि देखभाल करण्यायोग्य ठेवू शकता.
या मार्गदर्शकामध्ये आपण एक्सप्रेस, मोंगोडीबी आणि jsonwebtoken, bcrypt, Joi आणि dotenv सारख्या साधनांचा वापर करून Node.js API मध्ये JWT-आधारित प्रमाणीकरण कसे अंमलात आणायचे ते पाहू आणि अधिक एंटरप्राइझ-ओरिएंटेड परिस्थितींमध्ये ऑथोरायझेशन सर्व्हरवरून JWKS एंडपॉइंट वापरून टोकन कसे प्रमाणित करायचे ते देखील पाहू. तुम्ही प्रकल्पाची रचना कशी डिझाइन करायची, मॉडेल्स आणि मार्ग कसे तयार करायचे, टोकन कसे तयार करायचे आणि पडताळायचे, ऑथ मिडलवेअर कसे जोडायचे आणि सर्वकाही एकत्र कसे करायचे ते शिकाल जेणेकरून फक्त ऑथेंटिकेटेड वापरकर्तेच संरक्षित संसाधनांपर्यंत पोहोचू शकतील.
तुमच्या Node.js API मध्ये JSON वेब टोकन (JWT) काय आणतात
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 वर अवलंबून राहू.
स्वच्छ फोल्डर लेआउटमुळे प्रकल्प वाढत असताना गोष्टी समजण्यासारख्या राहण्यास मदत होते, म्हणून सर्वकाही एकाच फाइलमध्ये डंप करण्याऐवजी आपण कॉन्फिगरेशन, डेटाबेस, मॉडेल्स, रूट्स आणि मिडलवेअरसाठी स्वतंत्र मॉड्यूल्ससह एक मूलभूत रचना परिभाषित करू. या मॉड्यूलर दृष्टिकोनामुळे प्रमाणीकरण प्रवाहाच्या विशिष्ट भागांची युनिट चाचणी करणे देखील सोपे होते.
उच्च स्तरावर, API वापरकर्ता नोंदणी आणि लॉगिनसाठी REST एंडपॉइंट्सचा संच उघड करेल, तसेच किमान एक संरक्षित संसाधन जो केवळ विनंती शीर्षलेखांमध्ये वैध JWT सह पोहोचू शकतो. वाटेत आपण रिक्वेस्ट पेलोड्स कसे प्रमाणित करायचे, पासवर्ड हॅश कसे करायचे आणि त्यांची तुलना कशी करायची, युजर आयडी एम्बेड करणारे टोकन कसे तयार करायचे आणि इनकमिंग कॉल्सवर टोकन तपासणारे ऑथ मिडलवेअर कसे एकत्रित करायचे ते पाहू.
हाच पॅटर्न अधिक जटिल सिस्टीममध्ये वाढवता येतो, ज्यामध्ये बाह्य ऑथोरायझेशन सर्व्हरशी एकत्रित होणाऱ्या आणि OAuth 2.0 क्लायंटकडून येणारे अॅक्सेस टोकन प्रमाणित करण्यासाठी JWKS एंडपॉइंट्स वापरणाऱ्या सिस्टीमचा समावेश आहे. जेव्हा तुम्ही ओळख प्रदात्यांना प्रमाणीकरण सोपवता किंवा अनेक सेवांमध्ये एकाच साइन-ऑनला समर्थन देण्याची आवश्यकता असते तेव्हा ती दुसरी परिस्थिती विशेषतः सामान्य असते.
अंमलबजावणीच्या गुंतागुंतीमध्ये जाण्यापूर्वी, आपण ज्या वातावरणावर अवलंबून राहू त्या घटकांची रूपरेषा काढूया आणि Node.js मध्ये सुरक्षित JWT हाताळणीसाठी प्रत्येक अवलंबित्व का महत्त्वाचे आहे.
Node.js मध्ये JWT प्रमाणीकरणासाठी मुख्य अवलंबित्वे
एक्सप्रेस हा अनेक Node.js API चा कणा आहे, जो राउटिंग, मिडलवेअर आणि HTTP हाताळणीसाठी किमान परंतु लवचिक फ्रेमवर्क प्रदान करतो. आमच्या बाबतीत, एक्सप्रेस हे प्लॅटफॉर्म म्हणून काम करेल जिथे आम्ही मार्गांची नोंदणी करतो जसे की /api/users or /api/auth, आणि जिथे आपण संवेदनशील एंडपॉइंट्सचे संरक्षण करणारे JWT व्हेरिफिकेशन मिडलवेअर प्लग इन करतो.
मुंगूस ही एक ऑब्जेक्ट डेटा मॉडेलिंग (ODM) लायब्ररी आहे जी कच्च्या प्रश्नांसह थेट काम करण्याऐवजी स्कीमा आणि मॉडेल्सद्वारे मोंगोडीबीशी संवाद साधणे सोपे करते. आपण ते परिभाषित करण्यासाठी वापरू a User नाव, ईमेल आणि पासवर्ड सारख्या गुणधर्मांसह मॉडेल तयार करणे आणि डेटाबेसमधून हे दस्तऐवज सुरक्षित पद्धतीने टिकवून ठेवणे किंवा पुनर्प्राप्त करणे.
The jsonwebtoken गुप्त किंवा सार्वजनिक की वापरून JWT तयार करण्यासाठी आणि पडताळण्यासाठी Node.js मध्ये लायब्ररी ही मानक निवड आहे. लॉगिन दरम्यान आम्ही वापरकर्ता आयडी (आणि आम्हाला आवश्यक असलेले इतर कोणतेही दावे) एम्बेड केलेल्या टोकनवर स्वाक्षरी करू आणि नंतर आम्ही संरक्षित मार्गांवर ते टोकन सत्यापित करू, अवैध, विकृत किंवा कालबाह्य टोकन असलेली कोणतीही विनंती नाकारू.
पासवर्ड सुरक्षेसाठी, bcrypt चा वापर स्टोरेजपूर्वी प्लेन टेक्स्ट पासवर्ड हॅश करण्यासाठी आणि ऑथेंटिकेशन दरम्यान प्रदान केलेल्या क्रेडेन्शियल्सची हॅश केलेल्या मूल्यांशी तुलना करण्यासाठी केला जातो. हे अत्यंत महत्त्वाचे आहे, कारण कच्चे पासवर्ड साठवणे किंवा कमकुवत हॅशिंग धोरणे वापरणे तुमच्या वापरकर्त्यांना डेटाबेस लीक झाल्यास मोठ्या धोक्यांना तोंड देते, तर bcrypt एक सिद्ध, युद्ध-चाचणी केलेले समाधान प्रदान करते.
API सीमेवर येणारा डेटा सत्यापित करण्यात, ऑब्जेक्ट्ससाठी स्कीमाचे वर्णन करण्यात आणि प्रत्येक रिक्वेस्ट पेलोड अपेक्षेनुसार वागतो की नाही हे तपासण्यात Joi मोठी भूमिका बजावते. उदाहरणार्थ, आपण असे परिभाषित करू शकतो की ईमेल योग्यरित्या फॉरमॅट केलेला असावा, पासवर्डची लांबी किमान असावी आणि काही फील्ड अनिवार्य असतील, ज्यामुळे आपल्या लॉजिकमध्ये वाईट किंवा दुर्भावनापूर्ण इनपुट जाण्याची शक्यता लक्षणीयरीत्या कमी होते.
शेवटी, dotenv आपल्याला a वरून पर्यावरण व्हेरिएबल्स लोड करण्याची परवानगी देते .env फाइल, जेडब्ल्यूटी साइनिंग की, डेटाबेस यूआरएल किंवा सोर्स कोडच्या बाहेर कॉन्फिगरेशन सेटिंग्ज सारखी गुपिते ठेवणे. हे संवेदनशील मूल्यांचे हार्डकोडिंग टाळण्यास मदत करते आणि विकास, स्टेजिंग आणि उत्पादन कॉन्फिगरेशनमध्ये चांगले पृथक्करण करण्यास प्रोत्साहन देते.
एक्सप्रेस सर्व्हर आणि वातावरण सेट अप करत आहे
आमच्या API चा प्रवेश बिंदू सहसा एक असतो 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). हे वेगळेपणा प्रमाणीकरणाशी संबंधित मार्ग आणि वापरकर्ता व्यवस्थापन समस्यांना API च्या इतर भागांपासून वेगळे ठेवते.
वातावरण कॉन्फिगर केलेले आणि एक्सप्रेस चालू असताना, पुढील काम म्हणजे एका समर्पित मॉड्यूलद्वारे मोंगोडीबी डेटाबेसला जोडणे, बहुतेकदा db.js फाइल, जिथे आपण कनेक्शन लॉजिक सेट करतो.
मोंगूससह मोंगोडीबी कॉन्फिगर करणे
मध्ये db.js मॉड्यूल, आम्ही सामान्यतः मुंगूस आयात करतो आणि कॉल करतो mongoose.connect() वातावरणीय चलात साठवलेल्या MongoDB कनेक्शन स्ट्रिंगसह. उत्पादन वातावरणात स्थिर वर्तन सुनिश्चित करण्यासाठी आम्ही रीट्री लॉजिक, युनिफाइड टोपोलॉजी किंवा कनेक्शन पूलिंगसारखे पर्याय देखील कॉन्फिगर करू शकतो.
कनेक्शन यशस्वी झाल्यावर संदेश लॉग करणे आणि त्रुटींना सुबकपणे हाताळणे सामान्य आहे जेणेकरून जर MongoDB पोहोचण्यायोग्य नसेल, तर API स्पष्ट निदानांसह सुरू होते. पूर्ण अनुप्रयोगात, डेटाबेस कनेक्शन अयशस्वी झाल्यास तुम्ही प्रक्रियेतून बाहेर पडण्याचा पर्याय देखील निवडू शकता, कारण बरेच मार्ग त्यावर अवलंबून असतात.
एकदा का db.js फाइल लागू केली आहे, आम्ही ती येथून आयात करतो index.js आणि अॅप्लिकेशन स्टार्टअप दरम्यान लवकर कॉल करा, कोणत्याही विनंतीवर प्रक्रिया करण्यापूर्वी आमचा API डेटाबेसशी कनेक्ट केलेला आहे याची खात्री करा. हे पृथक्करण कॉन्फिगरेशन वेगळे आणि पुन्हा वापरण्यायोग्य ठेवते, तर index.js एक्सप्रेसच्या चिंतांवर लक्ष केंद्रित करते.
डेटाबेस वायर्ड इन करून, आपण आपल्या ऑथेंटिकेशन सिस्टमला चालना देणाऱ्या डेटाचे मॉडेलिंग करू शकतो, जे वापरकर्ता स्कीमा आणि मॉडेलच्या व्याख्येपासून सुरू होते.
JWT सपोर्टसह वापरकर्ता मॉडेल तयार करणे
The User मॉडेल, सहसा ठेवलेले /models/user.js, MongoDB मध्ये संग्रहित वापरकर्ता दस्तऐवजांची रचना परिभाषित करते आणि प्रमाणीकरणाशी संबंधित वर्तन समाविष्ट करते. कमीत कमी, आम्ही अशा गुणधर्मांचा समावेश करू जसे की name, email आणि password, आणि गरजेनुसार आम्ही टाइमस्टॅम्प, भूमिका किंवा इतर मेटाडेटा देखील जोडू शकतो.
एक सामान्य नमुना म्हणजे ईमेल फील्ड अद्वितीय आणि आवश्यक म्हणून चिन्हांकित करणे, जेणेकरून कोणतेही दोन वापरकर्ते एकाच ईमेल पत्त्यासह नोंदणी करू शकत नाहीत याची खात्री होईल. त्याचप्रमाणे, पासवर्ड फील्ड प्लेन टेक्स्ट व्हॅल्यू साठवणार नाही; त्याऐवजी, आम्ही नोंदणीच्या वेळी किंवा वापरकर्ता त्यांचे क्रेडेन्शियल्स अपडेट करतो तेव्हा तयार केलेला bcrypt हॅश साठवू.
एक मनोरंजक आणि अतिशय व्यावहारिक डिझाइन निर्णय म्हणजे JWT जनरेट करण्यासाठी वापरकर्ता स्कीमावर एक पद्धत जोडणे, जी वापरकर्त्याचा आयडी पेलोड म्हणून घेते आणि वातावरणात परिभाषित केलेल्या गुप्त कीसह त्यावर स्वाक्षरी करते. लॉगिन दरम्यान त्या वापरकर्त्यासाठी विशिष्ट टोकन तयार करण्यासाठी ही पद्धत कॉल केली जाऊ शकते आणि ती टोकन जनरेशन लॉजिकला ओळख डेटाच्या मालकीच्या मॉडेलसह सह-स्थित ठेवते.
जॉई-आधारित व्हॅलिडेशन हेल्पर्सच्या संयोजनात, वापरकर्ता मॉडेल ओळखीशी संबंधित प्रत्येक गोष्टीसाठी मध्यवर्ती भाग बनते: वापरकर्ता डेटाच्या आकाराचे वर्णन करणे, येणारे पेलोड प्रमाणित करणे आणि उर्वरित API द्वारे वापरलेले टोकन तयार करणे.
येथून, आम्ही वापरकर्ता मॉडेल, bcrypt आणि Joi यांचा वापर करून नवीन खाती नोंदणी करण्यासाठी आणि विद्यमान वापरकर्त्यांना प्रमाणित करण्यासाठी जबाबदार असलेल्या मार्गांची अंमलबजावणी करू शकतो.
नोंदणी मार्ग तयार करणे
नोंदणी लॉजिक सहसा रूट मॉड्यूलमध्ये राहतो जसे की /routes/users.js, जिथे आपण एक अंत्यबिंदू परिभाषित करतो जसे की POST /api/users येणाऱ्या साइन-अप विनंत्या हाताळण्यासाठी. हा मार्ग Joi वापरून पेलोडची पडताळणी करेल, ईमेल आधीच वापरात आहे का ते तपासेल, पासवर्ड हॅश करेल, वापरकर्ता तयार करेल आणि डेटाबेसमध्ये सेव्ह करेल.
काहीही टिकवून ठेवण्यापूर्वी, आपण जॉई स्कीमा वापरू शकतो जो अनिवार्य नाव आणि ईमेल, योग्य ईमेल फॉरमॅट आणि किमान पासवर्ड लांबी यासारख्या आवश्यकतांची अंमलबजावणी करतो. जर प्रमाणीकरण अयशस्वी झाले, तर मार्ग योग्य त्रुटी स्थिती कोड आणि संदेशासह प्रतिसाद देतो, ज्यामुळे विकृत डेटा व्यवसाय तर्कापर्यंत पोहोचण्यापासून रोखला जातो.
जर ईमेल आधीच अस्तित्वात नसेल, तर आम्ही bcrypt सॉल्ट जनरेट करतो आणि पासवर्ड हॅश करतो, रॉ पासवर्डला युजर ऑब्जेक्टमध्ये त्याच्या हॅश केलेल्या आवृत्तीने बदलतो. हे हॅश केलेले मूल्य शेवटी मोंगोडीबीमध्ये साठवले जाते, जे संभाव्य डेटा उल्लंघनाच्या परिणामांना लक्षणीयरीत्या मर्यादित करते.
नवीन वापरकर्ता सेव्ह केल्यानंतर, काही अंमलबजावणी तात्काळ JWT जनरेट करणे आणि ते प्रतिसाद शीर्षलेख किंवा मुख्य भागामध्ये परत करणे देखील निवडतात, जेणेकरून नोंदणीनंतर लगेच वापरकर्त्याला प्रमाणीकृत मानले जाईल. सिस्टमच्या सुरक्षा आवश्यकतांवर अवलंबून, इतर API ला वेगळ्या लॉगिन चरणाची आवश्यकता असू शकते.
एकदा नोंदणी सुरू झाली की, लॉग इन करण्यासाठीचा कंपॅनियन रूट क्रेडेन्शियल्स पडताळणी आणि टोकन जारी करण्यावर लक्ष केंद्रित करताना समान प्रमाणीकरण तर्काचा पुन्हा वापर करू शकतो.
लॉगिन रूट आणि टोकन जनरेशनची अंमलबजावणी
लॉगिन फ्लो सामान्यतः यामध्ये हाताळला जातो /routes/auth.js, सारख्या शेवटच्या बिंदूसह POST /api/auth ज्याला रिक्वेस्ट बॉडीमध्ये ईमेल आणि पासवर्ड मिळतो. वापरकर्त्याचे प्रमाणीकरण करण्याचा प्रयत्न करण्यापूर्वी दोन्ही फील्ड उपस्थित आहेत आणि योग्यरित्या संरचित आहेत याची खात्री करण्यासाठी हा मार्ग पुन्हा Joi वापरतो.
प्रमाणीकरणानंतर, रूट दिलेल्या ईमेल असलेल्या वापरकर्त्यासाठी डेटाबेसची चौकशी करतो आणि जर त्याला एखादा ईमेल सापडला तर तो bcrypt चा वापर करून संग्रहित हॅशशी प्रदान केलेल्या पासवर्डची तुलना करतो. जर तुलना अयशस्वी झाली, तर विनंती योग्य त्रुटी संदेशासह नाकारली जाते; अन्यथा, आम्ही टोकन जारी करण्याकडे जाऊ.
यशस्वी प्रमाणीकरणाच्या क्षणी, आम्ही वापरकर्ता मॉडेलवर परिभाषित केलेल्या टोकन-जनरेटिंग पद्धतीला कॉल करतो, जी वापरकर्त्याच्या ओळखकर्त्याला (आणि शक्यतो इतर दाव्यांसह) एम्बेड करून JWT तयार करते आणि त्यावर गुप्त की सह स्वाक्षरी करते. हे टोकन नंतर क्लायंटला पाठवले जाऊ शकते, बहुतेकदा प्रतिसाद बॉडीमध्ये किंवा कस्टम हेडरमध्ये, जिथे फ्रंटएंड किंवा बाह्य ग्राहक भविष्यातील विनंत्यांसाठी ते संग्रहित करतात आणि पुन्हा वापरतात.
क्लायंट बाजूच्या दृष्टिकोनातून, संरक्षित एंडपॉइंट्सवर येणाऱ्या प्रत्येक कॉलमध्ये हे JWT समाविष्ट असेल Authorization हेडरला बेअरर टोकन म्हणून वापरतो, जे आमचे मिडलवेअर नेमके हेच शोधेल. सर्व्हरच्या बाजूने, समर्पित ऑथ मिडलवेअर असल्याने आम्ही प्रत्येक रूटमध्ये टोकन व्हेरिफिकेशन लॉजिकची पुनरावृत्ती करणार नाही याची खात्री होते.
त्या मिडलवेअरमध्ये जाण्यापूर्वी, हे लक्षात घेण्यासारखे आहे की हाच पॅटर्न रिएक्ट किंवा इतर SPA फ्रेमवर्कसह उत्तम प्रकारे एकत्रित होतो, जिथे JWT-आधारित फ्लो सामान्यतः प्रमाणीकरण आणि साध्या अधिकृततेच्या गरजांसाठी वापरले जातात.
मार्गांचे संरक्षण करण्यासाठी ऑथ मिडलवेअर तयार करणे
ऑथ मिडलवेअर, बहुतेकदा यामध्ये अंमलात आणले जाते /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, हँडलर टोकनमधून थेट वापरकर्ता आयडी मिळवू शकतो आणि त्यानुसार डेटाबेसची चौकशी करू शकतो.
हे पॅटर्न हे सुनिश्चित करते की व्यवसाय लॉजिकला प्रमाणीकरण कसे केले गेले याची पर्वा नाही; ते फक्त सत्यापित पेलोडच्या उपस्थितीवर विश्वास ठेवते आणि डोमेन डेटा आणण्यावर किंवा सुधारण्यावर लक्ष केंद्रित करते. अधिक प्रगत सेटअपमध्ये, तुम्ही टोकनमध्ये भूमिका, परवानग्या किंवा स्कोप एम्बेड करू शकता आणि हँडलर्समध्ये अधिकृतता तपासणी चालविण्यासाठी त्यांचा वापर करू शकता.
ग्राहकांच्या दृष्टिकोनातून, कॉलर प्रथम टोकन मिळविण्यासाठी लॉगिन एंडपॉइंटवर क्लिक करेल आणि नंतर या संरक्षित एंडपॉइंट्सच्या पुढील विनंत्यांमध्ये ते समाविष्ट करेल, बहुतेकदा React, मोबाइल अॅप किंवा बॅकएंड-टू-बॅकएंड इंटिग्रेशन सारख्या SPA वरून. टोकन कालबाह्य झाल्यावर किंवा अवैध असताना त्रुटी संदेश स्पष्ट असल्यास एकूण अनुभव सुरळीत असतो.
या टप्प्यावर आम्ही आमच्या मध्ये साठवलेल्या गुपिताचा वापर करून एक स्वयंपूर्ण JWT सेटअप कव्हर केला आहे .env फाइल, परंतु अनेक उत्पादन प्रणाली बाह्य ऑथोरायझेशन सर्व्हरसह देखील एकत्रित होतात आणि टोकन प्रमाणित करण्यासाठी JWKS एंडपॉइंट्स वापरतात; येथेच OAuth-सुरक्षित API साठी एक्सप्रेस मिडलवेअर कार्यात येते.
Node.js मध्ये JWTs प्रमाणित करण्यासाठी JWKS एंडपॉइंट वापरणे
अधिक प्रगत आर्किटेक्चरमध्ये, विशेषतः OAuth 2.0 आणि OpenID Connect वर अवलंबून असलेल्या आर्किटेक्चरमध्ये, Node.js API बहुतेकदा JWT स्वतः जनरेट करण्याऐवजी बाह्य ऑथोरायझेशन सर्व्हरद्वारे जारी केलेले अॅक्सेस टोकन प्राप्त करतात. या प्रकरणात, API ने असममित की, सामान्यत: RSA किंवा EC सह स्वाक्षरी केलेले टोकन प्रमाणित करणे आवश्यक आहे, जिथे फक्त ऑथोरायझेशन सर्व्हरकडे खाजगी की असते.
एक सामान्य उपाय म्हणजे एक्सप्रेस मिडलवेअर लायब्ररी वापरणे जी ऑथोरायझेशन सर्व्हरद्वारे उघड केलेल्या कॉन्फिगर केलेल्या एंडपॉइंटमधून JSON वेब की सेट्स (JWKS) मिळवते. तो JWKS एंडपॉइंट पब्लिक कीज एका मानक स्वरूपात उघड करतो, ज्यामुळे API ला खाजगी कीज व्यवस्थापित न करता येणारे 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. विशिष्ट व्यवसाय डेटाला स्पर्श करणाऱ्या विनंतीवर प्रक्रिया करण्यापूर्वी API आवश्यक स्कोप उपस्थित आहे की नाही हे तपासू शकते, जर ती गहाळ असेल तर निषिद्ध प्रतिसाद परत करू शकते.
त्याचप्रमाणे, वापरकर्ता आयडी, ईमेल, भूमिका किंवा भाडेकरू माहिती यासारखे दावे तुम्हाला अधिक सूक्ष्म नियम लागू करण्यास अनुमती देतात; उदाहरणार्थ, वापरकर्त्यांना फक्त त्यांच्या स्वतःच्या रेकॉर्डमध्ये प्रवेश मिळावा याची खात्री करणे किंवा प्रशासकीय कृती विशिष्ट भूमिकांपुरत्या मर्यादित करणे. एक्सप्रेसमध्ये, या दाव्यांचे परीक्षण करणारे कस्टम मिडलवेअर लिहिणे सोपे आहे req.user आणि पॉलिसी तपासणी लागू करा.
एक्सप्रेससाठी काही JWT व्हॅलिडेशन लायब्ररी त्यांच्या पर्यायांचा भाग म्हणून आवश्यक स्कोप तपासण्यासाठी बिल्ट-इन हुक देतात, ज्यामुळे प्रत्येक रूट किंवा राउटरला विशिष्ट परवानगी संचाशी जोडणे सोपे होते. हा दृष्टिकोन अधिकृततेच्या चिंतांना मार्गाच्या व्याख्येजवळ ठेवतो, ज्यामुळे वाचनीयता आणि देखभालक्षमता सुधारते.
डिझाइनच्या दृष्टिकोनातून, तुमच्या कोडमध्ये हार्ड-कोडेड स्ट्रिंग्स पसरवण्याऐवजी, JWT स्कोप्स आणि दाव्यांचा घोषणात्मक धोरणाचा भाग म्हणून वापर करणे सामान्यतः चांगले असते, जेणेकरून विसंगती टाळता येतील आणि तुमच्या सुरक्षा मॉडेलमध्ये भविष्यातील बदल सुलभ होतील.
JWT-संरक्षित Node.js API ची चाचणी आणि समस्यानिवारण
एकदा सर्वकाही वायर्ड झाले की, अॅक्सेस कंट्रोल अपेक्षेप्रमाणे वागते याची खात्री करण्यासाठी तुम्हाला वैध JWT सह आणि त्याशिवाय तुमचा Node.js API कॉल करण्याची चाचणी घ्यावी लागेल. कर्ल, HTTPie किंवा पोस्टमन सारखी साधी साधने यासाठी परिपूर्ण आहेत, ज्यामुळे तुम्ही हेडर आणि पेलोड सहजपणे सेट करू शकता.
एका सामान्य चाचणी प्रवाहात प्रथम टोकन मिळविण्यासाठी लॉगिन एंडपॉइंटवर कॉल करणे आणि नंतर संरक्षित मार्गावर दुसरी विनंती पाठवणे समाविष्ट असते. Authorization: Bearer <token> शीर्षलेख संच. जर तुमची अंमलबजावणी योग्य असेल, तर अधिकृत विनंत्या यशस्वी होतील तर टोकनशिवाय किंवा अवैध टोकन असलेले कॉल नाकारले जातील.
JWKS एंडपॉइंटसह एकत्रित केलेली एक्सप्रेस JWT व्हॅलिडेशन लायब्ररी वापरताना, टोकनमधील कोणतीही समस्या बहुतेकदा a ने सिग्नल केली जाते 401 Unauthorized प्रतिसाद आणि तपशीलवार माहिती WWW-Authenticate प्रतिसाद शीर्षलेख. उदाहरणार्थ, जर अॅक्सेस टोकन कालबाह्य झाले असेल, तर ते शीर्षलेख सामान्यतः विशिष्ट त्रुटी कोड आणि वर्णन दर्शवेल.
हे तपशीलवार त्रुटी संदेश विकास आणि डीबगिंग दरम्यान खूप उपयुक्त आहेत, परंतु तुम्ही उत्पादन लॉग किंवा प्रतिसादांमध्ये अतिसंवेदनशील अंतर्गत माहिती लीक होणार नाही याची काळजी घेतली पाहिजे. ऑपरेटर्सना समस्यांचे निदान करण्यासाठी पुरेसा संदर्भ ठेवत असताना लॉगिंगचे केंद्रीकरण करणे आणि काही संदेश लपवणे किंवा सामान्यीकरण करणे ही अनेकदा चांगली कल्पना असते.
ऑटोमेटेड चाचण्या आणि मॉक केलेले JWT तुमचा आत्मविश्वास आणखी वाढवू शकतात, ज्यामुळे तुम्ही मार्ग बदलता, स्कोप जोडता किंवा मिडलवेअर लॉजिक रिफॅक्टर करता तेव्हा ऑथोरायझेशन वर्तन स्थिर आहे हे पडताळता येते.
हे सर्व एकत्र ठेवून, एक्सप्रेस, मोंगोडीबी, बीक्रिप्ट, जोई आणि जेडब्ल्यूटी यांचे संयोजन करणारा एक नोड.जेएस एपीआय - पर्यायीपणे जेडब्ल्यूकेएस-आधारित व्हॅलिडेशन लायब्ररीद्वारे समर्थित - तुम्हाला एंडपॉइंट्स सुरक्षित करण्यासाठी एक मजबूत पाया देतो आणि त्याचबरोबर आधुनिक फ्रंटएंड फ्रेमवर्क, मोबाइल अॅप्स आणि एंटरप्राइझ ओळख प्रदात्यांसह एकत्रित होण्यासाठी पुरेसे लवचिक राहतो.
