सरल, सुरक्षित एपीआई प्रमाणीकरण प्रणाली

Question

मेरे पास मेरी वेबसाइट के कुछ डेटाबेस (PHP गेटवे के माध्यम से) तक पहुंचने के लिए अन्य वेबसाइटों/ऐप्स के लिए एक साधारण रीस्ट JSON API है। असल में सेवा इस तरह काम करती है: example example.com/fruit/orange पर कॉल करें, सर्वर नारंगी के बारे में JSON जानकारी देता है। यहां समस्या है: मैं केवल उन वेबसाइटों को चाहता हूं जिन्हें मैं इस सेवा तक पहुंचने की अनुमति देता हूं। एक साधारण एपीआई कुंजी प्रणाली के साथ, किसी भी वेबसाइट को अधिकृत वेबसाइट (संभावित रूप से) क्लाइंट साइड कोड से कुंजी की प्रतिलिपि बनाकर जल्दी से एक कुंजी प्राप्त कर सकती है। मैंने ओथ को देखा है, लेकिन मैं जो कर रहा हूं उसके लिए यह थोड़ा जटिल लगता है। समाधान की?

Answer 1

यदि किसी के ग्राहक पक्ष कोड से समझौता किया गया है, तो उन्हें एक नई कुंजी मिलनी चाहिए। अगर उनके कोड का खुलासा हुआ तो आप इतना कुछ नहीं कर सकते हैं।

हालांकि, आप दिए गए कुंजी के लिए अधिकृत सिस्टम के आईपी पते पंजीकृत होने के लिए अधिक सख्त हो सकते हैं। यह एक अतिरिक्त कदम जोड़ता है और अधिक हो सकता है।

मुझे यकीन नहीं है कि "सरल एपीआई कुंजी" का उपयोग करके आपका क्या मतलब है, लेकिन आपको किसी प्रकार का प्रमाणीकरण का उपयोग करना चाहिए जिसमें निजी कुंजी (केवल क्लाइंट और सर्वर के लिए जाना जाता है), और उसके बाद किसी प्रकार का चेकसम एल्गोरिदम डेटा को यह सुनिश्चित करने के लिए कि क्लाइंट वास्तव में आपको लगता है कि यह है, और यह कि डेटा पारगमन में संशोधित नहीं किया गया है। Amazon AWS यह कैसे करना है इसका एक बड़ा उदाहरण है।

मुझे लगता है कि यह गारंटी देने के लिए थोड़ा सख्त हो सकता है कि आपके ग्राहकों के पक्ष में कोड से समझौता नहीं किया गया है। मुझे लगता है कि अपने ग्राहकों की ज़िम्मेदारी अपने ग्राहकों की सुरक्षा के लिए उचित है। बेशक यह मानता है कि एक हमलावर केवल उस ग्राहक के खाते को गड़बड़ कर सकता है।

शायद आप किसी विशेष खाते के लिए आईपी अनुरोध कौन से आ रहे हैं, इसका लॉग इन रख सकते हैं, और यदि कोई नया आईपी आते हैं, तो खाते को ध्वजांकित करें, ग्राहक को ईमेल भेजें, और उन आईपी को अधिकृत करने के लिए कहें। मुझे नहीं पता शायद ऐसा कुछ काम कर सकता है।

Answer 2

असल में आपके पास दो विकल्प हैं, या तो आईपी द्वारा एक्सेस प्रतिबंधित करें या फिर एपीआई कुंजी रखें, दोनों विकल्पों में उनके सकारात्मक और नकारात्मक पक्ष हैं।

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

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

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

Answer 3

आपको ओथ का उपयोग करना चाहिए।

वास्तव में दो ओएथ विनिर्देश, 3-पैर वाले संस्करण और 2-पैर वाले संस्करण हैं। 3-पायदान वाला संस्करण वह है जो अधिक ध्यान देता है, और यह वह नहीं है जिसे आप उपयोग करना चाहते हैं।

अच्छी खबर यह है कि 2-पैर वाले संस्करण वास्तव में आप जो चाहते हैं वह करता है, यह किसी एप्लिकेशन को साझा गुप्त कुंजी के माध्यम से किसी अन्य तक पहुंच प्रदान करने की अनुमति देता है (अमेज़ॅन के वेब सेवा मॉडल के समान ही, आप एचएमएसी- SHA1 हस्ताक्षर विधि) या सार्वजनिक/निजी कुंजी सिस्टम के माध्यम से (हस्ताक्षर विधि का उपयोग करें: आरएसए-एसएचए 1)। बुरी खबर यह है कि यह अभी तक 3-पैर वाले संस्करण के रूप में अभी तक समर्थित नहीं है, इसलिए आपको अभी कुछ और काम करना पड़ सकता है अन्यथा आपको अभी भी करना होगा।

असल में, 2-पैर वाले ओएथ केवल कई क्षेत्रों में "साइन" (एक हैश ओवर की गणना) करने का एक तरीका निर्दिष्ट करता है जिसमें वर्तमान दिनांक, "nonce," नामक यादृच्छिक संख्या और आपके अनुरोध के पैरामीटर शामिल हैं। यह आपकी वेब सेवा के अनुरोधों का प्रतिरूपण करने के लिए बहुत कठिन बनाता है।

ओएथ धीरे-धीरे लेकिन निश्चित रूप से इस तरह की चीज़ के लिए एक स्वीकार्य मानक बन रहा है - यदि आप इसे गले लगाते हैं तो आप लंबे समय तक सबसे अच्छे तरीके से बंद हो जाएंगे क्योंकि लोग ऐसा करने के लिए उपलब्ध विभिन्न पुस्तकालयों का लाभ उठा सकते हैं।

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

शुभकामनाएं!

क्रिस

Answer 4

OAuth यहाँ समाधान नहीं है।
ओएथ तब होता है जब आपके पास एंडसर्स होता है और तीसरे पक्ष के ऐप्स चाहते हैं कि अंतिम उपयोगकर्ता पासवर्ड न हों। OAuth उपयोग कब करें: के लिए http://blog.apigee.com/detail/when_to_use_oauth/

जाओ सरल एपीआई कुंजी।
और यदि अधिक सुरक्षित समाधान की आवश्यकता हो तो अतिरिक्त उपाय करें।

यहाँ कुछ अधिक जानकारी, आईपी की सुरक्षा के उत्पादन के सभी लगता है जुड़ा हो रहा से पहले उपयोगकर्ताओं के लिए एक विशाल बग का उत्पादन होता है http://blog.apigee.com/detail/do_you_need_api_keys_api_identity_vs._authorization/

Answer 5

। सिम्बियन 60 के पास कोड किए गए यूआई, + पूरी तरह से भरे नेटवर्क सेट-अप के साथ-साथ कई उपयोगकर्ताओं (ओपेरा हैंडलर यूआई 6.5, ओपेरा मिनी वी 8 और 10 को लागू करने) के बीच एक अवांछित, भरोसेमंद और सुरक्षित सिग्नल छोड़ने की पूरी क्षमता है। अंततः अन्य लिंक के लिए प्रतिबंधित क्यों करें जब तेजी से लिंक विधि बनाने की खोजने योग्य विधि अंततः प्राप्त की जाती है। अधिक पहचाने गए खातों को ध्यान में रखते हुए, उस 'सही खाते' की उचित निगरानी- यदि वे बिलों का भुगतान करने के ट्रैक-अनुपालन पर हैं और यह जानकर कि उपयोगकर्ताओं के पास अप्रत्याशित संतुलन शेष है, तो लोकप्रिय/हस्ताक्षर किए गए मोबाइल पर इंटरनेट सिग्नल का एक तेज़ लिंक बन जाएगा उद्योग। साइट पर पहुंचने से पहले हार्ड सुरक्षा सुविधाओं को क्यों बनाते हैं, मासिक रूप से उनके खातों की एक यात्रा सभी कनेक्टिविटी मुद्दों को मिटा सकती है? यदि उनके पास अवैतनिक बिल नहीं हैं तो मोबाइल के सभी उपयोगकर्ता को 'कनेक्ट होने' की कोई क्षमता नहीं होनी चाहिए।क्यों न 'ऑल इन वन' - पंजीकरण/आवेदन खाता, एक 'निगरानी क्षमता' के साथ ओएस, (शायद एक ई-मेल खाता) के साथ तय प्रोग्राम किया गया है, यदि वे भुगतान कर रहे हैं या नहीं (पासवर्ड समस्याएं चिंता-दी जानी चाहिए अन्य विभाग के लिए)। और यदि 'खाता' उनके खाते को ठीक से बंद नहीं करता है और उनकी अन्य लिंक सुविधाएं हैं। उनमें से प्रत्येक का अपना हित है कि दैनिक हुक करने के लिए, यदि आप बिना भुगतान किए गए बिलों के कारण उन्हें बंद कर देते हैं/उन्हें बंद कर देते हैं जो उन्हें फिर से सब्सक्राइब करने के लिए शुरू कर सकते हैं और अधिक जिम्मेदार उपयोगकर्ताओं बनने के लिए उन्हें अधिक अनुशासन दे सकते हैं और यह भी समाप्त हो सकता है एक खाता अगर बनाए रखा नहीं है। नेटवर्क प्रदाता के सहयोग से किसी पहचान किए गए 'सच्चे खाते' की मासिक निगरानी या पहुंच, उनकी डेटा सेवाओं को देखने के लिए हमेशा उपयोगकर्ताओं के नाम 'और' पासवर्ड ',' स्थान ',' अनुमतियों 'के लिए पूछने की बजाय उच्च गोपनीयता उत्पन्न करती है। आईपी ​​ने पहले से ही अपनी पहली पहचान या 'उपयोगकर्ताओं के स्थान को ढूंढना' चिह्नित किया है, इसलिए ब्राउज़रों की पूर्व-खोजों पर इसे रखना अनिवार्य लगता है, 'डेटा प्राप्त करने' या 'प्रोसेसिंग डेटा' का उपयोग क्यों न करें।