क्लाइंट एप्लिकेशन से उपयोगकर्ता प्रमाणीकरण कैसे प्राप्त करें?

Question

मैं एक एप्लिकेशन विकसित कर रहा हूं जो कई उपयोगकर्ताओं का समर्थन करेगा। बात यह है कि मैं ग्राहक / उपयोगकर्ता को प्रमाणित करने में असमर्थ हूं।

मैं http://quickblox.com/ की तरह एक ऐप बना रहा हूं, जहां मैं अपने उपयोगकर्ताओं को क्रेडेंशियल्स दूंगा और वे उन एन एप्लिकेशन को बनाने के लिए उपयोग करेंगे जिनमें वे प्रमाणित होने के लिए अपना उपयोगकर्ता नाम और पासवर्ड नहीं डाल सकते हैं।

मान लेते हैं कि यह अनुसरण करता है। (बस QuickBlox की तरह)

1. उपयोगकर्ता मेरी वेबसाइट पर खाता बनाता है।
2. उपयोगकर्ता एन एपीआई कुंजी बना सकते हैं और क्रेडेंशियल्स स्रावित कर सकते हैं। (कई ऐप्स के लिए)
3. मेरे REST एपीआई के साथ बात करने के लिए उपयोगकर्ता अपने एप्लिकेशन (Android, iOS, जावास्क्रिप्ट आदि ...) में इन क्रेडेंशियल्स का उपयोग करेंगे।
(REST API ने एक्सेस पढ़ा और लिखा है।)

मेरी चिंता?

उपयोगकर्ता अपने क्रेडेंशियल (एपीआई कुंजी और सीक्रेट कुंजी) का निर्माण उन अनुप्रयोगों में करेंगे, अगर किसी को ये चाबियां मिलती हैं और उपयोगकर्ता की नकल करने की कोशिश करते हैं? (APK विघटित करके या सीधे जावास्क्रिप्ट कोड में देख रहे हैं।

क्या मैं कहीं पर गलत हूं?
मैं इस तीन स्तरीय उपयोगकर्ता तंत्र के वास्तुकार के लिए उलझन में हूँ।

Comments

जिस चीज को आप करने की कोशिश करते दिख रहे हैं वह संभव नहीं है।

— user253751

वहाँ कई अनुप्रयोग हैं जो एक ही काम करता है। मुझे यकीन नहीं है कि वे उपयोगकर्ताओं को कैसे प्रमाणित करते हैं।

— आलोक पटेल

क्या आप क्लाइंट एप्लिकेशन या उपयोगकर्ता को प्रमाणित करने का प्रयास कर रहे हैं ? बहुत सारे ऐप उपयोगकर्ताओं को प्रमाणित करते हैं। उनमें से कोई भी क्लाइंट एप्लिकेशन को अटूट तरीके से प्रमाणित नहीं करता है।

— user253751

हाँ ग्राहक द्वारा मेरा मतलब है कि मैं केवल उपयोगकर्ता को प्रमाणित करना चाहता हूं।

— आलोक पटेल

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

— user253751

Answer 1

मैं पिछले कुछ सालों से REST API को डिजाइन कर रहा हूं। आप बहुत ज्यादा चिंता कर रहे हैं। हाल ही में इस बोर्ड के एक अन्य उपयोगकर्ता ने एक सवाल पूछा है, जहां वह अपने जावास्क्रिप्ट क्लाइंट-साइड कोड में यूआरआई एंडपॉइंट्स को संग्रहीत करने के बारे में चिंतित था ।

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

मूल उत्तर से उद्धरण:

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

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

आपको अपने एप्लिकेशन एक्सेस टोकन को केवल उन ऑपरेशंस की अनुमति देने के लिए डिज़ाइन करना चाहिए जिन्हें आप अनुमति देना चाहते हैं। आपके पास पहुँच टोकन के दो प्रकार हो सकते हैं:

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

---

लेकिन क्या कोई स्रोत कोड को डिकंस्ट्रक्ट करता है, आवेदन से टोकन लेता है, पता करता है कि सार्वजनिक एंडपॉइंट्स क्या हैं और आपकी वेब सेवा का दुरुपयोग करते हैं?

जब तक आप सीधे अपने एपीआई का उपभोग करने वाले अनुप्रयोगों के विकास का प्रबंधन नहीं कर रहे हैं, तब तक कुछ भी वास्तव में लोगों को आपके एपीआई को सीधे ऐप से उसी तरह दुरुपयोग करने से रोकता है।

Comments

अच्छी व्याख्या अब तक, मैं एक सवाल है, हालांकि। मान लें कि मेरा एक एपीआई मेरे उपयोगकर्ता के सभी संबंधित डेटा (ए + बी) लाने के लिए है । मेरा उपयोगकर्ता केवल अपने उपयोगकर्ता के filtered data(बी) प्राप्त करने के लिए अपने ऐप में इस एपीआई का उपयोग करता है । अब यह संभव है, या मेरे उपयोगकर्ता के सभी डेटा (ए + बी) को चोरी करने के लिए तीसरे उपयोगकर्ता को रोकने के लिए कोई समाधान है । क्या इस का कोई मतलब निकलता है?

— आलोक पटेल

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

— एंडी

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

— आलोक पटेल

क्या आप मुझे अपनी यह बात समझा सकते हैं? जब तक आप सीधे अपने एपीआई का उपभोग करने वाले अनुप्रयोगों के विकास का प्रबंधन नहीं कर रहे हैं

— आलोक पटेल

@AlokPatel मेरा क्या मतलब है, अभी आप चिंता कर रहे हैं कि आप किसी को एपीआई तक पहुंच दें, वे पहुंच वितरित कर सकते हैं और एपीआई का दुरुपयोग करना शुरू कर सकते हैं। यदि आपके एपीआई का उपभोग करने वाले अनुप्रयोगों के विकास पर आपका कोई नियंत्रण नहीं है, तो वे स्वयं भी ऐसा कर सकते हैं।

— एंडी

Answer 2

आपकी समस्या एक तकनीकी एक व्यवसाय के रूप में इतनी अधिक नहीं है।

कहते हैं कि आपके पास आपका एपीआई है, जिसे आप अपने ग्राहकों (ऐप डेवलपर्स) को £ 100 की एक फ्लैट दर, असीमित एक्सेस के लिए बेचते हैं।

ठीक है, तो जाहिर है, मैं £ 100 पर आपकी सेवा खरीद सकता हूं और इसे $ 50 प्रत्येक पर 10 लोगों को बेच सकता हूं। आप ऐसा नहीं चाहते हैं! इसलिए आप एक प्रतिबंध के बारे में सोचने की कोशिश करते हैं जो आपको मध्यस्थता के लिए खुले रहने के बिना अपने एपीआई को बेचने देगा।

• यदि आप केवल ऐप्स की संख्या को प्रतिबंधित करते हैं, तो ग्राहक एक एकल ऐप बना सकता है जो अन्य ऐप से कनेक्शन स्वीकार करता है और उन्हें पास करता है।

• यदि आप उपयोगकर्ताओं को फिर से सीमित करते हैं, तो ग्राहक अपने प्रमाणीकरण के पीछे उपयोगकर्ताओं को छिपा सकता है और एकल उपयोगकर्ता बन सकता है।

आपको जो करने की आवश्यकता है वह आपके ग्राहक को प्रत्येक एपीआई कॉल की लागत को पास करने की है। यानी प्रति एपीआई कॉल का शुल्क, या प्रति वर्ष कॉल का कोटा निर्धारित करें।

यह आपके ग्राहकों की मध्यस्थता की इसी समस्या को आगे बढ़ाता है। यह उन्हें अपने उपयोगकर्ताओं को उनकी चाबियाँ चुराने से रोकने के लिए जगह मापने के लिए मजबूर करता है। इस मामले में, अपने आपी को अपने स्वयं के उपयोगकर्ता प्रमाणित एपीआई के पीछे छिपाते हुए।

Comments

मैंने पहले से ही एपीआई की संख्या के आधार पर अपने एपीआई के उपयोग को सीमित करने की योजना बनाई है, इसलिए इस समय व्यवसाय से संबंधित समस्या मेरी चिंता का विषय नहीं है, मैं केवल चाबी चोरी होने से चिंतित हूं।

— आलोक पटेल

व्यापार की दृष्टि से, समस्या असहनीय है। अफसोस की बात है, आप इसे प्रोग्रामेटिक रूप से हल नहीं कर सकते।

— एंडी

प्रति कॉल चार्ज करके व्यापारिक समस्याएं। यदि कुंजी चोरी हो जाती है तो आपका ग्राहक खो देता है। तुम नहीं। बस अपने ग्राहक को चोरी की चाबियों को रद्द करने का तरीका दें और दुर्व्यवहार को रोकने के लिए एक इंटरमीडिएट एपीआई करने के लिए कहें

— इवान

Answer 3

अन्य जवाबों से लगता है कि उपभोक्ता उपकरणों पर एक ऐप में एक गुप्त भंडारण की समस्या हल नहीं है।

यकीन से यही है।

दो सिद्धांत (कार्यान्वयन विवरण का पालन करेंगे):

1. वास्तविक प्रमाणीकरण अंत बिंदुओं को गुमनाम रूप से जनता के लिए खुला होना चाहिए।
2. सर्वर को किसी तरह क्लाइंट को प्रमाणित करने और एक एपीआई कुंजी प्रदान करने में शामिल होना चाहिए।

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

आपको समय-समय पर टोकन को "ताज़ा" करने के लिए एक तंत्र की आवश्यकता होगी, जिसका अर्थ है, एक नया प्राप्त करें। केवल एक REST समापन बिंदु बनाएँ, जो किसी मौजूदा से नया टोकन बनाने की अनुमति देता है, ताकि क्रेडेंशियल से पुन: प्रमाणित होने से बचा जा सके।

यदि आप अंतिम उपयोगकर्ता को स्वयं को पुनः प्रमाणित करने से बचने की कोशिश कर रहे हैं, तो यह प्रमाणीकरण स्थापित होने पर ऐप में एक शुरुआती एक-बार सेटअप हो सकता है।

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

Comments

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

— न्यूटोपियन

यह सभी एपीआई का सच है। यदि कोई API उपभोक्ता इसका ठीक से उपभोग नहीं करता है, तो चीजें काम नहीं कर सकती हैं। यह एपीआई का एक प्रलेखित हिस्सा होना चाहिए।

— ब्रैंडन

वैसे, यह आसान बनाने में मदद करने के लिए मानक हैं, जैसे OAuth।

— ब्रैंडन

Answer 4

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

आपका सर्वर प्रत्येक क्लाइंट ऐप के लिए समय-समय पर (रोल) टोकन बदलता रहता है (समय-समय पर प्लस / माइनस कुछ रैंडम फ़ज़ी / रैंडम डिले, उदाहरण के लिए)। रोलिंग टोकन केवल सर्वर और प्रमाणित क्लाइंट के बीच जाना जाता है।

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

जब भी किसी क्लाइंट के साथ एक्सचेंज सिंक से बाहर हो जाता है (कुछ प्रकार की प्रोटोकॉल त्रुटि) तो आपका सर्वर पुनः प्रमाणीकरण का अनुरोध करेगा (अगले क्लाइंट अनुरोध के लिए एक त्रुटि उत्तर के माध्यम से, या ग्राहक के अनुरोध पर मान्य प्रतिक्रिया पर गुल्लक-समर्थित। उदाहरण)।

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

ग्राहक पक्ष पर टोकन को जारी रखने के लिए यह बेहतर होगा कि एक फिर से शुरू किया गया ग्राहक वहां से जारी रह सकता है जहां उसके पूर्ववर्ती ने छोड़ा - नकल के लिए उद्घाटन को काफी कम कर दिया।

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

Answer 5

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

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

Comments

जावास्क्रिप्ट के लिए चारों ओर काम क्या है? उसके लिए आर्किटेक्ट कैसे?

— आलोक पटेल

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

— अरुण

नहीं, ऐसा नहीं है। मैं तीसरा शीर्ष एपीआई प्रदाता होगा, मेरे उपयोगकर्ता अपने अनुप्रयोगों में मेरी एपीआई सेवा का उपयोग करेंगे। यह एंड्रॉइड, आईओएस, जावास्क्रिप्ट आदि हो सकता है ...

— आलोक पटेल

Answer 6

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

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

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

यह आपके प्रश्न के दायरे से थोड़ा भटक सकता है, लेकिन यह आपके टोकन की सुरक्षा से संबंधित है इसलिए मैं इसका उल्लेख करूंगा। तार पर टोकन की तुच्छ चोरी को रोकने के लिए, आप संभवतः सीधे टोकन नहीं भेजना चाहते हैं, इसके बजाय आप एचएमएसी फ़ंक्शन का उपयोग करके ट्रैफ़िक पर हस्ताक्षर कर सकते हैं। आप सर्वर पर संदेश के HMAC की गणना करके और क्लाइंट से भेजे गए HMAC के खिलाफ तुलना करके संदेश की वैधता की जांच कर सकते हैं। आप टोकन को HMAC फ़ंक्शन की कुंजी के रूप में उपयोग करेंगे, ताकि टोकन जानने वाला कोई व्यक्ति ट्रैफ़िक साइन कर सके। यह आपके टोकन की सुरक्षा के लिए बेहतर है क्योंकि आप इसे सीधे सर्वर पर नहीं भेजते हैं, इसलिए इसे सीधे इंटरसेप्ट और चोरी नहीं किया जा सकता है। HMACS की अधिक जानकारी के लिए यह प्रश्न देखें: /security/20129/how-and-when-do-i-use-hmac/20301

कोई भी सुरक्षा समाधान अभेद्य नहीं होगा, आपको यह तय करना होगा कि इस संभावना को लागू करने में आपको कितना खर्च आएगा और समझौता होने की लागत।

Comments

मैं एक पुस्तकालय नहीं बना सकता और इसमें रहस्य नहीं रख सकता, जो मेरे प्रत्येक उपयोगकर्ता के लिए अलग होंगे।

— आलोक पटेल

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

— thePragmatist

Answer 7

खुद को उद्धृत करना:

मैं यह पता लगाने में असमर्थ हूं कि क्लाइंट / उपयोगकर्ता को कैसे प्रमाणित किया जाए ... जिसमें वे प्रमाणित होने के लिए अपना उपयोगकर्ता नाम और पासवर्ड नहीं डाल सकते।

अब यह एक विरोधाभास सा है, है ना? ;)

जैसा कि दूसरों ने कहा, आप नहीं कर सकते। यदि कोई एप्लिकेशन API कुंजी का उपयोग करता है, तो कोई इसे कुंजी के रूप में उपयोग करने के लिए कह सकता है और इसे भी उपयोग कर सकता है।

अतिरिक्त उचित उपयोगकर्ता प्रमाणीकरण की आवश्यकता के अलावा, आप केवल नुकसान को सीमित कर सकते हैं:

• श्वेतसूची / आईपी को ब्लैक लिस्ट करना
• थ्रॉटलिंग
• "असामान्य गतिविधि" का पता लगाना और उसका स्रोत
• आसान कुंजी नवीकरण