रीस्टफुल एपीआई (प्रौद्योगिकी अज्ञेयवादी)

Question

के लिए लोग प्रमाणीकरण कैसे संभालते हैं मैं कुछ मोबाइल एप्लिकेशन बनाने की सोच रहा हूं। इसलिए, ये ऐप्स JSON के माध्यम से और REST के माध्यम से मेरे सर्वर पर 'बात' करेंगे (उदाहरण के लिए, पोस्ट, पोस्ट, आदि)।

यदि मैं यह सुनिश्चित करना चाहता हूं कि कोई क्लाइंट फ़ोन ऐप ऐसा करने की कोशिश कर रहा है जिसके लिए कुछ 'अनुमति' की आवश्यकता है, तो लोग इसे कैसे संभालेंगे?

उदाहरण के लिए: -> टीवी, कार के, कपड़े, आदि एपीआई लोग दुकान ब्राउज़ करें और वस्तुओं की खरीद करने की अनुमति देगा

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

यह कैसे किया जा सकता है?

मैंने देखा है कि ट्विटर अपने ओथ के साथ कैसे करता है .. और ऐसा लगता है कि उनके पास अनुरोध हेडर में कई मूल्य हैं? यदि ऐसा है (और मैं इस दृष्टिकोण को पसंद करता हूं), क्या यह संभव है कि मैं उपयोगकर्ता नाम/पासवर्ड (उदाहरण के लिए ट्विटर या फेसबुक ओएथ प्रदाता) स्टोर करने के लिए वेबसाइट के रूप में किसी अन्य तृतीय पक्ष का उपयोग कर सकूं .. और मैं जो कुछ करता हूं वह किसी भी तरह से पुनर्प्राप्त होता है कस्टम हेडर डेटा .. और सुनिश्चित करें कि यह मेरे डीबी में मौजूद है .. अन्यथा .. उन्हें अपने OAuth प्रदाता के साथ प्रमाणीकृत करने के लिए मिलता है?

या फिर कोई और तरीका है?

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

Answer 1

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

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

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

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

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

या कोई और तरीका है?

बेशक। आप अपने आईडी में उपयोगकर्ता आईडी को स्टोर कर सकते हैं और अपने एपीआई को सुरक्षित करने के लिए basic या digest प्रमाणीकरण का उपयोग कर सकते हैं। मूल प्रमाणीकरण केवल एक (आसानी से गणना) अतिरिक्त आपके अनुरोध पर हैडर की आवश्यकता है:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 

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

Answer 2

जैसा कि विश्वसनीय सेवाएं HTTP कॉल का उपयोग करती हैं, आप सुरक्षा उद्देश्यों के लिए HTTP Basic Authentication पर रिले कर सकते हैं। यह सरल, प्रत्यक्ष है और प्रोटोकॉल के लिए पहले से ही समर्थित है; और यदि आप परिवहन में अतिरिक्त सुरक्षा नहीं चाहते हैं तो आप एसएसएल का उपयोग कर सकते हैं। अच्छी तरह से स्थापित उत्पादों जैसे आईबीएम वेबस्पेयर प्रोसेस सर्वर इस दृष्टिकोण का उपयोग करते हैं।

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