2017-02-22 5 views
14

मैं एक oAuth2 सर्वर विकसित कर रहा हूं और मैंने इस सवाल पर ठोकर खाई है।क्या एक ओथ सर्वर एक ही क्लाइंट अनुरोध के लिए समान पहुंच देना चाहिए?

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

क्या मुझे इसे उसी accessToken को बाद के लोगों पर पहले अनुरोध पर जेनरेट किया जाना चाहिए जब तक कि यह समाप्त नहीं हो जाता है या मुझे प्रत्येक अनुरोध पर नया accessToken जारी करना चाहिए?

एक ही टोकन भेजने का लाभ यह है कि मैं सर्वर पर किसी ग्राहक के पुराने और अप्रयुक्त टोकन नहीं छोड़ूंगा, एक वैध टोकन अनुमान लगाने की कोशिश कर रहे हमलावर के लिए विंडो को कम करना।

मुझे पता है कि मुझे चीजों को रेट-सीमित करना चाहिए और मैं इसे कर रहा हूं, लेकिन हजारों विभिन्न मशीनों से बड़े बोनेट के हमले के मामले में, कुछ सीमाएं तुरंत प्रभावी नहीं होंगी।

हालांकि, मुझे इस समाधान के डाउनसाइड्स के बारे में निश्चित नहीं है और यही कारण है कि मैं यहां आया था। क्या यह एक वैध समाधान है?

उत्तर

4

मैं कहूंगा - नहीं।

कारण:

  1. आप कभी प्राधिकरण सर्वर साइड पर सादे पाठ में पहुंच टोकन को संग्रहीत करना चाहिए। एक्सेस टोकन प्रमाण-पत्र हैं और इसे शेड किया जाना चाहिए। सल्टिंग आवश्यक नहीं हो सकता है क्योंकि वे तारों को उत्पन्न कर रहे हैं। OAuth RFC point 10.3 देखें।
  2. निर्भर करता है कि आप बाद के अनुरोधों को कैसे प्रबंधित करते हैं - एक हमलावर जो जानता है कि एक निश्चित संसाधन स्वामी आपकी सेवा का उपयोग कर रहा है और उपयोग किए गए क्लाइंट आईडी के लिए अनुरोध दोहराता है। इस तरह एक हमलावर संसाधन मालिक का प्रतिरूपण करने में सक्षम होगा। यदि आप वास्तव में एक ही टोकन वापस करते हैं तो कम से कम सुनिश्चित करें कि आप संसाधन मालिक को हर बार प्रमाणित करते हैं।
  3. "राज्य" पैरामीटर के बारे में क्या? यदि राज्य पैरामीटर अलग है तो क्या आप अनुरोधों को "समान" मानेंगे? यदि नहीं तो कोई बोनेट नेट हमले हर बार एक अलग राज्य का उपयोग करेगा और आपको नए टोकन जारी करने के लिए मजबूर करेगा।

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

+0

के बजाय AS के साथ टोकन संग्रहीत कर रहा हूं मैं आपके तीसरे बिंदु से भ्रमित हूं। ओपी में "राज्य" पैरामीटर का कोई उल्लेख नहीं है। मुझे नहीं लगता कि नया टोकन प्राप्त करने के लिए राज्य को पैरामीटर के रूप में भेजा जाएगा। –

+0

@ किरणशक्ति ग्राहक एक राज्य पैरामीटर भेजने या भेजने के लिए स्वतंत्र है। कॉन्फ़िगरेशन रीडायरेक्ट यूआरआई के प्रमाणीकरण अनुरोध के साथ पारित होने पर प्राधिकरण सर्वर को राज्य पैरामीटर भेजना होगा। Https://tools.ietf.org/html/rfc6749#section-4.2.2 देखें। तो यह प्रासंगिक है। – vap78

+0

बिंदु 2 में और अनुरोध हैं जहां प्रतिक्रिया समय धीमा हो सकता है। अगर मैं गलत हूं तो मुझे सही करें – Prageeth

3

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

+1

हालांकि नहीं सबसे अच्छा अभ्यास है, इस को देखने का एक और तरीका डी क्लाइंट –

1

आप अलगपहुँच टोकन भेज जब उचित प्रमाणीकरण के बाद का अनुरोध किया है और यह भी अपने पहुँच टोकन साथ ताज़ा टोकन भेज सकते हैं।

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

नकली के साथ हमले का विरोध करने के लिए टोकन रीफ्रेश करें, आपको कुछ चेतावनियों के बाद उन्हें अपने मूल आईपी के साथ ब्लैकलिस्ट करना चाहिए।

पीएस: पूर्वानुमानित टोकन का कभी भी उपयोग न करें। कम से कम पूरी तरह यादृच्छिक, लंबे अल्फा-न्यूमेरिक तारों का उपयोग करके बल के हमलों को क्रूर करना बेहद मुश्किल है। यदि आप php का उपयोग कर रहे हैं, तो मैं bin2hex(openssl_random_pseudo_bytes(512)) का सुझाव दूंगा। आप एक तरह से ':

2

के रूप में एक अंगूठे का नियम कुंजी पुन: उपयोग कभी नहीं, इस अतिरिक्त सुरक्षा के लिए बनाया गया सिस्टम में कुंजी पर कब्जा करने के मामले में लाना होगा

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