लेकिन, लेकिन, लेकिन aUtH हार गया है

नहीं, ऐसा नहीं है। यह उबाऊ है, लालफीताशाही है, एक हल हो चुकी समस्या है... लेकिन इसे एक सामान्य कथन के रूप में कठिन मत कहिए।

मैं "मैंने PHP में पासवर्ड हैश करने के लिए MD5 का उपयोग किया है" वर्षों पुराना है। निश्चित रूप से, यह एक भयानक विचार था, 2012 में भी। लेकिन, तब, मुझे याद नहीं है कि मैंने ऑथ को "कठिन" माना था। यह अपने आप में एक बहुत ही सरल परीक्षा थी - एक ईमेल या उपयोगकर्ता नाम प्राप्त करें, एक पासवर्ड प्राप्त करें, इसे हैश करें (MD5 के साथ, जैसा कि "भगवान ने इरादा किया"), और यदि आप विशेष रूप से सुरक्षा के प्रति सचेत थे, तो पासवर्ड को [ सॉल्ट ] करें। यह सब कहीं स्टोर करें, आमतौर पर डेटाबेस में। ता-दा, साइनअप हो गया।

आजकल, कथा बदल गई है। "प्रमाणीकरण कठिन है" एक हमेशा मौजूद कथा की तरह लगता है जो HackerNews या Reddit क्लिक की दूरी पर है। लेकिन क्या यह वास्तव में है? मेरे विचार से, सच्चाई यह है कि प्रमाणीकरण बनाना कठिन नहीं है - कोई भी इसे सीख सकता है (और इस क्षेत्र में काम करने वाले सभी लोगों को मूल बातें सीखनी चाहिए)। असली चुनौती अतिरिक्त चीजों में है: MFA, उपयोगकर्ता प्रबंधन, पासवर्ड रीसेट, सैकड़ों OAuth प्रदाताओं में से प्रत्येक, और विभिन्न प्रदाताओं से खाता मर्ज। यह हज़ार कटों से मौत है। चूँकि प्रमाणीकरण एक हल की गई समस्या है, इसलिए पहिये का फिर से आविष्कार करना आपके समय का सबसे अच्छा उपयोग नहीं है। लेकिन इसका मतलब यह नहीं है कि "प्रमाणीकरण कठिन है" एक सामान्य कथन के रूप में सही है या सही के करीब भी है। आपको प्रयोग करना चाहिए, मूल बातें समझनी चाहिए, और वहाँ से निर्माण करना चाहिए। जटिलता केवल आपके द्वारा बनाए जा रहे पैमाने (या संभावित पैमाने) के साथ बढ़ती है।

तो, प्रमाणीकरण वास्तव में कितना कठिन हो सकता है? आइये इस पर गौर करें।

पुराने दिनों में...

PHP और md5 के बारे में कहानी को जहां मैंने छोड़ा था, वहीं से आगे बढ़ते हुए, लॉगिन कार्यक्षमता का निर्माण करने के लिए समान चरणों का पालन किया गया; एक ईमेल और पासवर्ड प्राप्त करें, अपने स्टोरेज में ईमेल के अस्तित्व की जांच करें, उस ईमेल के लिए संग्रहीत सॉल्ट के साथ पासवर्ड को हैश करें, परिणामी हैश की तुलना डेटाबेस में संग्रहीत हैश से करें, और यदि यह सब ठीक काम करता है, तो setcookie के माध्यम से कुकी सेट करें (हम अभी भी PHP की दुनिया में हैं - ऐसा नहीं है कि अन्य पारिस्थितिकी प्रणालियों में समग्र तर्क बहुत अलग था)।

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

पूर्ण प्रकटीकरण - मैं सुपरटोकन्स के लिए काम करता हूँ। हालाँकि, यह लेख एक सर्वव्यापी कथा के बारे में व्यक्तिगत हताशा से उपजा है कि एक सामान्य कथन के रूप में प्रमाणीकरण कितना कठिन है। दूसरे शब्दों में, मैं "आपको अपनी चीज़ बेचने" की कोशिश नहीं कर रहा हूँ। आप जो चाहें उसका उपयोग करें।

अपना खुद का रोल बनाएं - एक "आधुनिक" रूप

ईमेल/पासवर्ड और सामाजिक प्रमाणीकरण

आज हम जिस मुकाम पर हैं, वहां पहुंचने के लिए हम शुरुआत से शुरू करेंगे... हैरानी की बात है, मुझे पता है। हम शायद इस बात से सहमत हो सकते हैं कि ये घटक ईमेल/पासवर्ड + सोशल लॉगिन PoC बनाने के लिए पर्याप्त हैं:

1. एक सर्वर जो रूटों को संभालता है - साइनअप, साइन-इन, साइन-आउट...
2. उपयोगकर्ता रिकॉर्ड रखने के लिए किसी प्रकार का भंडारण (इन-मेमोरी सरणी भी काम करती है)
3. दृश्य - लॉगिन, साइनअप, और प्रमाणीकृत "डैशबोर्ड" स्क्रीन।
4. सामाजिक प्रमाणीकरण के लिए हैंडलर

एक्सप्रेस और पासपोर्ट के साथ चलते हुए, चूँकि हम पहियों का पुनः आविष्कार नहीं करने जा रहे हैं, हम बहुत ही नीरस और दोहराव वाले कोड की ठीक 150 पंक्तियों पर पहुँचते हैं: https://github.com/supertokens/auth-express/blob/master/index.mjs । अगला भाग कोड में क्या चल रहा है, इसकी सतही व्याख्या करेगा, इसलिए यदि आप पहले से ही अवधारणाओं से परिचित हैं, तो आगे बढ़ने के लिए स्वतंत्र महसूस करें। एक्सप्रेस ऐप वैसे भी एक PoC है।

आइये इसका शीघ्र विश्लेषण करें:

स्क्रीन पर सामग्री प्रस्तुत करना

जिस तरह से मैं इसे देखता हूँ, इसे करने के दो तरीके हैं - रेंडरिंग से शुरू करें और ऑथ रूट पर जाएँ या इसके विपरीत। ज़्यादातर संयोग से, मैं एक FE-भारी pleb बन गया (मैं अभी भी SQL कर सकता हूँ, अगर आप सोच रहे हैं), इसलिए मैं "ऑन-स्क्रीन रेंडरिंग स्टफ" दृष्टिकोण से शुरू करूँगा।

चूंकि यह एक PoC है, इसलिए हम React-fancy का सहारा नहीं लेंगे। ejs के साथ सादा SSR ठीक रहेगा: https://github.com/supertokens/auth-express/tree/master/views

मार्ग जोड़ना

कुछ पासपोर्ट.js उदाहरणों के आधार पर, लेकिन आगे सरलीकृत रूप में, हमें निम्नलिखित की आवश्यकता है:

1. कुछ निर्भरताएँ: npm i passport passport-local express-session । आइए संक्षेप में प्रत्येक पर जाएँ:

   1. Passport.js - एक्सप्रेस और नोड के लिए OG प्रमाणीकरण मिडलवेयर.
   2. पासपोर्ट-स्थानीय - पासपोर्ट के लिए एक प्रमाणीकरण रणनीति; एक मॉड्यूल में एक प्रमाणीकरण रणनीति जो एक विशिष्ट प्रमाणीकरण विधि के लिए प्रमाणीकरण प्रक्रिया को संभालती है - इस मामले में, एक उपयोगकर्ता नाम (ईमेल) और पासवर्ड का उपयोग करके एक स्थानीय लॉगिन।
   3. एक्सप्रेस-सेशन - एक मिडलवेयर जो सत्र डेटा का प्रबंधन करता है, जिससे आप HTTP अनुरोधों के बीच उपयोगकर्ता सत्रों को संग्रहीत और बनाए रख सकते हैं। यह प्रत्येक क्लाइंट को एक अद्वितीय सत्र आईडी असाइन करके काम करता है, जिसे क्लाइंट साइड पर कुकी में संग्रहीत किया जाता है और सर्वर पर सत्र डेटा प्राप्त करने के लिए उपयोग किया जाता है।

2. हमारे उपयोगकर्ताओं को संग्रहीत करने के लिए एक स्थान (ऊपर दिया गया उदाहरण इन-मेमोरी सरणी का उपयोग करता है): https://github.com/supertokens/auth-express/blob/master/index.mjs#L13

3. उपयोगकर्ता लुकअप के लिए आने वाले अनुरोधों को संभालने के लिए हमारे पासपोर्ट इंस्टेंस और हमारे लोकलस्ट्रेटजी इंस्टेंस के लिए कॉन्फ़िगरेशन: https://github.com/supertokens/auth-express/blob/master/index.mjs#L18

4. पासपोर्ट ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L60 ) और एक्सप्रेस-सेशन ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L69 ) को प्रारंभ करें।

बहुत ज़्यादा, ज़रूर। मुश्किल? मुझे ऐसा नहीं लगता, कम से कम इसे खिलौने की तरह लागू करने के मामले में तो नहीं। लेकिन हम कुछ समय पहले ईमेल/पासवर्ड कॉम्बो का इस्तेमाल करना छोड़ चुके हैं। आइए देखें कि हमारे पास जो है, उसके ऊपर सोशल प्रोवाइडर जोड़ना कितना मुश्किल है।

यहाँ एक उदाहरण प्रदाता के लिए, मैंने एक साधारण कारण से GitHub को चुना है - यदि आप पूरी तरह से इसका अनुसरण करने का निर्णय लेते हैं, तो यह आरंभ करने के लिए सबसे आसान प्रदाताओं में से एक है (Google, आप पर नज़र डालते हुए)।

यदि आप पूरी तरह से अनुसरण करने का निर्णय लेते हैं, तो यहां एक लिंक दिया गया है जो बताता है कि उन GitHub कुंजियों को कैसे प्राप्त किया जाए: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app ओह, और BTW, यदि आप चिंतित थे तो रेपो में मौजूद कुंजी मान्य नहीं हैं ;)

हमारे PoC में GitHub OAuth2 को एकीकृत करना

सबसे पहले, हमें एक और निर्भरता की आवश्यकता है, npm i passport-github2 । पासपोर्ट-github2 पासपोर्ट के लिए एक प्रमाणीकरण रणनीति है, जो हमें GitHub के OAuth2 API के साथ एकीकृत करने की अनुमति देता है।

कुछ हैंडलर ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L122-L133 ) और कॉन्फ़िगरेशन ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L29-L45 ) बाद में, बस इतना ही। जटिल? शायद नहीं। लालफीताशाही? यकीन मानिए। बोरिंग? बिल्कुल। खासकर अगर आपको इसे बार-बार करना पड़े। यह एक हल की गई समस्या है; पहियों का फिर से आविष्कार करना अक्सर किसी के समय का सबसे अच्छा उपयोग नहीं होता है जैसा कि हमने स्थापित किया है।

बड़ा विचार

अब तक, हम शायद इस बात पर सहमत हो सकते हैं कि Auth का निर्माण करना कठिन नहीं है। इसलिए, यह कोई जादुई चीज़ नहीं है जिसे केवल सफ़ेद दाढ़ी वाले जादूगर ही समझ सकते हैं और लागू कर सकते हैं जो JWT की रहस्यमय भाषा बोलते हैं।

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

इस पर विचार करें - ऊपर दिए गए उदाहरण में, हमारे पास एक काम करने वाली प्रमाणीकरण चीज़ है। कुछ हद तक। लेकिन यहाँ बताया गया है कि यह क्या नहीं कर सकता (लेख के आरंभ में भी इसका उल्लेख किया गया है):

• 2एफए, एमएफए
• पासवर्ड रीसेट
• सैकड़ों OAuth प्रदाताओं में से प्रत्येक अपनी विशिष्टता के साथ
• प्रयोक्ता प्रबंधन
• विभिन्न प्रदाताओं से खाता विलय
• सभी संभावित किनारे के मामलों और संभावित सुरक्षा खामियों को कवर करें
• ...और मैं आगे भी जा सकता हूं

हम शायद इनमें से हर एक को लागू कर सकते हैं। और अपने आप में, हर एक भाग को सरल माना जा सकता है। लेकिन यह जोड़ता है। इसलिए, यह जरूरी नहीं कि कार्यान्वयन हो - यह इसे बनाए रखना, इसके लिए जिम्मेदार होना, मानकों, सुरक्षा उल्लंघनों आदि के साथ अद्यतित रहना है। साथ ही, हाथ उठाकर जवाब देना - आप में से कितने लोग RfC पढ़ना पसंद करते हैं? मुझे नहीं लगता कि अगर हम मीटअप पर होते तो मैं बहुत से लोगों को हाथ उठाते हुए देखता।

मेरा कहना है कि संपूर्ण रूप से देखा जाए तो प्रमाणीकरण आसान नहीं है। निश्चित रूप से, हम PoC के लिए आसानी से कुछ जोड़ सकते हैं, जैसा कि हमने ऊपर किया। लेकिन यह जादुई नहीं है, इसे समझना असंभव नहीं है, और कृपया, कृपया ऐसा न कहें। मेरी राय में, यह सोच (और मार्केटिंग) पूरे उद्योग के लिए हानिकारक है।

तो, स्वाभाविक अनुवर्ती प्रश्न यह होगा कि - आपको अपना स्वयं का रोल कब बनाना चाहिए?

खिलौना परियोजना, स्वतंत्र और शैक्षिक गतिविधियाँ

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

स्टार्टअप

आम तौर पर, अगर आप उत्पाद बना रहे हैं, तो अपना खुद का प्रमाणीकरण न करें। यह एक बहुत ही उबाऊ और लालफीताशाही वाले पहिये का पुनर्निर्माण है। आपके पास चुनने के लिए बहुत सारे विकल्प हैं। साथ ही, आप कुछ बना रहे हैं, है न? अगर आपका उत्पाद प्रमाणीकरण योग्य नहीं है, तो हम इस बातचीत में क्यों लगे हुए हैं?

स्केलअप और उससे ऊपर (जैसे भी हम उन्हें परिभाषित करना चाहें)

ऐसा न करें। स्टार्टअप्स के समान ही कारण - लेकिन यह निश्चित रूप से यहां अधिक लागू होता है।

आप शायद समझ सकते हैं कि मैं इस बारे में क्या कहना चाह रहा हूँ। "ऑथ मुश्किल है" मैं कहूँगा, यह एक मार्केटिंग पिच है जब इसे एक सामान्य कथन के रूप में इस्तेमाल किया जाता है। आप ऑथ को समझ सकते हैं, आप इसे बना सकते हैं, लेकिन यह उबाऊ है, इसे बनाए रखना मज़ेदार नहीं है, और यह एक ऐसी समस्या है जिसका समाधान किया जा सकता है। इस प्रकार, इसे एक कमोडिटी माना जा सकता है - जिसे आप अपनी पसंद के अनुसार शेल्फ से चुन सकते हैं (नीचे कुछ विकल्प दिए गए हैं)।

स्व-होस्टेड और FOSS परिदृश्य

जो लोग अपने स्टैक के मालिक हैं (जैसे कि मैं भी हूं), उनके लिए भी चुनने के लिए बहुत सारे विकल्प हैं:

प्रामाणिक लाइब्रेरी

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

प्रमाणीकरण सर्वर

• कीक्लोक - एक ओपन-सोर्स पहचान और पहुंच प्रबंधन सर्वर जो सिंगल साइन-ऑन (एसएसओ), पहचान ब्रोकरिंग और उपयोगकर्ता फेडरेशन जैसी सुविधाएं प्रदान करता है।
• सुपरटोकन्स (ऊपर अस्वीकरण देखें) - एक ओपन-सोर्स प्रमाणीकरण समाधान जो सुरक्षा और सरलता पर ध्यान देने के साथ सत्र प्रबंधन, सामाजिक लॉगिन और ईमेल/पासवर्ड प्रमाणीकरण जैसी पूर्व-निर्मित सुविधाएं प्रदान करता है।
• फ्यूजनऑथ - डेवलपर्स के लिए एक लचीला प्रमाणीकरण प्लेटफॉर्म, जो उपयोगकर्ता प्रबंधन, मल्टीफैक्टर प्रमाणीकरण (एमएफए) और एकल साइन-ऑन (एसएसओ) जैसी सुविधाएं प्रदान करता है।
• ऑथेलिया - एक ओपन-सोर्स प्रमाणीकरण सर्वर जो मल्टीफैक्टर प्रमाणीकरण (एमएफए) और एसएसओ प्रदान करता है, जिसे रिवर्स प्रॉक्सी का उपयोग करके अनुप्रयोगों को सुरक्षित करने के लिए डिज़ाइन किया गया है।

संग्रहण + प्रमाणीकरण

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

इसलिए, भले ही आप प्रमाणीकरण के लिए तीसरे पक्ष के सॉफ्टवेयर का उपयोग नहीं करना चाहते हों, फिर भी आप अपनी आवश्यकताओं और प्राथमिकताओं के आधार पर, किसी ओपन-सोर्स सॉफ्टवेयर को चुन सकते हैं और उसका उपयोग कर सकते हैं।

निष्कर्ष: प्रमाणीकरण विकास का "लालफीताशाही" है

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