OAuth अच्छा है, लेकिन Google और Microsoft उसे प्रवेश-द्वार बना देते हैं

OAuth सुरक्षा में सुधार है

बेसिक ऑथेंटिकेशन, लंबे समय तक वैध पासवर्ड और बहुत व्यापक अधिकार वाले क्रेडेंशियल से आगे बढ़ना सही निर्णय था। OAuth सीमित अनुमतियाँ, अल्पकालिक एक्सेस टोकन, वापस लिए जा सकने वाले कनेक्शन और एप्लिकेशन वास्तव में क्या कर सकता है, इस पर बेहतर नियंत्रण देता है।

यह मानक खुला है। यह बताता है कि कोई एप्लिकेशन उपयोगकर्ता की ओर से एक्सेस कैसे माँग और प्राप्त कर सकता है। मानक स्वयं डेवलपर से प्लेटफ़ॉर्म संचालक को व्यावसायिक दस्तावेज़, संगठन के प्रमाण, प्रदर्शन वीडियो या प्रवेश आवेदन देने की माँग नहीं करता। यह अतिरिक्त परत इकोसिस्टम के नियमों से आती है।

खुला मानक भी बंद दरवाज़ा बन सकता है

SMTP और IMAP ऐसे इंटरनेट में विकसित हुए जिसकी बुनियाद आपसी संगतता थी। प्रदाता मेल सर्वर चला सकता था, डेवलपर क्लाइंट बना सकता था और दोनों दस्तावेज़ीकृत मानकों के माध्यम से संवाद कर सकते थे।

OAuth इस खुलेपन को नष्ट नहीं करता। लेकिन जब मेलबॉक्स एक्सेस प्लेटफ़ॉर्म के मालिक की मंज़ूरी पर भी निर्भर हो, तो निर्णायक प्रश्न बदल जाता है: क्या उपयोगकर्ता एप्लिकेशन को अनुमति देता है, या Google अथवा Microsoft तय करता है कि उसे अनुमति दी ही जा सकती है या नहीं?

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

Microsoft 365: सहमति अक्सर टेनेंट की सीमा पर रुक जाती है

यहाँ बताया गया Microsoft का अवरोध अक्सर Google जैसी वीडियो समीक्षा नहीं है। यह Microsoft Entra ID, प्रकाशक सत्यापन, प्रशासक की सहमति और प्रत्येक Microsoft 365 टेनेंट की नीतियों के पारस्परिक प्रभाव से बनता है।

Microsoft उपयोगकर्ता सहमति को सत्यापित प्रकाशकों और कम जोखिम वाली चुनी गई अनुमतियों तक सीमित रखने की सलाह देता है। प्रशासक इसे और सीमित कर सकते हैं या बंद कर सकते हैं। कोई उपयोगकर्ता स्पष्ट रूप से मेलबॉक्स इंटीग्रेशन चाह सकता है, फिर भी उसे बताया जा सकता है कि प्रशासक की मंज़ूरी आवश्यक है।

नए मल्टीटेनेंट एप्लिकेशन के लिए प्रकाशक सत्यापन भी निर्णायक हो सकता है। अन्य आवश्यकताओं के साथ प्रकाशक को ऐप पंजीकरण से जुड़ा सत्यापित Microsoft AI Cloud Partner Program खाता चाहिए। यह भरोसे का समझ में आने वाला संकेत है, लेकिन खुले प्राधिकरण की उपयोगिता को Microsoft की व्यावसायिक और साझेदार प्रक्रियाओं से भी बाँध देता है।

Google और Gmail: अनुमति-क्षेत्र की समीक्षा उत्पाद की बाधा बन सकती है

Gmail की प्रक्रिया अधिक केंद्रीय नियंत्रण में है। प्रकाशन के समय वर्णित नीति वर्गीकरण gmail.send को संवेदनशील और gmail.readonly को प्रतिबंधित बताता है। इन अनुमतियों की आवश्यकता वाले सार्वजनिक एप्लिकेशन को उपयोग के अनुसार ब्रांड और डोमेन का प्रमाण, अनुमति-क्षेत्र का सटीक औचित्य और प्रदर्शन वीडियो देना पड़ सकता है।

वीडियो में पूरा OAuth प्रवाह, वास्तविक सहमति स्क्रीन और माँगे गए प्रत्येक अनुमति-क्षेत्र का उपयोग करने वाली सुविधाएँ दिखनी चाहिए। यदि औचित्य अस्वीकार हो जाए या समीक्षक को प्रस्तुति एप्लिकेशन से मेल खाती न लगे, तो अतिरिक्त प्रश्न, नई रिकॉर्डिंग या दोबारा आवेदन की आवश्यकता पड़ सकती है।

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

100 उपयोगकर्ताओं की सीमा के व्यावहारिक परिणाम हैं

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

यदि कोई संवेदनशील या प्रतिबंधित अनुमति-क्षेत्र अस्वीकार हो जाए, तो उपयोगकर्ता उस अस्वीकृत क्षेत्र को एक्सेस नहीं कर सकते। इसलिए सीमा या अस्वीकृति केवल प्रशासनिक चेतावनी नहीं है: वह उस उत्पाद सुविधा को रोक सकती है जिसे उपयोगकर्ता सक्रिय करना चाहता है।

Hassolux को इन अनुमतियों की आवश्यकता क्यों है

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

Microsoft 365 के लिए प्रत्यायोजित Mail.Read और Mail.Send एक्सेस लॉग-इन उपयोगकर्ता की ओर से आने वाले संदेश पढ़ने और उसी उपयोगकर्ता द्वारा स्पष्ट रूप से माँगे गए दस्तावेज़ ईमेल भेजने में काम आता है। Gmail में gmail.readonly चुने गए संदेश और PDF/XML अटैचमेंट प्राप्त करता है, जबकि gmail.send अलग से उपयोगकर्ता द्वारा शुरू किए गए आउटगोइंग मेल के लिए है।

Hassolux केवल उपयोगकर्ता द्वारा चुनी गई अवधि में खोजता है, प्रेषक, विषय और प्राप्ति का समय पढ़ता है, तथा चालान प्रसंस्करण के लिए समर्थित PDF या XML अटैचमेंट आयात करता है। यह Gmail संदेशों को न स्थानांतरित करता है, न चिह्नित, संशोधित या हटाता है। भेजना अलग है और केवल उपयोगकर्ता की विशिष्ट कार्रवाई के बाद होता है। कनेक्शन हटाया जा सकता है और प्रदाता के यहाँ भी उसका प्राधिकरण वापस लिया जा सकता है।

यहाँ छोटे अनुमति-क्षेत्र की माँग तकनीकी विरोधाभास बन सकती है। केवल मेटाडेटा की अनुमति संदेश की सामग्री या चालान अटैचमेंट उपलब्ध नहीं कराती; एप्लिकेशन उस दस्तावेज़ को आयात नहीं कर सकता जिसे पढ़ने की उसे अनुमति ही नहीं है। इस दिखाई देने वाली सुविधा के लिए gmail.readonly उस सबसे सीमित Google अनुमति के रूप में माँगा जाता है जो आवश्यक एक्सेस देती है, न कि एहतियातन व्यापक अधिकार जमा करने के लिए।

हमारा अनुभव: बार-बार प्रदर्शन, फिर भी अस्वीकृति

Hassolux के लिए Google सत्यापन केवल इंटीग्रेशन लागू करने से कहीं अधिक था। हमने बार-बार प्रदर्शन वीडियो बनाए, समीक्षा चक्रों की प्रतीक्षा की, स्थिति संबंधी ईमेल के उत्तर दिए और अनुमति-क्षेत्र की आवश्यकता समझाई। उस क्षेत्र की अस्वीकृति केवल किसी अमूर्त API अनुमति को नहीं हटाती: वह उस सुविधा को हटा देती है जिसके लिए उपयोगकर्ता अपना मेलबॉक्स जोड़ना चाहता है।

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

निष्पक्ष सत्यापन प्रक्रिया को क्या देना चाहिए

प्रस्तावित सुधारों का उद्देश्य सुरक्षा बनाए रखते हुए स्वतंत्र इंटीग्रेशन को संभव बनाना है।

• पहले से जाँचे जा सकने वाले स्पष्ट मानदंड: डेवलपर को लागू करने से पहले पता होना चाहिए कि किन उपयोगों की अनुमति है।
• विशिष्ट और समझने योग्य निर्णय: अस्वीकृति में ठोस तकनीकी या गोपनीयता संबंधी असंगति बताई जानी चाहिए।
• अनुपातिक प्रमाण: मुख्यतः प्रकाशक के आकार के बजाय डेटा प्रवाह, भंडारण स्थान और वास्तविक जोखिम का आकलन हो।
• दोबारा उपयोग की जा सकने वाली समीक्षा: उत्पाद में छोटे बदलाव से पूरी प्रमाण प्रक्रिया फिर से शुरू न हो।
• सार्थक तकनीकी अपील: जहाँ प्रदाता कोई छोटी काम करने वाली अनुमति नहीं देता, उन स्थितियों का ध्यान रखा जाए।
• प्रभावी उपयोगकर्ता विकल्प: जानकारी के साथ दी गई सहमति और किसी भी समय वापस लेने के अधिकार को प्लेटफ़ॉर्म की व्यापक सीमाओं से अधिक महत्व मिले।

खुला प्राधिकरण खुला रहना चाहिए

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

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