वसंत सुरक्षा

Question

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

हम उस सत्र/टोकन को रीफ्रेश करना चाहते हैं जब भी हम टोकन का उपयोग करके बैकएंड का अनुरोध करते हैं।

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

बात है: मैं यह ग्राहक ज़िम्मेदारी नहीं टोकन की अवधि समाप्त हो अपवाद और पुन: प्रमाणीकृत पकड़ने या एक ताज़ा समाप्ति टोकन से पहले शेड्यूल करने के लिए बनाने के लिए नहीं करना चाहती। मैं टोकन को खुद को रीफ्रेश करना चाहता हूं जब तक कि इसे सीमित समय के लिए उपयोग नहीं किया जाता - बस एक सत्र की तरह। (मैं इसे "डेटा" अनुरोध के साथ रीफ्रेश अनुरोध जारी नहीं करना चाहूंगा, हालांकि मुझे लगता है कि मुझे पढ़ना याद है, एक ताज़ा टोकन केवल एक बार वैध है ..?!)

क्या ऐसा करने का कोई तरीका है वसंत सुरक्षा में या क्या मुझे टोकन स्टोर के कुछ कस्टम कार्यान्वयन या मुझे जो भी भाग चुनना है, उसे बनाना होगा?

चूंकि मुझे वास्तव में कोई जवाब नहीं मिल रहा है (इसलिए पोस्ट) मैं सोच रहा हूं: शायद ऐसा करना बुद्धिमान नहीं है, हालांकि मैं क्यों नहीं सोच सकता। अगर मैं टोकन चुरा सकता हूं, तो मैं रीफ्रेश टोकन भी चुरा सकता हूं। तो मुझे लगता है कि मैं वास्तव में पहली जगह में एक ताज़ा टोकन होने में बात नहीं दिख रहा है ..

संपादित

ल्यूक टेलर के जवाब के जवाब में मैं अपने उपयोग के मामले clearify करेंगे।

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

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

Answer 1

मैं टोकन ही ताज़ा करने के लिए चाहते हैं जब तक यह किसी भी अधिक समय की एक सीमित मात्रा में करने के लिए नहीं किया जाता है - सिर्फ एक सत्र

यह वास्तव में मतलब नहीं है की तरह (एक OAuth2 संदर्भ में) । एक्सेस टोकन प्राधिकरण सर्वर द्वारा जारी किया जाता है, जो तय करता है कि यह कब तक मान्य है।यह संसाधन सर्वर पर "प्रयुक्त" है, जो प्रमाणीकरण सर्वर से पूरी तरह से अलग हो सकता है, इसलिए टोकन के जीवनकाल के साथ उपयोग को जोड़ने के लिए OAuth2 में कोई सुविधा नहीं है। सिद्धांत में यह एक साथ कुछ हैक करना संभव होगा जिसने यह काम किया है, लेकिन यह एक बुरा विचार की तरह लगता है।

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

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

यह आपके प्रश्न से वास्तव में स्पष्ट नहीं है कि आप OAuth2 का उपयोग क्यों कर रहे हैं। आपको इसे स्पष्ट करने के लिए शायद अपने प्रश्न का विस्तार करना चाहिए। यदि केवल एक ग्राहक और एक आरईएसटी सर्वर है, तो क्यों न केवल HTTPS पर बेसिक ऑथ की तरह कुछ उपयोग करें?

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