मैं OAuth v1 उपभोक्ता कुंजी को कैसे स्टोर करूं और उपयोगकर्ता को बताए बिना एक ओपन सोर्स डेस्कटॉप ट्विटर क्लाइंट के लिए गुप्त रखूं?

Question

मैं एक मोटी-क्लाइंट, डेस्कटॉप, ओपन सोर्स ट्विटर क्लाइंट बनाना चाहता हूं। मैं अपने OAuth / Twitter आवरण के रूप में अपनी भाषा और Twitterizer के रूप में .NET का उपयोग कर रहा हूं , और मेरे एप्लिकेशन को संभवतः खुले स्रोत के रूप में जारी किया जाएगा।

OAuth टोकन प्राप्त करने के लिए, जानकारी के चार टुकड़े आवश्यक हैं:

1. पहुँच टोकन (ट्विटर उपयोगकर्ता नाम)
2. एक्सेस सीक्रेट (ट्विटर पासवर्ड)
3. उपभोक्ता कुंजी
4. उपभोक्ता रहस्य

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

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

Comments

+1 मुझे भी यही चिंता है। हालाँकि यह सवाल वास्तव में डेस्कटॉप वातावरण या ट्विटर के लिए विशिष्ट नहीं है - यह प्रमाणीकरण स्कीमा मेरे द्वारा विश्वास की जाने वाली वेबसेवाओं में बहुत आम है?

— vemv

क्योंकि आपके प्रश्न को "ग्राहक पर गुप्त डेटा को कैसे संग्रहीत किया जाए" जैसे कुछ को सार किया जा सकता है "मुझे लगता है कि यदि आप एक नया प्रश्न कम ट्विटर-विशिष्ट पोस्ट करते हैं तो आप अधिक उत्तर आकर्षित कर सकते हैं। IMO।

— जेफ वेलिंग

+1 मैं इस बारे में भी उत्सुक हूं कि यहां सबसे अच्छा अभ्यास क्या है। अपने Qt एप्लिकेशन में मैं OAuth का उपयोग करता हूं लेकिन मैं उपभोक्ता विवरण को बाइनरी में स्ट्रिंग्स (QString) के रूप में संग्रहीत करता हूं।

— fejd

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

— जस्टिन डियरिंग 15

Answer 1

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

Answer 2

मैं गलत हो सकता हूं, लेकिन यदि आप डेस्कटॉप या मोबाइल ऐप, ओपन सोर्स या नहीं के साथ कुंजियों को बंडल करते हैं, तो उन्हें एक्सेस करना संभव है। यदि ट्विटर और टंबलर जैसी सेवाएं हमें OAuth-केवल API का उपयोग करने पर मजबूर करती हैं, तो हमारे पास दो विकल्प हैं:

• हर ऐप के लिए एक प्रॉक्‍सी प्रॉक्सी सर्विस सेटअप करें
• एप्लिकेशन के साथ बंडल कुंजियाँ

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

अंत में, हर उपयोगकर्ता को API कुंजियाँ प्राप्त करने के लिए बाध्य करने का विकल्प होता है ।

Answer 3

RFC 5849 की धारा 4.6 , जो OAuth 1 को परिभाषित करती है, कहती है कि उपभोक्ता रहस्य डेस्कटॉप उपभोक्ताओं द्वारा उपयोग करने के लिए कभी नहीं था, इसके बावजूद व्यवहार में ट्विटर का उपयोग किया गया था। जैसा कि नेल्सन एल्हागे ने " डियर ट्विटर " में बताया , ट्विटर डेस्कटॉप ग्राहकों की उपभोक्ता कुंजी को समाप्त कर सकता है, बशर्ते कि ग्राहक विफल होने के लिए बहुत बड़ा न हो। लेकिन डेस्कटॉप या मोबाइल एप्लिकेशन में OAuth 1 के उपयोग की अनुमति देने के लिए दो वर्कअराउंड हैं।

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

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

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

Answer 4

मैं जवाब देने जा रहा हूं, लेकिन चेतावनी दी जा रही है कि मैंने खुद से नहीं निपटा है, मैं सर्वोत्तम अभ्यासों और मौजूदा प्रासंगिक अनुभव से दूर जा रहा हूं;

मैं इसके बारे में बहुत ज्यादा चिंता नहीं करता। यदि आपका क्लाइंट खुला स्रोत है, तो वे वैसे भी स्रोत तक पहुंच बनाने जा रहे हैं, और यह नियंत्रित करने की कोशिश कर रहे हैं कि वे आपके कार्यक्रम के साथ क्या करते हैं, वैसे भी खुले स्रोत की प्रकृति के खिलाफ जाता है (हालांकि महत्वपूर्ण रूप से, आप क्या करने की कोशिश नहीं कर रहे हैं )।

यदि किसी को आपके कार्यक्रम को डिबग करने और अपनी चाबी निकालने के लिए पर्याप्त ज्ञान है, तो वे संभवत: जानते हैं कि इससे अधिक कैसे करना है और आप बहुत अच्छी तरह से अपना समय बर्बाद करने की कोशिश कर सकते हैं।

एहतियात के तौर पर मैं हर बार (यदि संभव हो तो) चाबियों को बदल देता, लेकिन अगर वे सब कर सकते हैं तो आपके कार्यक्रम होने का दिखावा करते हैं, क्योंकि यह मेरे लिए बहुत गंभीर नहीं है।

पूर्ण प्रकटीकरण, मैं Twitters एपीआई, twitterizer एपीआई, oauth आवश्यकताओं, या कुछ और के साथ परिचित नहीं हूँ जो मैंने कहा कि लगता है कि संदिग्ध लगता है;)

Comments

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

— जस्टिन डियरिंग

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

— जेफ वेलिंग

Answer 5

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

देखें इस ब्लॉग पोस्ट के रूप में यह दिखाता है कि कैसे काम करता है प्रोटोकॉल अधिक जानकारी के लिए।