क्या मोबाइल ऐप के लिए ओएथ 2 एक्सेस टोकन की समय सीमा समाप्त होनी है?

Question

यहाँ why OAuth2 access tokens expire के रूप में स्वीकार कर जवाब:

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

मानते हैं कि हम एक्सेस टोकन के गैर-एन्क्रिप्टेड ट्रांसमिशन का समर्थन नहीं करते हैं, पहले बुलेट बिंदु का ख्याल रखता है।

यह मानते हुए कि हम एक रद्द करने योग्य, पूरी तरह से यादृच्छिक पहुंच टोकन के खिलाफ डेटाबेस लुकअप करने के साथ ठीक हैं, दूसरे की देखभाल करता है।

मोबाइल ऐप्स के लिए, क्लाइंट प्रमाणीकरण मजबूत नहीं हो सकता है, क्योंकि "पंजीकरण के दौरान प्राप्त क्लाइंट_आईडी और क्लाइंट_सेक्रेट आपके आवेदन के स्रोत कोड में एम्बेडेड हैं। इस संदर्भ में, क्लाइंट_सेक्रेट को स्पष्ट रूप से एक रहस्य के रूप में नहीं माना जाता है।" (Google)। इससे तीसरी चिंता समाप्त हो जाती है।

तो इस परिदृश्य में अल्पकालिक पहुंच टोकन और लंबे समय तक रहने वाले ताज़ा टोकन को अलग करने का क्या फायदा है? क्या यह "ठीक है" केवल गैर-समाप्त होने वाली पहुंच टोकन जारी करने और पूरे ताज़ा टोकन भाग को अनदेखा करने के लिए है?

Answer 1

सुरक्षा के माध्यम से रीफ्रेश टोकन और गैर-समाप्ति पहुंच टोकन के बीच का अंतर प्राधिकरण सर्वर के लिए एक अतिरिक्त कॉल है।

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

हर बार एक रिफ्रेश टोकन का उपयोग करके आपके प्राधिकरण सर्वर से एक्सेस टोकन से अनुरोध किया जाता है, ओएथ 2 विनिर्देश (कम से कम अब के लिए नवीनतम ड्राफ्ट) यदि संभव हो तो सर्वर को check the client identity and if it is bound to the token पर सर्वर की आवश्यकता होती है।

चूंकि क्लाइंट गुप्त के साथ सामान्य दृष्टिकोण एक खुले प्लेटफॉर्म पर स्थापित अनुप्रयोग की निश्चित रूप से पहचान करने के लिए काम नहीं करता है, तो एप्लिकेशन चलाने वाले प्लेटफ़ॉर्म को ऐसा करने के तरीके प्रदान करना पड़ता है। Google उदा। एंड्रॉइड अनुप्रयोगों को डेवलपर द्वारा हस्ताक्षरित करने की आवश्यकता है। Google API Console का उपयोग कर एंड्रॉइड एप्लिकेशन के लिए क्रेडेंशियल्स का अनुरोध करते समय, आपको the fingerprint of the certificate you used for signing the application निर्दिष्ट करना होगा और केवल क्लाइंट आईडी प्राप्त करना होगा, लेकिन प्रतिक्रिया में कोई रहस्य नहीं है। टोकन जारी करने पर, Google तब निर्णय ले सकता है कि डेवलपर द्वारा एप्लिकेशन को टोकन का अनुरोध करने के लिए अधिकृत किया गया था या नहीं।

यदि आप निश्चित रूप से ग्राहक पहचान सत्यापित नहीं कर सकते हैं, तो कुछ मामलों में यह सुनिश्चित करना कम से कम संभव है कि रीफ्रेश टोकन चोरी हो गया हो। विनिर्देश एक example for this है:

जब क्लाइंट प्रमाणीकरण संभव नहीं है, प्राधिकरण सर्वर चाहिए अन्य साधनों ताज़ा टोकन दुरुपयोग का पता लगाने के तैनात।

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

Answer 2

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

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

Answer 3

ओएथ 2 एक्सेस टोकन की अवधि समाप्त होने की आवश्यकता नहीं है (या बल्कि वे करते हैं, लेकिन यह कई सालों से हो सकता है)।

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

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

बेयरर टोकन किसी भी अन्य प्रकार के टोकन प्रति से कमजोर नहीं हैं, जैसा कि कागजात के एक समूह में साबित होता है (जिसमें से मेरा एक भी है, जिसे मैं इसे खोदने के लिए लिंक पोस्ट करूंगा।) हालांकि, भालू टोकन केवल उन मामलों में उपयुक्त हैं जहां वे धारणाएं वैध हैं। धारणा है कि टोकन को गुप्त रखा जा सकता है, सामान्य रूप से भालू टोकन की प्राथमिक धारणा है। यदि यह सत्य नहीं है तो भालू टोकन किसी भी सुरक्षा गुणों पर जोर नहीं देते हैं (हालांकि कुछ अभी भी पकड़ते हैं)। NIST Level 3 tokens देखें, जो परिभाषित करता है कि कौन से हमले वाले टोकन को हारना चाहिए, जैसा कि एस OAuth Bearer Tokens में pecified। छोटे भालू टोकन में टोकन की चोरी को हराने के लिए नहीं माना जाता है।

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

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

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

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