JSON वेब टोकन क्या है?
<पी> JSON वेब टोकन इंटरनेट इंजीनियरिंग टास्क फोर्स (IETF) द्वारा परिभाषित एक इंटरनेट मानक है:"दो पक्षों के बीच स्थानांतरित किए जाने वाले दावों का प्रतिनिधित्व करने का संक्षिप्त, URL-सुरक्षित साधन"। <पी> यहां, "दावे" का तात्पर्य किसी विषय के बारे में जानकारी के मिश्रित टुकड़ों से है। एक दावे को एक नाम/मूल्य जोड़ी के रूप में दर्शाया जाता है जहां नाम हमेशा एक स्ट्रिंग होता है, और मान कोई भी JSON मान हो सकता है।JSON वेब टोकन की मूल संरचना
<पी> जेडब्ल्यूटी की पेचीदगियों में विस्तार करना इस पोस्ट के दायरे से बाहर है। जैसा कि कहा गया है, यह JWTs की संरचना को जानने लायक है। <पी> JWT में तीन भाग होते हैं, जो एक अवधि से अलग होते हैं:हेडर, पेलोड और हस्ताक्षर। <पी> एक उदाहरण JWT निम्नलिखित जैसा दिख सकता है: <पी> पठनीयता के लिए, टोकन का प्रत्येक भाग एक नई लाइन पर शुरू होता है। व्यवहार में, हिस्से जुड़ जाते हैं। <पी> यह टोकन सर्वर से क्लाइंट को भेजा जाता है। क्लाइंट स्वयं को पहचानने और अनुरोध संसाधित करने के लिए सर्वर को टोकन भेजता है। <पी> पहले भाग, हेडर में टोकन उत्पन्न करने के लिए उपयोग किए जाने वाले एल्गोरिदम और टोकन के प्रकार के बारे में जानकारी शामिल है। यदि डिकोड किया जाए, तो हमें कुछ इस प्रकार मिलता है: <पी> दूसरे भाग, पेलोड, में उपयोगकर्ता के बारे में दावों का एक सेट शामिल है। ज्यादातर मामलों में, यह क्लाइंट-सर्वर सेटअप में क्लाइंट होगा, और यह इस तरह दिख सकता है: <पी> हस्ताक्षर (हस्ताक्षरित JWT का अंतिम भाग) टोकन को मान्य करता है। यह Base64url एन्कोडिंग - RFC 4648 का उपयोग करके हेडर और पेलोड को एन्कोड करके और फिर उन्हें एक अवधि विभाजक के साथ जोड़कर उत्पन्न किया जाता है। <पी> मूलतः, हस्ताक्षर बिट के साथ क्या होता है यह है: <पी>HMAC_SHA256 SHA-256 हैश फ़ंक्शन से निर्मित एक प्रकार का कुंजीयुक्त हैश एल्गोरिदम है जो हस्ताक्षर को हैश करता है। क्रिप्टोग्राफ़िक एल्गोरिथम का चयन "alg": "HS256" से होता है शीर्षलेख में. यदि टोकन अहस्ताक्षरित है, तो इसमें हस्ताक्षर के बिना केवल हेडर और पेलोड होगा। JWTs बनाम। आपके रूबी ऐप के लिए अन्य प्रमाणीकरण विधियाँ
<पी> JSON वेब टोकन, जैसा कि नाम से पता चलता है, टोकन-आधारित हैं। स्पेक्ट्रम के दूसरे छोर पर, हमारे पास सत्र-आधारित प्रमाणीकरण है:उपयोगकर्ताओं को प्रमाणित करने का एक अधिक पारंपरिक तरीका। सत्र-आधारित प्रमाणीकरण का प्रवाह टोकन-आधारित प्रमाणीकरण से काफी भिन्न है। <पी> सत्र-आधारित प्रमाणीकरण का प्रवाह निम्न जैसा दिख सकता है:- एक उपयोगकर्ता या ग्राहक एक अनुरोध भेजता है जिसमें उपयोगकर्ता क्रेडेंशियल शामिल होते हैं।
- सर्वर उपयोगकर्ता को प्रमाणित करता है, एक सत्र संग्रहीत करता है, और ब्राउज़र में कुकी के रूप में संग्रहीत एक सत्र आईडी लौटाता है।
- क्लाइंट अपने बाद के अनुरोधों के साथ कुकीज़ को सर्वर पर भेजता है।
- सर्वर प्रस्तुत सत्र जानकारी का निरीक्षण करता है और, यदि मान्य है, तो उपयोगकर्ता को प्रमाणित करता है और क्लाइंट को अनुरोधित जानकारी लौटाता है।
प्रमाणीकरण के लिए JWT का उपयोग क्यों करें?
<पी> कार्यान्वयन में अपेक्षाकृत सरल होने के अलावा, प्रमाणीकरण के लिए JSON वेब टोकन का उपयोग करने के कुछ अन्य फायदे भी हैं, जैसे:- वे राज्यविहीन हैं , जिसका अर्थ है कि एक सत्र स्टोर आवश्यक नहीं है। टोकन में ही उपयोगकर्ता की सारी जानकारी होती है, इसलिए प्रत्येक अनुरोध पर जानकारी के लिए डेटाबेस या प्रमाणीकरण सर्वर से पूछताछ करने की कोई आवश्यकता नहीं है।
- JWTs आम तौर पर अधिक प्रदर्शन करने वाले होते हैं प्रमाणीकरण के अधिकांश पारंपरिक तरीकों की तुलना में (जब तक सर्वर किसी उपयोगकर्ता को प्रमाणित करने के लिए डेटाबेस या स्टोर के खिलाफ कोई लुकअप नहीं करता है), उन्हें काफी कुशल बनाता है।
- वे ठोस सुरक्षा गारंटी भी प्रदान करते हैं , उसमें हस्ताक्षरित JWT सुरक्षा उपाय प्रदान करते हैं ताकि कोई हमलावर या ग्राहक संरक्षित डेटा तक पहुंच प्राप्त करने के लिए टोकन को संशोधित न कर सके।
रूबी ऐप्स के लिए JWT सर्वोत्तम अभ्यास
<पी> यह कहने की आवश्यकता नहीं है कि JWT पर हस्ताक्षर करने के लिए उपयोग की जाने वाली गुप्त कुंजियाँ लंबी, यादृच्छिक और जटिल वर्ण संयोजन वाली होनी चाहिए। यह सुनिश्चित करता है कि चाबियाँ पर्याप्त रूप से सुरक्षित हैं और हमलावरों के लिए उन पर बलपूर्वक हमला करना कठिन है। <पी> रेल द्वारा उत्पन्न की जाने वाली गुप्त कुंजियाँ अधिकांश भाग के लिए सुरक्षित होती हैं, लेकिन यदि आप गलती से कुंजियाँ बनाते हैं और उन्हें प्रकट कर देते हैं, तो सुरक्षा गारंटी समाप्त हो जाती है। <पी> नेटवर्क पर पार्टियों के बीच टोकन परिवहन करते समय ट्रांसपोर्ट लेयर सिक्योरिटी (टीएलएस) का उपयोग करना भी महत्वपूर्ण है। टीएलएस मैन-इन-द-मिडिल हमले को कम कर सकता है (टोकन और सत्र-आधारित प्रमाणीकरण विधियां दोनों ऐसे हमलों के लिए प्रवण हैं)।रेल ऐप में JWT प्रमाणीकरण लागू करना
<पी> आइए टोकन-आधारित प्रमाणीकरण प्रवाह पर एक नज़र डालें: <पी>
<पी> सत्र-आधारित प्रमाणीकरण के विपरीत, एक स्टेटफुल प्रमाणीकरण तकनीक जहां हम एक प्रमाणित उपयोगकर्ता का ट्रैक रखने के लिए सत्र का उपयोग करते हैं, जेडब्ल्यूटी के साथ टोकन-आधारित प्रमाणीकरण स्टेटलेस है; सर्वर पर उपयोगकर्ता की प्रमाणीकरण स्थिति के बारे में कोई जानकारी संग्रहीत करने की कोई आवश्यकता नहीं है। यह एप्लिकेशन डिज़ाइन को सरल बनाता है। <पी> इस पोस्ट में, हम मान लेंगे कि हमारा एप्लिकेशन फ्रंटएंड और बैकएंड में विभाजित है। प्रमाणीकरण बैकएंड पर होता है, इसलिए हम प्रमाणीकरण के साथ एक रेल एपीआई बैकएंड का निर्माण करेंगे। <पी> इस पोस्ट में नमूना कोड रेल्स 7.0.5 और रूबी 3.2.2 पर आधारित है। jwt का उपयोग करना और bcrypt रूबी रत्न
<पी> हमें अपने एप्लिकेशन के लिए दो रत्नों की आवश्यकता होगी:jwt और bcrypt . <पी> jwt RFC 7519 OAuth JSON वेब टोकन मानक का रूबी कार्यान्वयन है। bcrypt OpenBSD bcrypt() के लिए रूबी बाइंडिंग है पासवर्ड हैशिंग एल्गोरिदम. <पी> आप इस कोड रेपो में नमूना कोड का अनुसरण कर सकते हैं। <पी> ध्यान दें: jwt JWTs के साथ काम करने का एकमात्र समाधान नहीं है; एक अन्य प्रसिद्ध रत्न devise-jwt है , जो डेविस और रेल्स के लिए JWT प्रमाणीकरण प्रदान करता है। लेकिन हम jwt पर ध्यान केंद्रित करेंगे इस पोस्ट में <पी> आइए शुरू करें। हमारी रेल एपीआई का निर्माण
<पी> पहली चीज़ जो हमें चाहिए वह है एक एपीआई एप्लिकेशन। हम इसके साथ एक बनाएंगे: <पी>--api यहां विकल्प केवल एपीआई अनुप्रयोगों के लिए रेल के एक छोटे स्टैक को पूर्व-कॉन्फ़िगर करता है। <पी> जेमफाइल के अंदर, हम अपनी पहली निर्भरता, jwt जोड़ सकते हैं . हमारा दूसरा रत्न, bcrypt , पहले से ही नव-निर्मित रेल एप्लिकेशन के जेमफ़ाइल में है - हमें केवल इसे अनकम्मेंट करने की आवश्यकता है। <पी> हमें bcrypt की आवश्यकता है डेटाबेस में उपयोगकर्ता पासवर्ड को सुरक्षित रूप से हैश करने के लिए। यह ध्यान रखना महत्वपूर्ण है कि हम bcrypt का उपयोग नहीं करेंगे सीधे. हम सक्रिय मॉडल के has_secure_password का लाभ उठाएंगे क्लास विधि, जो bcrypt पर निर्भर करती है . <पी> नए रेल एप्लिकेशन के साथ आने वाले डिफ़ॉल्ट रत्नों को नजरअंदाज करते हुए, हमारी जेमफाइल कुछ इस तरह दिखनी चाहिए: <पी> अब हमारे रत्नों को bundle install के साथ स्थापित करने का अच्छा समय है . User जनरेट करें और Product मॉडल
<पी> इसके बाद, हम दो मॉडल तैयार करेंगे:User और Product . User उपयोगकर्ताओं का प्रतिनिधित्व करने वाला मॉडल होगा और हम इसे उत्पादों तक पहुंच की अनुमति देने के लिए प्रमाणित करेंगे, जो Product द्वारा दर्शाया जाएगा। मॉडल. <पी> rails db:migrate के साथ अपना माइग्रेशन चलाने के बाद , मॉडलों के साथ हमारा सेटअप पूरा हो गया है, और हमारा स्कीमा, db/schema.rb में पाया गया है , अब इसके जैसा दिखना चाहिए: <पी> इस स्तर पर यह बताना महत्वपूर्ण है कि हम जानबूझकर संभावित मुद्दों जैसे डेटाबेस की कमी, सत्यापन, विशिष्टता सुनिश्चित करना आदि को अनदेखा कर रहे हैं। इस पोस्ट के लिए, हम अन्य त्रुटियों के साथ-साथ हैंडलिंग त्रुटियों की भी उपेक्षा करेंगे। यहां हमारा उद्देश्य हमारे रूबी एप्लिकेशन को सुरक्षित करने के लिए स्टेटलेस प्रमाणीकरण के रूप में जेडब्ल्यूटी को क्रियान्वित करना है। किसी उत्पादन एप्लिकेशन में, आप यह सुनिश्चित करना चाहेंगे कि ये सभी शामिल हों। एक jwt बनाएं रत्न आवरण
<पी> अगला कदम jwt के चारों ओर एक रैपर बनाना है रत्न हमने पहले स्थापित किया था। हम इस रैपर का उपयोग सर्वर से क्लाइंट तक दावों को एनकोड और डीकोड करने के लिए करेंगे। इसके लिए, हम एक app/lib बनाएंगे फ़ोल्डर. <पी> इसका कारण यह है कि हम lib का उपयोग नहीं कर रहे हैं जो फ़ोल्डर रेल्स के साथ आता है वह स्वतः लोड नहीं होता है। app के अंतर्गत सब कुछ डिफ़ॉल्ट रूप से ऑटोलोडेड और उत्सुकता से लोड किया गया है, जिससे हमारे मामले में सेटअप आसान हो गया है। <पी> हमारा रैपर वर्ग app/lib/json_web_token.rb में पाया जाता है और इस तरह दिखता है: <पी> यहां मुख्य विधियां encode हैं — उपयोगकर्ता जानकारी को एन्कोड करने के लिए — और decode - बाद में सर्वर में उपयोगकर्ता की जानकारी को डिकोड करने के लिए। ध्यान दें कि हम एन्कोडिंग और डिकोडिंग कार्यों को jwt को कैसे सौंप रहे हैं JWT.encode के माध्यम से रत्न और JWT.decode . <पी> इस बिंदु पर, आप पहले से ही अपने रेल कंसोल में इस क्लास का परीक्षण कर सकते हैं: <पी> ध्यान दें कि JsonWebToken.encode(data) का परिणाम कैसा है हेडर, पेलोड और हस्ताक्षर तैयार करते हुए, इसे एक अवधि के अनुसार तीन भागों में विभाजित किया जाता है। हमारे पास हस्ताक्षर बिट है क्योंकि हमने अपने पेलोड पर एक गुप्त कुंजी के साथ हस्ताक्षर किए हैं जो रेल Rails.application.secrets.secret_key_base के माध्यम से प्रदान करती है। . User पर वापस जाएं मॉडल
<पी> अब हमारे User पर जाने का अच्छा समय होगा app/models/user.rb पर मॉडल . हमें यहां बस has_secure_password जोड़ना है क्लास विधि: <पी> has_secure_password डेटाबेस में हमारे उपयोगकर्ताओं के पासवर्ड को सुरक्षित रूप से हैश करता है। रेल में एक नमूना उपयोगकर्ता और उत्पाद बनाएं
<पी> अब हम अपने डेटाबेस में एक नमूना उपयोगकर्ता और उत्पाद तैयार करने और अपने एप्लिकेशन की सुरक्षा का परीक्षण करने के लिए रेल्स कंसोल में जा सकते हैं: <पी> आप कोड का वही टुकड़ा अपनेseeds.rb में डाल सकते हैं यदि आप अपना डेटाबेस रीसेट करते हैं तो कुछ टाइपिंग सहेजने के लिए फ़ाइल करें। रेल नियंत्रकों में JWTs का उपयोग करना
<पी> अगले चरणों में, हम अपने नियंत्रकों के अंदर JWTs का उपयोग करके सुरक्षा लागू करेंगे। शुरू करने के लिए एक अच्छी जगहApplicationController है app/controllers/application_controller.rb पर : <पी> यहां, हम एक authenticate बनाते हैं JSON वेब टोकन को डिकोड करने की विधि जो उपयोगकर्ता हमें भेजते हैं। यदि हम टोकन को सफलतापूर्वक सत्यापित कर सकते हैं, तो हम User लौटा देते हैं ऑब्जेक्ट जो अनुरोध करने वाले उपयोगकर्ता का प्रतिनिधित्व करता है। हम यहां ज्यादातर खुशहाल रास्ते में रुचि रखते हैं और बहुत सारी जांचों को बायपास कर देंगे। <पी> authenticate को परिभाषित करना ApplicationController में विधि और इसे before_action के रूप में सेट कर रहा हूँ इससे प्राप्त होने वाले प्रत्येक नियंत्रक को सुरक्षित करता है। किसी अन्य नियंत्रक से अनुरोध करने के लिए उन नियंत्रकों तक पहुंचने के लिए एक वैध JWT की आवश्यकता होगी (क्योंकि प्रत्येक अन्य नियंत्रक को यह मुख्य नियंत्रक विरासत में मिलेगा)। <पी> इसके बाद, हमें AuthenticationController की आवश्यकता है जिस पर उपयोगकर्ता अनुरोध भेज सकते हैं और हमारे सर्वर से एक हस्ताक्षरित JSON वेब टोकन प्राप्त कर सकते हैं। इस नियंत्रक को app/controllers/authentication_controller.rb पर रखा जाना चाहिए और इस तरह दिख सकता है: <पी> जब कोई अनुरोध इस नियंत्रक से टकराता है, क्योंकि यह एक उपयोगकर्ता है जो टोकन मांग रहा है, तो हम शुरू में उन्हें प्रमाणित नहीं करना चाहते हैं। इस नियंत्रक का उद्देश्य एक टोकन के साथ प्रतिक्रिया देना है जिसका उपयोग उपयोगकर्ता हमारे सर्वर पर बाकी संसाधनों तक पहुंचने के लिए कर सकता है। इसलिए skip_before_action :authenticate की आवश्यकता है दूसरी पंक्ति पर. <पी> login में कार्रवाई (वह जिसे उपयोगकर्ता टोकन के लिए दबाते हैं), हम username लेते हैं और password इस नियंत्रक के अनुरोध के साथ आने वाले पैरामीटर से। यदि हम उपयोगकर्ता को प्रमाणित कर सकते हैं - यानी, सत्यापित कर सकते हैं कि क्या उनका उपयोगकर्ता नाम और पासवर्ड हमारे डेटाबेस में संग्रहीत किए गए से मेल खाता है - तो हम उन्हें एक हस्ताक्षरित टोकन और उस टोकन की समाप्ति तिथि के बारे में जानकारी प्रदान करते हैं। <पी> हमारे मामले में, हम टोकन की समाप्ति अवधि का उपयोग नहीं करेंगे। लेकिन एक उत्पादन एप्लिकेशन में, इसका उपयोग किसी संसाधन तक पहुंच रद्द करने के लिए किया जा सकता है। <पी> हम curl का उपयोग करके इन सभी चरणों से गुजरेंगे बाद में. संरक्षित संसाधन के साथ हमारे रूबी एप्लिकेशन का परीक्षण
<पी> हमने पहले 'रेल ऐप में जेडब्ल्यूटी प्रमाणीकरण लागू करना' अनुभाग के प्रवाह आरेख में प्रवाह को आंशिक रूप से कवर किया था। सब कुछ पूरी तरह से कवर करने और प्रवाह आरेख में सभी चरणों का परीक्षण करने के लिए, हमें सुरक्षा के लिए एक संसाधन की आवश्यकता है। <पी> हमारे पास एकProduct है मॉडल पहले से ही. अब हमें उत्पाद मॉडल और उत्पाद तथा टोकन तक पहुंचने के मार्गों के लिए एक नियंत्रक की आवश्यकता है। <पी> आइए rails g controller Product index के साथ एक नियंत्रक बनाएं तो हमारे पास कुछ ऐसा है: <पी> निःसंदेह, हमें इन नियंत्रकों तक पहुँचने के लिए एक मार्ग की आवश्यकता है। हमारा config/routes.rb कुछ इस तरह दिखना चाहिए: <पी> अब हम curl के साथ परीक्षण करेंगे यह देखने के लिए कि क्या सब कुछ अपेक्षा के अनुरूप काम करता है। ध्यान दें कि हमारे पास प्रमाणित करने के लिए पहले से ही एक उपयोगकर्ता और एक्सेस करने के लिए एक उत्पाद संसाधन है। <पी> आइए ऐसे उपयोगकर्ता के साथ JWT प्राप्त करने का प्रयास करें जो मौजूद नहीं है: <पी> हमें निम्नलिखित प्रतिक्रिया मिलनी चाहिए: <पी> अब उस उपयोगकर्ता के साथ भी ऐसा ही प्रयास करें जिसे हमने पहले बनाया था: <पी> इससे हमें एक हस्ताक्षरित JSON वेब टोकन मिलना चाहिए जो इस तरह दिख सकता है: <पी> आइए इस टोकन को एक सेकंड के लिए रखें और खराब टोकन वाले उत्पाद संसाधन तक पहुंचने का प्रयास करें (मैंने टोकन में एक यादृच्छिक वर्ण बदल दिया है): <पी> और हमें मिलना चाहिए: <पी> हालाँकि, यदि हम पहले सर्वर से प्राप्त वैध टोकन के साथ उत्पाद संसाधन तक पहुँचने के लिए वही अनुरोध करते हैं: <पी> हमें उत्पाद संसाधन तक पहुंच प्रदान की गई है: <पी> बस इतना ही! हमने अपने रूबी एप्लिकेशन को JSON वेब टोकन के साथ सफलतापूर्वक सुरक्षित कर लिया है! समापन
<पी> इस पोस्ट में, हमने JSON वेब टोकन और वे कैसे काम करते हैं, इस पर चर्चा की। हमने सबसे पहले जेडब्ल्यूटी की बुनियादी बातों को कवर किया, जिसमें उनकी संरचना और कुछ सर्वोत्तम प्रथाएं शामिल हैं। फिर हमनेjwt का उपयोग करके एक सरल JWT प्रमाणीकरण लागू किया रत्न. <पी> मुझे आशा है कि आपको यह पोस्ट उपयोगी लगी होगी। हैप्पी कोडिंग! <पी> पी.एस. यदि आप प्रेस से हटते ही रूबी मैजिक पोस्ट पढ़ना चाहते हैं, तो हमारे रूबी मैजिक न्यूज़लेटर की सदस्यता लें और एक भी पोस्ट न चूकें! 
