अन्य एपीआई सुरक्षा संग्रहीत टोकन बनाम JWT बनाम OAuth


104

मैं अभी भी REST एपीआई की सुरक्षा के लिए सबसे अच्छा सुरक्षा समाधान खोजने की कोशिश कर रहा हूं, क्योंकि हर दिन मोबाइल एप्लिकेशन और एपीआई की मात्रा बढ़ रही है।

मैंने प्रमाणीकरण के विभिन्न तरीकों की कोशिश की है, लेकिन अभी भी कुछ गलतफहमियां हैं, इसलिए मुझे किसी और अनुभवी की सलाह की आवश्यकता है।

मुझे बताइए, मैं यह सब कैसे समझता हूं। अगर मैं कुछ गलत समझ रहा हूं, तो कृपया मुझे बताएं।

जहाँ तक REST API स्टेटलेस होने के साथ-साथ सामान्य रूप से WEB है, हमें प्रत्येक अनुरोध (कुकीज़, टोकन ....) में कुछ डेटा को भेजने की आवश्यकता है। मैं उपयोगकर्ता को प्रमाणित करने के लिए तीन व्यापक रूप से प्रयुक्त तंत्र जानता हूं

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

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

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

ऑनलाइन स्टोर के लिए मोबाइल क्लाइंट पर विचार करें।

पहला प्रश्न क्या मुझे पहले प्रकार के टोकन पर JWT पसंद करना चाहिए? जहां तक ​​मुझे मोबाइल क्लाइंट पर लॉगिन / लॉगआउट उपयोगकर्ता की आवश्यकता है, मुझे कहीं टोकन या JWT के मामले में स्टोर करने की आवश्यकता है, टोकन लॉगआउट पर अमान्य होना चाहिए। अमान्य टोकन सूची (काली सूची) बनाने के लिए टोकन को अमान्य करने के लिए विभिन्न तरीकों का उपयोग किया जाता है। हम्म। यदि तालिका में टोकन संग्रहीत किया गया था और उपयोगकर्ता के साथ जुड़ा हुआ था, तो टेबल / फ़ाइल का आकार बहुत बड़ा होगा।

तो JWT टोकन के क्या लाभ हैं?

OAuth के बारे में दूसरा प्रश्न, क्या मुझे अपने सर्वर के साथ सीधे संचार के मामले में इसका उपयोग करना चाहिए? केवल क्लाइंट और सर्वर के बीच टोकन जारी करने के लिए एक और परत का उद्देश्य क्या है, लेकिन संचार oauth सर्वर के साथ नहीं बल्कि मुख्य सर्वर के साथ होगा। जैसा कि मैं समझता हूं कि उपयोगकर्ता निजी जानकारी तक पहुंचने के लिए OAuth सर्वर केवल तृतीय-पक्ष एप्लिकेशन अनुमतियाँ (टोकन) देने के लिए जिम्मेदार है। लेकिन मेरा मोबाइल क्लाइंट एप्लिकेशन तृतीय-पक्ष नहीं है।


धन्यवाद, मैं हाल ही में यह सोच रहा था। मैं सत्र प्रबंधन (बीकर) के साथ गया, और एक घंटे के बाद सत्र टोकन हटा दिया। Oauth सही फिट नहीं लगता था।
जस्सोन्चैर

जवाबों:


86

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

सत्र आईडी / कुकीज़

पेशेवरों:

  • क्लाइंट और सर्वर दोनों को कोड करना आसान है।
  • जब कोई लॉग आउट करता है तो सत्र को नष्ट करना आसान होता है।

विपक्ष:

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

JSON वेब कैम (JWT)

दूसरे मामले में डेटा को एक JWT में संग्रहीत किया जाता है जो सर्वर के बजाय चारों ओर से गुजरता है।

पेशेवरों:

  • सर्वर साइड स्टोरेज समस्याएँ दूर हो गई हैं।
  • क्लाइंट साइड कोड आसान है।

विपक्ष:

  • JWT का आकार सत्र आईडी से बड़ा हो सकता है। यह नेटवर्क के प्रदर्शन को प्रभावित कर सकता है क्योंकि यह प्रत्येक HTTP अनुरोध के साथ शामिल है।
  • JWT में संग्रहीत डेटा क्लाइंट द्वारा पठनीय है। यह एक मुद्दा हो सकता है।
  • JWTs को जनरेट करने, वेरिफाई करने और पढ़ने के लिए सर्वर साइड को कोड की आवश्यकता होती है। यह कठिन नहीं है, लेकिन सीखने की अवस्था थोड़ी है और सुरक्षा इस पर निर्भर करती है।

    जो कोई भी हस्ताक्षर करने वाली कुंजी की प्रतिलिपि प्राप्त करता है, वह JWTs बना सकता है। आपको पता नहीं होगा कि ऐसा कब होता है।

    कुछ पुस्तकालयों में एक बग (था?) था जो किसी भी JWT को "कोई नहीं" एल्गोरिथ्म के साथ हस्ताक्षरित स्वीकार करता था ताकि कोई भी JWTs बना सके जिसे सर्वर भरोसा करेगा।

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

OAuth

अक्सर OAuth का उपयोग प्रमाणीकरण (यानी पहचान) के लिए किया जाता है, लेकिन इसका उपयोग अन्य डेटा को साझा करने के लिए किया जा सकता है जैसे उपयोगकर्ता द्वारा खरीदी गई सामग्री की सूची और डाउनलोड करने का हकदार है। इसका उपयोग तीसरे पक्ष द्वारा संग्रहीत डेटा को लिखने के लिए पहुंच प्रदान करने के लिए भी किया जा सकता है। आप उपयोगकर्ताओं को प्रमाणित करने के लिए OAuth का उपयोग कर सकते हैं और फिर सत्र डेटा के लिए सर्वर साइड स्टोरेज या JWT का उपयोग कर सकते हैं।

पेशेवरों:

  • उपयोगकर्ताओं के लिए अपना पासवर्ड साइनअप करने या रीसेट करने के लिए कोई कोड नहीं।
  • एक सत्यापन लिंक के साथ एक ईमेल भेजने और फिर पते को मान्य करने के लिए कोई कोड नहीं।
  • उपयोगकर्ताओं को किसी अन्य उपयोगकर्ता नाम और पासवर्ड को सीखने / लिखने की आवश्यकता नहीं है।

विपक्ष:

  • आप अपने उपयोगकर्ताओं को आपकी सेवा का उपयोग करने के लिए तीसरे पक्ष पर निर्भर करते हैं। यदि उनकी सेवा नीचे जाती है या वे इसे बंद कर देते हैं तो आपको कुछ और जानने की जरूरत है। उदाहरण: यदि उपयोगकर्ता की पहचान "foo@a.com" से "bar@b.com" में परिवर्तित हो जाती है, तो आप कैसे माइग्रेट करेंगे?
  • आमतौर पर आपको प्रत्येक प्रदाता के लिए कोड लिखना होगा। जैसे गूगल, फेसबुक, ट्विटर।
  • आपको या आपके उपयोगकर्ताओं को गोपनीयता की चिंता हो सकती है। प्रदाताओं को पता है कि उनके कौन से उपयोगकर्ता आपकी सेवा का उपयोग करते हैं।
  • आप प्रदाता पर भरोसा कर रहे हैं। एक प्रदाता के लिए टोकन जारी करना संभव है जो एक उपयोगकर्ता के लिए किसी और के लिए मान्य हैं। यह वैध उद्देश्यों के लिए हो सकता है या नहीं।

विविध

  • सत्र आईडी और JWTs दोनों को कई उपयोगकर्ताओं द्वारा कॉपी और उपयोग किया जा सकता है। आप क्लाइंट IP एड्रेस को JWT में स्टोर कर सकते हैं और इसे वैरिफाई कर सकते हैं लेकिन यह क्लाइंट को वाई-फाई से सेल्युलर तक घूमने से रोकता है।

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

5
मुझे नहीं पता कि यह स्वीकृत उत्तर क्यों है? यह असली सवाल का जवाब नहीं देता है, सिर्फ दूसरे तरीके से सवाल को सुधार रहा है
amd

1
आप कहते हैं: "JWT में संग्रहीत डेटा क्लाइंट द्वारा पठनीय है। यह एक मुद्दा हो सकता है .. अगर यह एक मुद्दा है तो JWE का उपयोग क्यों न करें?
सिल्वर

यह उत्तर सेब और संतरे को भ्रमित करता है। आपको OAuth 2.0 ("प्राधिकरण" कल्पना) के साथ इनकी तुलना नहीं करनी चाहिए। ओपी को किस बारे में जानना चाहिए: "रिसोर्स ओनर पासवर्ड फ्लो" - जो एक अनुदान के रूप में प्रमाणीकरण है।
ओनुर येल्ड्रिम

5

अपने आप से पूछें कि आपको मूल टोकन को अमान्य करने की आवश्यकता क्यों है।

एक उपयोगकर्ता लॉग इन करता है, एक टोकन उत्पन्न होता है और ऐप बंद हो जाता है।

उपयोगकर्ता लॉगआउट दबाता है, एक नया टोकन उत्पन्न होता है और मूल टोकन को बदल देता है। एक बार फिर, सब ठीक है।

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

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

आप मूल टोकन पर समाप्ति समय लगाकर खुद को कुछ अतिरिक्त सुरक्षा दे सकते हैं। तो अगर अंत में चोरी या कुछ किया जा रहा है, तो यह केवल थोड़े समय के लिए अच्छा होगा।

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


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

1
बुरा विचार, इसे बाद में हैकर द्वारा उपयोग किया जा सकता है, या बस मजबूर किया जा सकता है ...
सीआरएसपी

2
कल्पना कीजिए कि एक उपयोगकर्ता अन्य सभी उपकरणों से लॉगआउट करना चाहता है, JWT का उपयोग करना संभव नहीं है।
AMD

@dd संभव नहीं है? क्या होगा अगर मैं नॉन = (रैंडम) जोड़ता हूं और यदि उपयोगकर्ता लॉग आउट करता है, तो नॉन को बदलें। सरल और प्रभावी लगता है।
शमौन बी।

3

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

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


4
लेकिन फिर से यह इस मामले में राज्य-पूर्ण हो जाता है, इसलिए नमक बनाने या किसी अन्य दृष्टिकोण का उपयोग करने का क्या कारण है, आप तालिका में सरल स्टोर टोकन ले सकते हैं और जब इसे अमान्य किया जाना चाहिए तो हटा दें
CROSP

2
आप समय के आधार पर अमान्य भी कर सकते हैं।
रिबेल्डिडी

इस मामले में समाप्ति समय के बीच अंतर क्या है? जब उपयोगकर्ता मोबाइल क्लाइंट से लॉगआउट करना चाहता है तो मैं समय के आधार पर टोकन को कैसे अमान्य कर सकता हूं? ऐसा लगता है कि इस मामले में एपीआई का कोई रास्ता नहीं है। की तुलना में सबसे उपयुक्त और सुरक्षित उपाय क्या है?
CROSP

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

उत्तर के लिए धन्यवाद, लेकिन मुझे समझ नहीं आता कि मुझे इस मामले में OAuth का उपयोग क्यों करना चाहिए।
सीआरएसपी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.