प्रमाणीकरण श्रृंखला (भाग 1): एप्लिकेशन इंजीनियरिंग प्रथाएँ

परिचय

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

विभिन्न एप्लिकेशन में, पहचान प्रमाणीकरण आमतौर पर निम्नलिखित दो तकनीकों का उपयोग करता है:

1. कुकी और सत्र: यह पारंपरिक प्रमाणीकरण तंत्र वेब एप्लिकेशन में व्यापक रूप से उपयोग किया जाता है, मुख्य रूप से ब्राउज़र के भीतर। यह कुकी और सत्र का उपयोग करके उपयोगकर्ता की पहचान सत्यापित करता है और सत्र स्थिति बनाए रखता है।

2. बेयरर टोकन: यह एक अधिक आधुनिक प्रमाणीकरण तंत्र है जो ब्राउज़र कुकी पर निर्भरता को समाप्त करता है और इसके बजाय HTTP प्रोटोकॉल का उपयोग करता है। यह API परिदृश्य के लिए विशेष रूप से उपयुक्त है और मोबाइल एप्लिकेशन में उपयोग किया जा सकता है।

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

पारंपरिक वेब एप्लिकेशन

पहले, हम वेब एप्लिकेशन बनाने के लिए Java JSP का उपयोग करते थे, और उपयोगकर्ताओं की पहचान करने के लिए JSESSIONID का उपयोग करते थे, जो क्लाइंट के ब्राउज़र में कुकी में संग्रहीत एक सत्र ID होता है और प्रत्येक अनुरोध के साथ ले जाया जाता है।

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

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

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

वेब एप्लिकेशन का विकास: फ्रंट-एंड और बैक-एंड का अलगाव

Vue और React जैसी नई फ्रंट-एंड तकनीकों के उभरने के साथ, वेब इंटरैक्शन में क्रांति आई है। पहले, उपयोगकर्ताओं को वेब पृष्ठों पर फॉर्म भरना और सबमिट करना पड़ता था, HTML फॉर्म और बटन का उपयोग करके बैक-एंड के साथ इंटरैक्ट करना पड़ता था, जो एक सहज उपयोगकर्ता अनुभव प्रदान नहीं करता था। अब, पृष्ठ पर इंटरैक्शन रियल-टाइम होते हैं, और डेवलपर्स बैक-एंड API के साथ इंटरैक्ट करने के लिए JavaScript स्क्रिप्ट का उपयोग करते हैं, जो एक अधिक सुसंगत और निरंतर अनुभव प्रदान करता है। उपयोगकर्ता इंटरैक्शन सीधे HTTP अनुरोध से विभिन्न API को आमंत्रित करने में बदल गए हैं।

वेब पृष्ठ-उन्मुख एप्लिकेशन और API-उन्मुख एप्लिकेशन के बीच पहचान प्रमाणीकरण तंत्र में कुछ अंतर होते हैं। जबकि पुरानी कुकी का अभी भी उपयोग किया जा सकता है, वे आधुनिक फ्रंट-एंड तकनीकों के लिए उपयुक्त नहीं हैं। नई तकनीकें डेवलपर्स को अधिक अभिव्यंजक कोड के साथ सशक्त करती हैं, जिससे वे अधिक ऑपरेशन कर सकते हैं, जिसमें ऐसे परिदृश्य शामिल हैं जहां हमें फ्रंट-एंड पर उपयोगकर्ता खाते को स्विच करने की आवश्यकता हो सकती है। हालांकि, इसे सीधे फ्रंट-एंड में कुकी के माध्यम से लागू करना चुनौतीपूर्ण है (सुरक्षा कारणों से, उपयोगकर्ता पहचान से संबंधित कुकी को अक्सर httpOnly के रूप में कॉन्फ़िगर किया जाता है, जो JavaScript स्क्रिप्ट को उन्हें पढ़ने और मैनिपुलेट करने से रोकता है)।

आमतौर पर, आधुनिक फ्रंट-एंड एप्लिकेशन उपयोगकर्ता सत्र को स्वयं प्रबंधित करते हैं। एक बार उपयोगकर्ता सफलतापूर्वक लॉग इन करने के बाद, फ्रंट-एंड बैकएंड द्वारा उत्पन्न टोकन को प्रबंधित करता है और API कॉल करते समय इसे अनुरोध हेडर में जोड़ता है ताकि बैकएंड उपयोगकर्ता की पहचान की पहचान कर सके। API उपयोगकर्ता जानकारी की पहचान करने के लिए टोकन का उपयोग करते हैं। JSON Web Tokens (JWT) का उपयोग करके टोकन तंत्र को मैन्युअल रूप से लागू करने के लिए विभिन्न तकनीकी साधन उपलब्ध हैं। JWT पेलोड में उपयोगकर्ता ID जैसी पहचान जानकारी संग्रहीत होती है, जिसे तब साइन किया जाता है ताकि बैकएंड टोकन को सत्यापित कर सके और उपयोगकर्ता पहचान जानकारी प्राप्त कर सके।

हालांकि, JWT में कुछ कमियां भी हैं, जैसे:

• JWT की समाप्ति समय तय होती है और साइन होने के बाद इसे संशोधित नहीं किया जा सकता है। चूंकि इसे आमतौर पर बैकएंड द्वारा संग्रहीत नहीं किया जाता है और केवल साइन सत्यापन होता है, टोकन को रद्द करना संभव नहीं होता है, जो टोकन चोरी का जोखिम पैदा करता है।

• पेलोड डेटा सादे पाठ में संग्रहीत होता है और क्लाइंट द्वारा पार्स किया जा सकता है, जिससे यह गोपनीय जानकारी संग्रहीत करने के लिए उपयुक्त नहीं है।

सौभाग्य से, अब इन कमियों को दूर करने के लिए नई JWT विनिर्देश उपलब्ध हैं। JWT पेलोड में "jti" नामक एक फ़ील्ड शामिल हो सकता है जो JWT के लिए एक अद्वितीय पहचानकर्ता संग्रहीत करता है, जिसे बैकएंड कैश में संग्रहीत किया जा सकता है ताकि JWT के जीवनचक्र को नियंत्रित किया जा सके। इसके अलावा, JSON Web Encryption (JWE) विनिर्देश एक एन्क्रिप्टेड JWT एक्सटेंशन को परिभाषित करता है जो असममित और सममित एन्क्रिप्शन के लाभों को जोड़ता है, यह सुनिश्चित करता है कि पेलोड सिफरटेक्स्ट रूप में प्रसारित हो ताकि लीकेज को रोका जा सके।

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

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

API गेटवे और पहचान प्रमाणीकरण

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

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

API गेटवे हमें इस समस्या को हल करने में मदद कर सकते हैं, कुकी या टोकन के समान प्रमाणीकरण और पार्सिंग कार्यों को संभालकर, और पार्स की गई पहचान जानकारी को सीधे बैकएंड सेवाओं को पास करके, कार्य की दोहराव को कम कर सकते हैं। Apache APISIX और API7 Enterprise भी आउट-ऑफ-द-बॉक्स OpenID Connect प्रमाणीकरण कार्यक्षमता का समर्थन करते हैं, जो उपयोगकर्ताओं को सीधे पहचान प्रमाणीकरण सेवाओं को एकीकृत करने में मदद करते हैं। इसके अलावा, API गेटवे स्क्रिप्टिंग के माध्यम से किसी भी प्रमाणीकरण तंत्र को लागू करने का समर्थन करते हैं, इसलिए यहां तक कि कस्टम पहचान प्रमाणीकरण तंत्र के साथ भी, उन्हें API गेटवे पर एकीकृत किया जा सकता है, जिससे एप्लिकेशन विकास को सरल बनाया जा सकता है।

सारांश

उपयोगकर्ता इंटरैक्शन तरीकों के विकास ने पहचान प्रमाणीकरण में प्रगति को प्रेरित किया है। API-केंद्रित दृष्टिकोण एक मुख्यधारा का रुझान बन रहा है, और API माइक्रोसर्विस आर्किटेक्चर द्वारा प्रदान किए जा सकते हैं, जिसके लिए एक एकीकृत पहचान प्रमाणीकरण तंत्र की आवश्यकता होती है ताकि अतिरिक्त विकास को कम किया जा सके। इसलिए, हमें अधिक आधुनिक तंत्र जैसे OpenID Connect और JWT का चयन करना चाहिए, और API गेटवे का उपयोग करने से API विकास के लिए अतिरिक्त कार्यक्षमता प्रदान की जा सकती है।