ग्राहक पक्ष पर संग्रहीत प्रमाणीकरण टोकन कहां है?

Question

मैं Azure पर एक एमवीसी 4 वेब एपीआई प्रोजेक्ट होस्ट करना चाहता हूं। मुझे यह सुनिश्चित करने की ज़रूरत है कि किसी भी तृतीय-पक्ष ऐप और किसी भी ब्राउज़र से API को एक्सेस किया जा सके। एक रीस्टफुल एपीआई को कार्यान्वित करना जो जेएसओएन को मेरे लिए एक अच्छा विचार पसंद करता है। अब, मेरे लिए सबसे बड़ी चुनौती एक मंच-अज्ञेय प्रमाणीकरण तंत्र बना रही है। मैं डिफ़ॉल्ट सदस्यता प्रदाता का उपयोग नहीं करना चाहता हूं। मैं एसएसएल का उपयोग करूँगा। मैं फॉर्म प्रमाणीकरण का भी उपयोग नहीं करूंगा। सभी एपीआई कॉल JQuery/AJAX के माध्यम से होने जा रहे हैं।

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

तक पहुंचने के लिए सर्वर पर टोकन भेजता है, अब मुझे समझ में नहीं आता है कि क्लाइंट टोकन स्टोर करता है? क्या यह एक कुकी में सहेजा गया है? यदि हां, तो गैर-ब्राउज़र तृतीय पक्ष ऐप्स प्रमाणीकरण टोकन को कहां से सुरक्षित करते हैं? टोकन चोरी कितनी आसानी से है?

Answer 1

प्रमाणीकरण टोकन ASP.net सदस्यता प्रदाता और प्रमाणीकरण मॉड्यूल द्वारा कुकी में संग्रहीत किया जाता है। क्लाइंट साइड पर HTTP क्लाइंट लाइब्रेरी कुकीज़ से निपट सकती है। फॉर्म प्रमाणीकरण के साथ cookieless प्रमाणीकरण भी संभव है। यदि चैनल एन्क्रिप्टेड नहीं है (एसएसएल या https) तो टोकन मध्य आदमी स्नीफर्स द्वारा चुराया जा सकता है। सुरक्षित websapps प्रमाणीकरण कुकी के लिए एक छोटा टाइमआउट सेट करता है ताकि निष्क्रियता की एक छोटी अवधि इस प्रकार सत्र को समाप्त कर देगी।

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

1. क्लाइंट के पास सर्वर द्वारा जारी किए गए खाते के लिए एक निजी कुंजी है या उपयोगकर्ता द्वारा खाते के लिए सर्वर में आयात की जाती है।

2. ग्राहक सामान्य रूप से एपीआई को कॉल करता है लेकिन कुछ जानकारी प्राधिकरण शीर्षलेख में रखता है। जानकारी क्लाइंट की खाता आईडी और तिथि के साथ मिश्रित डेटा भेजने के एचएमएसी होगी।

यहाँ HTTP एपीआई में प्राधिकरण हैडर

Authorization: account-id HMAC_OF_WITH_SECRET_KEY(data + account-id + GMT Date that will be in date header) 

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

यह तंत्र प्रमाणीकरण के साथ-साथ डेटा अखंडता को भी शामिल करता है।

Answer 2

ग्राहक को अपने एप्लिकेशन स्पेस में टोकन को सुरक्षित रूप से स्टोर करने की आवश्यकता है। यह टोकन को आगे एन्क्रिप्ट करने का चयन कर सकता है।

कुकी टोकन स्टोर करने के लिए भी एक जगह है लेकिन समस्या यह है कि कुछ ग्राहकों को कुकीज़ का लाभ नहीं होता है। तो सामान्य मामले के बारे में सोचो।