इस प्रश्न को, कुछ अलग रूप में, लंबाई में, यहाँ संबोधित किया गया है:
रेस्टफुल ऑथेंटिकेशन
लेकिन यह इसे सर्वर-साइड से संबोधित करता है। इसे क्लाइंट-साइड से देखते हैं। हालांकि, इससे पहले कि हम एक महत्वपूर्ण प्रस्तावना करें:
जावास्क्रिप्ट क्रिप्टो होपलेस है
इस पर माटसानो का लेख प्रसिद्ध है, लेकिन इसमें निहित पाठ काफी महत्वपूर्ण हैं:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
संक्षेप में:
- एक आदमी के बीच में हमला तुच्छ रूप से आपके क्रिप्टो कोड को बदल सकता है
<script>
function hash_algorithm(password){ lol_nope_send_it_to_me_instead(password); }</script>
- एक मानव-में-मध्य हमला एक ऐसे पृष्ठ के खिलाफ तुच्छ है जो गैर-एसएसएल कनेक्शन पर किसी भी संसाधन का काम करता है।
- एक बार जब आपके पास एसएसएल होता है, तो आप वास्तविक क्रिप्टोकरंसी का उपयोग कर रहे हैं।
और मेरी खुद की एक कोरोलरी जोड़ने के लिए:
- एक सफल XSS हमले का परिणाम आपके क्लाइंट के ब्राउज़र पर कोड को निष्पादित करने में परिणाम हो सकता है, भले ही आप एसएसएल का उपयोग कर रहे हों - इसलिए भले ही आपने हर हैच को नीचे गिरा दिया हो, आपका ब्राउज़र क्रिप्टो अभी भी विफल हो सकता है यदि आपके हमलावर को निष्पादित करने का एक तरीका मिल जाए। किसी और के ब्राउज़र पर कोई जावास्क्रिप्ट कोड।
यदि आप एक जावास्क्रिप्ट क्लाइंट का उपयोग करने का इरादा कर रहे हैं, तो यह असंभव या मूर्खतापूर्ण कई विश्वसनीय योजनाओं को प्रस्तुत करता है। चलो देखते हैं!
HTTP मूल प्रामाणिक
सबसे पहले और सबसे महत्वपूर्ण, HTTP बेसिक प्रामाणिक। योजनाओं का सबसे सरल: बस हर अनुरोध के साथ एक नाम और पासवर्ड पास करें।
यह, निश्चित रूप से, SSL की आवश्यकता है, क्योंकि आप प्रत्येक अनुरोध के साथ Base64 (प्रतिवर्ती) एन्कोडेड नाम और पासवर्ड पास कर रहे हैं। लाइन पर सुनने वाला कोई भी उपयोगकर्ता नाम और पासवर्ड तुच्छ तरीके से निकाल सकता है। "बेसिक ऑथेंट असुरक्षित है" के अधिकांश तर्क "बेसिक ऑथेंट ओवर एचटीटीपी" की जगह से आते हैं जो एक भयानक विचार है।
ब्राउज़र बेक्ड-इन HTTP बेसिक ऑथेंट सपोर्ट प्रदान करता है, लेकिन यह बदसूरत पाप के रूप में है और शायद आपको इसे अपने ऐप के लिए उपयोग नहीं करना चाहिए। विकल्प, हालांकि, जावास्क्रिप्ट में उपयोगकर्ता नाम और पासवर्ड को छिपाने के लिए है।
यह सबसे Restful समाधान है। सर्वर को राज्य के बारे में कोई जानकारी की आवश्यकता नहीं है और उपयोगकर्ता के साथ प्रत्येक व्यक्तिगत बातचीत को प्रमाणित करता है। कुछ REST उत्साही (ज्यादातर स्ट्रोमैन) जोर देते हैं कि किसी भी प्रकार की स्थिति बनाए रखना विधर्म है और यदि आप किसी अन्य प्रमाणीकरण विधि के बारे में सोचते हैं तो मुंह में झाग आएगा। इस तरह के मानकों-अनुपालन के लिए सैद्धांतिक लाभ हैं - यह अपाचे द्वारा समर्थित है बॉक्स से बाहर - आप अपनी वस्तुओं को स्टोर कर सकते हैं जैसे कि .htaccess फ़ाइलों द्वारा संरक्षित फ़ोल्डर में यदि आपका दिल चाहे!
समस्या ? आप क्लाइंट-साइड पर एक उपयोगकर्ता नाम और पासवर्ड को कैशिंग कर रहे हैं। यह बुराई को इस पर एक बेहतर दरार देता है - यहां तक कि एक्सएसएस कमजोरियों का सबसे बुनियादी परिणाम क्लाइंट को अपने उपयोगकर्ता नाम और पासवर्ड को एक बुराई सर्वर पर बीम करने में हो सकता है। आप हैशिंग और पासवर्ड को सलाम करके इस जोखिम को कम करने की कोशिश कर सकते हैं, लेकिन याद रखें: जावास्क्रिप्ट क्रिप्टो होपलेस है । आप इस जोखिम को ब्राउज़र की मूल प्रामाणिक सहायता तक छोड़ सकते हैं, लेकिन .. बदसूरत पाप के रूप में, जैसा कि पहले उल्लेख किया गया है।
HTTP डाइजेस्ट प्रामाणिक
क्या jQuery के साथ डाइजेस्ट प्रमाणीकरण संभव है?
एक अधिक "सुरक्षित" स्थिति, यह एक अनुरोध / प्रतिक्रिया हैश चुनौती है। सिवाय जावास्क्रिप्ट क्रिप्टो के होपलेस है , इसलिए यह केवल एसएसएल पर काम करता है और आपको अभी भी क्लाइंट साइड पर उपयोगकर्ता नाम और पासवर्ड को कैश करना होगा, जिससे यह एचटीटीपी बेसिक ऑथेंट की तुलना में अधिक जटिल हो जाएगा लेकिन अधिक सुरक्षित नहीं है ।
अतिरिक्त हस्ताक्षर पैरामीटर्स के साथ क्वेरी प्रमाणीकरण।
एक और "सुरक्षित" स्थिति, जहां आप अपने पैरामीटर को नॉन और टाइमिंग डेटा (दोहराने और समय के हमलों से बचाने के लिए) के साथ एन्क्रिप्ट करते हैं और भेजते हैं। इसका एक सबसे अच्छा उदाहरण OAuth 1.0 प्रोटोकॉल है, जो है, जहां तक मुझे पता है, एक REST सर्वर पर प्रमाणीकरण को लागू करने का एक सुंदर तरीका है।
http://tools.ietf.org/html/rfc5849
ओह, लेकिन जावास्क्रिप्ट के लिए कोई OAuth 1.0 ग्राहक नहीं हैं। क्यों?
जावास्क्रिप्ट क्रिप्टो होपलेस है , याद रखें। जावास्क्रिप्ट SSL के बिना OAuth 1.0 में भाग नहीं ले सकता है, और आपको अभी भी ग्राहक के उपयोगकर्ता नाम और पासवर्ड को स्थानीय रूप से संग्रहीत करना होगा - जो इसे उसी श्रेणी में रखता है जैसे कि डाइजेस्ट ऑथेंट - यह HTTP बेसिक ऑथेंट की तुलना में अधिक जटिल है लेकिन यह अधिक सुरक्षित नहीं है ।
टोकन
उपयोगकर्ता एक उपयोगकर्ता नाम और पासवर्ड भेजता है, और बदले में एक टोकन मिलता है जिसका उपयोग अनुरोधों को प्रमाणित करने के लिए किया जा सकता है।
यह HTTP बेसिक ऑथ की तुलना में थोड़ा अधिक सुरक्षित है, क्योंकि जैसे ही उपयोगकर्ता नाम / पासवर्ड लेनदेन पूरा होता है आप संवेदनशील डेटा को छोड़ सकते हैं। यह भी कम Restful है, क्योंकि टोकन "स्थिति" का गठन करते हैं और सर्वर कार्यान्वयन को अधिक जटिल बनाते हैं।
एसएसएल स्टिल
हालाँकि, यह है कि आपको अभी भी टोकन प्राप्त करने के लिए उस प्रारंभिक उपयोगकर्ता नाम और पासवर्ड को भेजना होगा। संवेदनशील जानकारी अभी भी आपके समझौता योग्य जावास्क्रिप्ट को छूती है।
अपने उपयोगकर्ता की साख बचाने के लिए, आपको अभी भी अपने जावास्क्रिप्ट से हमलावरों को बाहर रखने की आवश्यकता है, और आपको अभी भी तार पर एक उपयोगकर्ता नाम और पासवर्ड भेजने की आवश्यकता है। एसएसएल आवश्यक है।
टोकन एक्सपायरी
यह टोकन नीतियों को लागू करने के लिए आम है जैसे "हे, जब यह टोकन बहुत लंबा हो गया है, तो इसे छोड़ दें और उपयोगकर्ता को फिर से प्रमाणित करें।" या "मुझे पूरा यकीन है कि इस टोकन का उपयोग करने के लिए केवल आईपी पते की अनुमति है XXX.XXX.XXX.XXX"। इनमें से कई नीतियां बहुत अच्छे विचार हैं।
Firesheeping
हालाँकि, बिना SSL के एक टोकन का उपयोग करना अभी भी 'साइडजैकिंग' नामक हमले के लिए असुरक्षित है: http://codebutler.github.io/firesheep/
हमलावर को आपके उपयोगकर्ता की विश्वसनीयता नहीं मिलती है, लेकिन वे अभी भी आपके उपयोगकर्ता होने का दिखावा कर सकते हैं, जो बहुत बुरा हो सकता है।
tl; dr: वायर पर बिना लाइसेंस के टोकन भेजने का मतलब है कि हमलावर उन टोकन को आसानी से पकड़ सकते हैं और आपके उपयोगकर्ता होने का दिखावा कर सकते हैं। फायरशीप एक ऐसा कार्यक्रम है जो इसे बहुत आसान बनाता है।
एक अलग, अधिक सुरक्षित क्षेत्र
जितना बड़ा एप्लिकेशन आप चला रहे हैं, उतना ही कठिन यह सुनिश्चित करना है कि वे कुछ कोड को इंजेक्ट नहीं कर पाएंगे जो आपको संवेदनशील डेटा को संसाधित करने के तरीके में बदलाव करता है। क्या आपको अपने CDN पर पूरा भरोसा है? आपके विज्ञापनदाता? आपका अपना कोड आधार?
क्रेडिट कार्ड के विवरण के लिए सामान्य और उपयोगकर्ता नाम और पासवर्ड के लिए कम सामान्य - कुछ कार्यान्वयनकर्ता अपने शेष एप्लिकेशन से एक अलग पृष्ठ पर 'संवेदनशील डेटा प्रविष्टि' रखते हैं, एक ऐसा पृष्ठ जिसे यथासंभव नियंत्रित किया जा सकता है और यथासंभव लॉक किया जा सकता है, अधिमानतः एक के साथ उपयोगकर्ताओं को फ़िश करना मुश्किल है।
कुकी (बस का अर्थ है टोकन)
एक कुकी में प्रमाणीकरण टोकन डालना संभव (और सामान्य) है। यह टोकन के साथ किसी भी गुण को नहीं बदलता है, यह एक सुविधा की बात है। पिछले तर्कों के सभी अभी भी लागू होते हैं।
सत्र (अभी भी सिर्फ टोकन का मतलब है)
सेशन ऑथोर सिर्फ टोकन ऑथेंटिकेशन है, लेकिन कुछ अंतरों के साथ जो इसे थोड़ा अलग लगता है:
- उपयोगकर्ता एक अनधिकृत टोकन के साथ शुरू करते हैं।
- बैकएंड एक 'राज्य' ऑब्जेक्ट को बनाए रखता है जो एक उपयोगकर्ता टोकन से बंधा होता है।
- एक कुकी में टोकन दिया गया है।
- अनुप्रयोग वातावरण आपके विवरण को अलग करता है।
इसके अलावा, हालांकि, यह टोकन प्रामाणिक से अलग नहीं है, वास्तव में।
यह एक भयावह कार्यान्वयन से आगे भी भटकता है - राज्य वस्तुओं के साथ आप एक स्टेटफुल सर्वर पर सादे ol 'RPC के पथ से आगे और आगे जा रहे हैं।
OAuth 2.0
OAuth 2.0 की समस्या "सॉफ्टवेयर ए कैसे सॉफ्टवेयर बी को उपयोगकर्ता एक्स के डेटा के बिना उपयोगकर्ता बी के उपयोगकर्ता एक्स के लॉगिन क्रेडेंशियल्स तक पहुंच के बिना एक्सेस देता है।"
किसी उपयोगकर्ता के लिए टोकन प्राप्त करने के लिए कार्यान्वयन केवल एक मानक तरीका है, और फिर "हां, इस उपयोगकर्ता और इस टोकन मिलान" के लिए एक तृतीय पक्ष सेवा के लिए, और आप अभी से उनके कुछ डेटा प्राप्त कर सकते हैं।
मौलिक रूप से, हालांकि, OAuth 2.0 सिर्फ एक टोकन प्रोटोकॉल है। यह अन्य टोकन प्रोटोकॉल के समान गुण प्रदर्शित करता है - आपको अभी भी उन टोकन की सुरक्षा के लिए SSL की आवश्यकता है - यह सिर्फ उन टोकन को उत्पन्न करने के तरीके को बदलता है।
दो तरीके हैं जो OAuth 2.0 आपकी मदद कर सकते हैं:
- दूसरों को प्रमाणीकरण / सूचना प्रदान करना
- दूसरों से प्रमाणीकरण / सूचना प्राप्त करना
लेकिन जब यह नीचे आता है, तो आप बस ... टोकन का उपयोग कर रहे हैं।
अपने सवाल पर वापस
तो, जो प्रश्न आप पूछ रहे हैं, "क्या मुझे कुकी में अपना टोकन स्टोर करना चाहिए और क्या मेरे पर्यावरण के स्वचालित सत्र प्रबंधन को विवरणों का ध्यान रखना चाहिए, या क्या मुझे जावास्क्रिप्ट में अपना टोकन स्टोर करना चाहिए और उन विवरणों को स्वयं संभालना चाहिए?"
और जवाब है: जो कुछ भी आपको खुश करता है उसे करो ।
हालाँकि, स्वचालित सत्र प्रबंधन की बात यह है कि आपके लिए पर्दे के पीछे बहुत कुछ जादू है। अक्सर यह अपने आप को उन विवरणों के नियंत्रण में होने के लिए अच्छा है।
मैं 21 का हूं इसलिए एसएसएल हां है
अन्य उत्तर है: सब कुछ या ब्रिगेड के लिए https का उपयोग करें जो आपके उपयोगकर्ताओं के पासवर्ड और टोकन चुरा लेगा।