2009-03-10 8 views
5

मैं एक वेब एपीआई डिजाइन कर रहा हूँ। मुझे उपयोगकर्ता को प्रमाणित करने की आवश्यकता है। मैं उपयोगकर्ता को अपने उपयोगकर्ता नाम/पासवर्ड में cleartext में जाने के लिए थोड़ा संकोच कर रहा हूं .. कुछ ऐसा: api.mysite.com/auth.php?user=x & पास = वाईएक वेब एपीआई डिज़ाइन करना: प्रमाणीकरण कैसे करें?

एक और विकल्प जिसे मैंने पढ़ा था बेस 64 उपयोगकर्ता नाम/पासवर्ड एन्कोडिंग और फिर HTTP अनुरोध भेजना। तो क्या इसका मतलब है कि सर्वर की तरफ; मैं _GET ['user'] और _GET ['password'] करूंगा और फिर किसी भी तरह उन्हें डीकोड करूँगा?

क्या यह ट्विटर है: http://apiwiki.twitter.com/REST+API+Documentation#Authentication?

उत्तर

7

बेस 64 कोई सुरक्षा नहीं है। असली सुरक्षा के लिए एसएसएल का प्रयोग करें।

+0

तो ट्विटर एपीआई सुरक्षा का उपयोग कैसे करता है? http://apiwiki.twitter.com/REST+API+Documentation# प्रमाणीकरण – shergill

+0

वे HTTP बेसिक ऑथ का उपयोग कर रहे हैं, जो सादा पाठ है, जिसे पोस्टर नहीं चाहता था। – truppo

+0

मैं बस सोच रहा हूं .. अगर यह ट्विटर के लिए कोई समस्या/समस्या नहीं है; तो क्या यह वास्तव में इतना बड़ा सौदा है? – shergill

2

यदि यह एक webservice है, तो आप प्रमाणीकरण के अधिक सुरक्षित रूप का बेहतर उपयोग करेंगे। उदाहरण के लिए, लाइवजर्नल प्रोटोकॉल पर देखें: Challenge-Response

+0

ट्विटर एपीआई इसका प्रबंधन कैसे करता है: http://apiwiki.twitter.com/REST+API+Documentation# प्रमाणीकरण? – shergill

3

इस सप्ताह आईईटीएफ ने new draft प्रकाशित किया जिसमें HTTP में विभिन्न प्रमाणीकरण तंत्र की सुरक्षा गुणों पर चर्चा की गई। आपको वहां उपयोगी जानकारी मिलनी चाहिए।

व्यक्तिगत रूप से मैं कम से कम digest authentication पढ़ने के लिए अनुशंसा करता हूं और विश्लेषण करता हूं कि यह आपके लिए उपयुक्त है या नहीं।

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

5

जैसा कि ट्रूपो द्वारा उल्लिखित है, पहले एसएसएल का उपयोग करें।

कितनी वेब सेवाओं में एक "प्रमाणीकृत" सेवा होती है जो बाद में उपयोग की जाने वाली टोकन देता है, और सादे टेक्स्ट में उपयोग किया जा सकता है, क्योंकि यह केवल सीमित समय के लिए मान्य है। जब यह समाप्त हो जाता है, तो ग्राहक बस एक और प्रमाणित करता है।

इसका मुख्य लाभ यह है कि यह SSL अनुरोधों की संख्या को कम करता है, जो सर्वर पर लोड को हल्का करता है।

1

कृपया एपीआई के लिए नियमित उपयोगकर्ता नाम/पासवर्ड प्रमाणीकरण का उपयोग न करें। लोगों को वास्तव में मैशप सेवा में विदेशी सेवाओं से प्रमाण-पत्र रखने के लिए मजबूर नहीं किया जाना चाहिए।

कृपया यूथ http://oauth.net/ या कम से कम कुछ चुनौती-प्रतिक्रिया आधारित प्रणाली का उपयोग करने पर विचार करें, जैसे यूजीन ने सुझाव दिया था।

एक आसान तरीका अतिथि सेवा को टोकन उत्पन्न करने देना होगा जो उसके ऐप और उपयोगकर्ता से जुड़ा हुआ है। यदि आप कुछ काम करते हैं तो आप टोकनक्रिएशन को सुरक्षित भी कर सकते हैं ताकि केवल कुछ निजी/सार्वजनिक-कुंजी तंत्र के साथ विदेशी सेवाओं को ही अनुमति दी जा सके।

अतिथि सेवा को प्रमाणित करने के लिए इसका उपयोग करने से पहले उपयोगकर्ता को आपके ऐप में इस टोकन को अधिकृत करना होगा।

+0

आपकी प्रतिक्रिया के लिए धन्यवाद। मैं चुनौती-प्रतिक्रिया प्रणाली को लागू करने जा रहा हूं। – shergill

0

मुझे यह article आंख खोलने का पता चला है।

संक्षेप में: प्रति उपयोगकर्ता एपीआई कुंजी की एक जोड़ी का उपयोग करें। एक क्लाइंट प्रमाणीकरण के लिए है, एक पैरामीटर हस्ताक्षर के लिए।

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^