मदद! मेरे मेटावर्स में एक JWT है!

क्या जेडब्ल्यूटी वास्तव में मर चुके हैं, या उन्हें सिर्फ गलत समझा गया है?

मैंने हाल ही में कुछ लेख देखे हैं जो सुझाव देते हैं कि वेब 3 के आगमन और वॉलेट के प्रसार के उपयोग से उपयोगकर्ता पारंपरिक ईमेल/पासवर्ड-आधारित खाता प्रणालियों को छोड़ देंगे, और इसके बजाय, अपने वॉलेट का उपयोग करके लॉग इन करेंगे।

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

इनमें से कई लेख आगे कहते हैं, "हाँ, हमें अब JWTs की आवश्यकता नहीं है!"।

यहीं पर मैं असहमत हूं।

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

मेटामास्क के साथ लॉग इन करना यह साबित करता है कि यह आप ही हैं - लेकिन आप भविष्य के एपीआई कॉल को कैसे साबित करते हैं, यह आप ही हैं?

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

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

यदि इसमें कई सेवाएँ शामिल हैं, तो यह प्रमाणीकरण सेवा के लिए कई अतिरिक्त राउंड ट्रिप हो सकती हैं।

इस स्थिति को ठीक करने के लिए, क्रिप्टोग्राफ़िक विशेषज्ञ सोचने लगे।

वे जेडब्ल्यूटी के साथ आए थे - अब ओपनआईडी मानक का हिस्सा है, आप जानते हैं, कि कीक्लोक, ऑथ0, और अन्य आपको लागू करने में मदद करते हैं।

JWTs, आप सभी

समाधान टोकन का एक सेट प्रदान करना था - JSON वेब टोकन सटीक होना। उस सेट में एक AccessToken , एक RefreshToken , और एक IdToken । इन टोकन को तब एक गुप्त द्वारा "हस्ताक्षरित" किया गया था - जिसे आमतौर पर ClientSecret कहा जाता है। हस्ताक्षर करना, जैसे कि हम एक ही पृष्ठ पर हैं, एक क्रिप्टोग्राफ़िक हैशिंग एल्गोरिथम है, JWTs के मामले में - आमतौर पर HS256 (Auth0 के लिए डिफ़ॉल्ट)। ClientSecret के मामले में HS256 को इनपुट के रूप में उपयोग किया जाता है और इसलिए, उस हैश को सफलतापूर्वक समझने के लिए आवश्यक कुंजी बन जाती है - या इसे "सत्यापित" करें। RS256 और ES256 के साथ एक सार्वजनिक/निजी कुंजी जोड़ी का उपयोग किया जाता है, अर्थात निजी कुंजी द्वारा हस्ताक्षरित, और क्लाइंट पर सार्वजनिक कुंजी के साथ सत्यापित किया जाता है।

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

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

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

टोकन पर हस्ताक्षर करने और सत्यापित करने के शीर्ष पर सावधानियों के न्यूनतम सेट में निम्न शामिल हैं:

1. 5-15 मिनट के एक्सेस टोकन जेडब्ल्यूटी पर एक समाप्ति तिथि निर्धारित करना और सुनिश्चित करना कि टोकन प्राप्त होने पर समाप्त नहीं हुए हैं

2. एक्सेस टोकन को मेमोरी में छोड़कर स्टोर न करें

3. इश्यू रीफ्रेश टोकन जिन्हें संग्रहीत किया जा सकता है और सत्यापन के लिए सर्वर पर भेजा जा सकता है, और इसे जारी करने ClientId ClientSecret उपयोग करके रीफ्रेश किया जा सकता है।

4. केवल TLS कनेक्शन (HTTPS) पर प्रेषित होने पर ही उपयोग करें

5. केवल HTTP कुकीज़ का उपयोग करें ताकि उन्हें ब्राउज़र की तरफ संशोधित नहीं किया जा सके

6. कॉर्स सेटिंग्स

7. हैश आउटपुट के समान आकार की एक कुंजी (उदाहरण के लिए, "HS256" के लिए 256 बिट) या इससे बड़ी का उपयोग इस एल्गोरिथम के साथ किया जाना चाहिए। - RFC7518 , नोट: Auth0 HS256 के लिए 512 बिट्स का उपयोग करता है।

   
   

एक गोपनीय क्लाइंट को एक मध्यस्थ सर्वर की आवश्यकता होती है, जैसे कि Node.js - यह सर्वर ऑथ सेवा के लिए एक प्रॉक्सी है, इसलिए क्लाइंट को क्लाइंट सीक्रेट के बारे में जानने की आवश्यकता नहीं है। एक सार्वजनिक क्लाइंट क्लाइंट सीक्रेट को उजागर करता है, और ब्राउज़र और ऑथ सेवा के बीच कोई प्रॉक्सी सर्वर नहीं होता है। इसे सीओआरएस सेटिंग्स के साथ और प्रतिबंधित किया जा सकता है, इसलिए केवल कुछ डोमेन के अनुरोधों की अनुमति है।

अतिरिक्त सावधानियों में शामिल हैं:

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

और शायद अधिक - उदाहरण के लिए, यदि आप किसी ऐसे व्यक्ति का पता लगाते हैं जो निरस्त किए गए रीफ्रेश टोकन का उपयोग करने का प्रयास कर रहा है, तो आप उस उपयोगकर्ता के सभी सक्रिय रीफ्रेश टोकन को रद्द कर सकते हैं।

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

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

यदि आप पहले से ही OpenId का उपयोग करते हैं, तो संभव है कि आपके पास पहले से ही ये चीज़ें मौजूद हों। आखिरकार, यह एक प्रमाणीकरण मानक है।

तो हम वेब3 में जेडब्ल्यूटी का उपयोग करने और मेटामास्क दुनिया के साथ लॉगिन करने की सुविधा कैसे रख सकते हैं?

जेडब्ल्यूटी और वेब3?

आइए SSO के लिए उपयोग किए जाने वाले OpenId प्रमाणीकरण प्रवाह को समझकर प्रारंभ करें।

1. आप एक वेबसाइट पर जाते हैं और अपने खाते से लॉगिन करना चाहते हैं - आप लॉगिन बटन पर क्लिक करें
2. आपको SSO लॉगिन पृष्ठ पर पुनः निर्देशित किया जाता है - आप एक ईमेल/उपयोगकर्ता नाम और पासवर्ड के साथ लॉगिन करते हैं
3. आपको JWTs के एक सेट के साथ मूल एप्लिकेशन पर वापस भेज दिया जाता है जो उचित रूप से संग्रहीत होते हैं और साइलेंट रिफ्रेश बैकग्राउंड फ्लो में उपयोग किए जाते हैं।

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

1. आप एक वेबसाइट पर जाते हैं और अपने खाते से लॉगिन करना चाहते हैं - आप लॉगिन बटन पर क्लिक करें

2. आपको प्रमाणीकरण सर्वर से एक चुनौती प्राप्त होती है जो आपके बटुए को खोलता है और आपसे चुनौती को "साइन" करने के लिए कहता है। प्रेस साइन।

3. प्रमाणीकरण सर्वर आपके हस्ताक्षर की पुष्टि करता है और आपको JWTs का एक सेट जारी करता है जो उचित रूप से संग्रहीत होते हैं और साइलेंट रिफ्रेश बैकग्राउंड फ्लो में उपयोग किए जाते हैं।

   
   

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

यह वही है जो मैं एक पूर्ण चक्र डेवलपर के रूप में चाहता हूं। मैं पहिया को फिर से नहीं बनाना चाहता। मैं OpenID को web3auth से बदलना चाहता हूं और अभी भी उन सभी शक्तिशाली उपकरणों का उपयोग करने में सक्षम हूं जिनका मैं उपयोग कर रहा हूं।

दुर्भाग्य से, मुझे ऐसा web3auth सर्वर नहीं मिला, जिसने ऐसा किया हो और साथ ही सुरक्षा संबंधी सावधानियां भी बरती हों। मुझे इस प्रक्रिया में तकनीकों का प्रदर्शन करने वाली कुछ परियोजनाएं मिलीं, लेकिन संपूर्ण प्रवाह अंत से अंत तक नहीं।

तो मुझे निर्माण करना है ...

मैंने इसे यहां ऑथ सर्वर बनाया है: https://github.com/CloudNativeEntrepreneur/web3auth-service

और यह यहाँ SvelteKit एकीकरण इसके साथ जाने के लिए है, जो सभी चीजों को लागू करता है - साइलेंट रिफ्रेश, यादा याद - वे सभी चीजें जिनका मैंने ऊपर उल्लेख किया है: https://github.com/CloudNativeEntrepreneur/sveltekit-web3auth

बेशक अगर एक ग्राफक्यूएल क्लाइंट और उदाहरण होने वाला था, तो एक ग्राफक्यूएल सर्वर और डेटाबेस भी होना चाहिए, इसलिए मैंने इसके उदाहरण भी दिए: https://github.com/CloudNativeEntrepreneur/example-hasura + https: //github.com/CloudNativeEntrepreneur/example-readmodel

यह उदाहरण Zalando Postgres ऑपरेटर और SchemaHero का उपयोग करता है, इसलिए आपको केवल अपने DBs की घोषणा करने और YAML में अपनी स्कीमा का वर्णन करने की आवश्यकता है, और हसुरा आपके लिए आवश्यक सभी ग्राफ़क्यूएल एपीआई को स्वत: उत्पन्न करेगा। और, मैंने हसुरा को ध्यान में रखते हुए ऑथ सर्वर बनाया है, इसलिए इसमें हसुरा के आरबीएसी और अनुमतियों के साथ एकीकृत करने के उचित दावे हैं, जो काफी मजबूत हैं।

और निश्चित रूप से, आपको वह सब चलाने के लिए एक जगह की आवश्यकता है, और इसलिए, एक स्थानीय देव क्लस्टर जो कि istio, और ऑपरेटरों, और आपके लिए SchemaHero जैसे सभी टूलिंग सेट करता है! https://github.com/CloudNativeEntrepreneur/local-dev-cluster

लेकिन कौन जानता है कि उस सब का उपयोग कैसे किया जाए?

इसलिए मैंने यह मेटा रेपो बनाया: https://github.com/CloudNativeEntrepreneur/web3auth-meta

उस मेटा रेपो का उपयोग करने से आपको आवश्यक सभी परियोजनाओं को सही स्थानों पर क्लोन कर दिया जाएगा, और उन सभी को एक साथ चलाया जाएगा।

अंत में, सभी परियोजनाओं को एक साथ चलाने के लिए, आपको उपकरण स्थापित करने की आवश्यकता है, और उपकरण स्थापित करना कष्टप्रद है - इसलिए मैंने यहां यह रेपो बनाया है जो उन सभी को आपके लिए स्थापित करेगा! https://github.com/CloudNativeEntrepreneur/onboard

मैंने sveltekit-web3auth भी प्रकाशित किया, और एक SvelteKit प्रोजेक्ट से एक टेम्प्लेट बनाया जो इसका उपयोग करता है और इसमें GraphQL की स्थापना और प्रमाणीकरण के साथ एक हसुरा इंस्टेंस के साथ एकीकृत किया गया है ताकि जब आप अपनी खुद की परियोजनाएं बनाने के लिए तैयार हों, तो आप इसका उपयोग कर सकते हैं एक टेम्पलेट के रूप में! https://github.com/CloudNativeEntrepreneur/sveltekit-web3auth-template

यदि आप अभी तक web3 ऑथ वर्ल्ड के लिए तैयार नहीं हैं, तो आप https://github.com/CloudNativeEntrepreneur/sveltekit-oidc का भी उपयोग कर सकते हैं, जो आपके स्थानीय देव क्लस्टर से कनेक्ट करने के लिए पूर्व-कॉन्फ़िगर होता है, और एक Keycloak इंस्टेंस जो कि सेट अप होता है यह। यह देखते हुए कि दोनों परियोजनाएं JWTs को कैसे जारी करती हैं, लक्ष्य है कि ऑथ सिस्टम को विनिमेय बनाया जाए - web3auth या क्लासिक OIDC का उपयोग करें - टोकन का अपस्ट्रीम उपयोग समान है।

अब जाओ और ऑटोजेनरेटेड ग्राफक्यूएल एपीआई और मजबूत आरबीएसी और अनुमतियों और सदस्यताओं के साथ कुछ हाइब्रिड डीएपी बनाएं और प्रमाणित एसएसआर पेज और साइलेंट रिफ्रेश लूप और रोटेटिंग रिफ्रेश टोकन और सामान!

निष्कर्ष

अंत में, नहीं, जेडब्ल्यूटी और एथेरियम/मेटामास्क के साथ लॉगिन परस्पर अनन्य नहीं हैं। वास्तव में, यदि आप डेवलपर उत्पादकता और मौजूदा उपकरणों के साथ एकीकरण पसंद करते हैं, तो मुझे लगता है कि आप JWTs और web3auth का उपयोग करके काफी अच्छा करेंगे।

प्रोत्साहित करना!

मैं परामर्श के लिए उपलब्ध हूँ! यदि आप किसी ऐसे प्रोजेक्ट पर मेरी मदद करना चाहते हैं, जिस पर आप काम कर रहे हैं, तो मुझे Twitter पर एक संदेश भेजें!