112

मैंने "JWT vs Cookie" के बारे में कुछ पोस्ट पढ़े, लेकिन उन्होंने मुझे केवल और अधिक भ्रमित किया ...

मैं कुछ स्पष्टीकरण चाहता हूं , जब लोग "टोकन-आधारित प्रमाणीकरण बनाम कुकीज़" के बारे में बात कर रहे हैं, तो यहां कुकीज़ केवल सत्र कुकीज़ का उल्लेख करती हैं ? मेरी समझ यह है कि कुकी एक माध्यम की तरह है , इसका उपयोग टोकन-आधारित प्रमाणीकरण को लागू करने के लिए किया जा सकता है (कुछ ऐसा है जो क्लाइंट की तरफ लॉग-इन उपयोगकर्ता की पहचान कर सकता है ) या एक सत्र-आधारित प्रमाणीकरण (ग्राहक पक्ष पर एक स्थिर स्टोर) सर्वर साइड पर सत्र जानकारी से मेल खाता है )
हमें JSON वेब टोकन की आवश्यकता क्यों है ? मैं मानक-आधारित प्रमाणीकरण को लागू करने के लिए मानक कुकी का उपयोग कर रहा था ( सत्र आईडी का उपयोग नहीं कर रहा, सर्वर मेमोरी या फ़ाइल संग्रहण का उपयोग नहीं कर रहा था ): Set-Cookie: user=innocent; preferred-color=azureऔर एकमात्र अंतर जो मैंने देखा कि जेडब्ल्यूटी में पेलोड और हस्ताक्षर दोनों शामिल हैं ... जबकि आप चुन सकते हैं http हैडर के लिए हस्ताक्षरित या प्लेनटेक्स्ट कुकी के बीच । मेरी राय में हस्ताक्षरित कुकी ( cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM') अधिक स्थान कुशल है, एकमात्र दोष यह है कि ग्राहक टोकन को नहीं पढ़ सकता है, केवल सर्वर ही कर सकता है ... लेकिन मुझे लगता है कि यह ठीक है क्योंकि जेडडब्ल्यूटी में दावा करना वैकल्पिक है, यह टोकन के लिए आवश्यक नहीं है सार्थक हो

165

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

यह सुविधा कुकीज़ को वेबसाइटों को सुरक्षित करने का एक अच्छा तरीका बनाती है, जहां उपयोगकर्ता लिंक का उपयोग करके पृष्ठों के बीच लॉग इन और नेविगेट करता है।

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

मान लीजिए कि https://www.example.com पर वेब साइट प्रमाणित उपयोगकर्ताओं को उपयोगकर्ता नाम या पुराने पासवर्ड की आवश्यकता के बिना POSTनए पासवर्ड को https://www.example.com/changepassword पर नया पासवर्ड बदलकर पोस्ट करने की अनुमति देती है ।

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

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

इसके अलावा, कुकीज़ आपके एपीआई का उपभोग करने के लिए गैर-ब्राउज़र आधारित अनुप्रयोगों (जैसे मोबाइल से टैबलेट ऐप) के लिए और अधिक कठिन बनाती हैं।

— MvdD
स्रोत

6

"यदि आप तब भी उस वेबसाइट में लॉग इन होते हैं जब आप किसी दुर्भावनापूर्ण वेबसाइट पर जाते हैं जो आपके ब्राउज़र में एक पेज लोड करता है जो उस पते पर एक पोस्ट को ट्रिगर करता है, तो आपका ब्राउज़र विश्वासपूर्वक प्रमाणीकरण कुकीज़ संलग्न करेगा, जिससे हमलावर को आपका पासवर्ड बदलने की अनुमति मिलती है।" क्या कॉर्स इसे नहीं रोकता है?

— kbuilds

17

@kbuilds केवल दुर्भावनापूर्ण पेज है AJAX का उपयोग फॉर्म को पोस्ट करने के लिए। यदि हमलावर आपको नियमित रूप से सबमिट बटन पर क्लिक करने के लिए मिलता है, तो CORS खेलने में नहीं आता है।

— MvdD

3

लेकिन इसका मतलब यह नहीं है कि साइट केवल असुरक्षित होगी अगर कोई सीएसआरएफ टोकन का उपयोग नहीं किया जा रहा था?

— १

5

सही, आप CSRF टोकन का उपयोग करके CSRF हमलों को कम कर सकते हैं। लेकिन यह कुछ ऐसा है जो आपको स्पष्ट रूप से करना है।

— MvdD

2

कुकीज़ का उपयोग करना आपको XSS हमलों से बचाता है, हालांकि प्राधिकरण हेडर को सेट करने में सक्षम होने के लिए, आपको जावास्क्रिप्ट से एक्सेस टोकन तक पहुंचने की आवश्यकता है; CSRF से खुद को बचाना आसान है, लेकिन XSS से बचाव करना बहुत कठिन

— बीयर के

101

अवलोकन

जो आप पूछ रहे हैं वह क्लाइंट से सर्वर पर JSON वेब टोकन (JWTs) भेजने के लिए कुकीज़ और बियरर टोकन के बीच का अंतर है।

कुकीज़ और वाहक टोकन दोनों डेटा भेजते हैं।

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

उस डेटा को अक्सर JWT के रूप में एन्कोड किया जाता है।

कुकी

कुकी एक नाम-मूल्य जोड़ी है, जिसे एक वेब ब्राउज़र में संग्रहीत किया जाता है, और जिसमें एक समाप्ति तिथि और संबंधित डोमेन होता है।

हम कुकीज़ को वेब ब्राउजर में या तो जावास्क्रिप्ट के साथ या HTTP रिस्पांस हेडर के साथ स्टोर करते हैं।

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

वेब ब्राउज़र कुकी के डोमेन के लिए प्रत्येक अनुरोध के साथ स्वचालित रूप से कुकीज़ भेजता है।

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

बियरर टोकन

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

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

JWT और टोकन आधारित प्रमाणीकरण

जब हम टोकन-आधारित प्रमाणीकरण करते हैं, जैसे कि OpenID, OAuth, या OpenID कनेक्ट, हम एक विश्वसनीय प्राधिकरण से एक access_token (और कभी-कभी id_token) प्राप्त करते हैं। आमतौर पर हम इसे संग्रहीत करना चाहते हैं और इसे संरक्षित संसाधनों के लिए HTTP अनुरोधों के साथ भेजते हैं। हम यह कैसे करे?

विकल्प 1 एक कुकी में टोकन (ओं) को संग्रहीत करना है। यह स्टोरेज को हैंडल करता है और Cookieप्रत्येक अनुरोध के हेडर में सर्वर पर टोकन (ओं) को स्वचालित रूप से भेजता है । सर्वर तब कुकी को पार्स करता है, टोकन जांचता है, और उसी के अनुसार प्रतिक्रिया करता है।

एक अन्य विकल्प टोकन को स्थानीय / सत्र भंडारण में संग्रहीत करना है, और फिर मैन्युअल रूप Authorizationसे प्रत्येक अनुरोध के हेडर को सेट करना है । इस मामले में, सर्वर हेडर को पढ़ता है और कुकी के समान ही आगे बढ़ता है।

यह अधिक जानने के लिए लिंक किए गए RFC को पढ़ने लायक है।

— शॉन लुट्टिन
स्रोत

22

MvdD ने कुकीज़ को स्वचालित रूप से भेजे जाने के बारे में क्या कहा है:

एक कुकी एक माध्यम हो सकता है, लेकिन इसका सबसे महत्वपूर्ण कार्य यह है कि यह ब्राउज़र के साथ कैसे इंटरैक्ट करता है। कुकीज़ सर्वर द्वारा निर्धारित की जाती हैं और बहुत विशिष्ट तरीकों से अनुरोधों में भेजी जाती हैं। दूसरी ओर JWT विशेष रूप से एक माध्यम है, यह एक विशेष संरचना में कुछ तथ्यों का एक जोर है। यदि आप इतने इच्छुक थे, तो आप अपने प्रमाणीकरण कुकी के रूप में एक JWT डाल सकते हैं। जब आप उनकी तुलना करते हुए लेख पढ़ते हैं, तो वे आम तौर पर एक प्रमाणीकरण कुकी बनाम फ्रंट एंड कोड द्वारा एक जेडब्ल्यूटी का उपयोग करने के बारे में बात कर रहे होते हैं, जो एक प्रमाणीकरण कुकी के पीछे होता है, जो पिछले छोर पर कुछ कैश्ड सत्र या उपयोगकर्ता डेटा से मेल खाती है।
जेडब्ल्यूटी कई विशेषताएं प्रदान करता है, और उन्हें एक मानक में रखता है ताकि उनका उपयोग पार्टियों के बीच किया जा सके। एक JWT कई अलग-अलग स्थानों में कुछ तथ्यों के हस्ताक्षर किए गए दावे के रूप में कार्य कर सकता है। एक कुकी, चाहे आप इसमें कितना भी डेटा डालें या यदि आप इसे साइन करते हैं, तो वास्तव में केवल ब्राउज़र और विशिष्ट बैक एंड के बीच उपयोग करने के लिए समझ में आता है। JWT का उपयोग ब्राउज़र से बैक एंड के लिए किया जा सकता है, विभिन्न पार्टियों द्वारा नियंत्रित बैक एंड के बीच (OpenId Connect एक उदाहरण है), या किसी एक पार्टी के बैक एंड सेवाओं के भीतर। अपने हस्ताक्षरित कुकीज़ के अपने विशिष्ट उदाहरण के बारे में, आप संभवतः उसी कार्य को प्राप्त कर सकते हैं ("सेशन आईडी का उपयोग नहीं करते, सर्वर मेमोरी या फाइल स्टोरेज का उपयोग नहीं करते") उस उपयोग मामले में JWT के रूप में, लेकिन आप पुस्तकालयों और पीयर-रिव्यू से चूक जाते हैं मानक, CSRF मुद्दों के अलावा अन्य उत्तर के बारे में बात की।

संक्षेप में: जो पोस्ट आप पढ़ रहे हैं, वे शायद JWT की तुलना कर रहे हैं जो ब्राउजर से सर्वर प्रमाणीकरण प्रयोजनों के लिए प्रमाणीकरण टोकन के वाहक के रूप में है। लेकिन JWT बहुत कुछ कर सकता है, यह उपयोग के मामले में मानकीकरण और सुविधाओं के उपयोग के लिए लाता है जिनके बारे में आप शायद सोच रहे हैं।

— kag0
स्रोत

4

अच्छा काम यह स्पष्ट करता है कि तुलना वास्तव में बियरर टोकन और कुकीज़ के बीच है।

— शॉन लुटिन

14

हालांकि कुकीज़ अनुरोधों के साथ स्वचालित रूप से भेजे जाने के कारण CSRF हमलों के जोखिम को बढ़ा सकते हैं, वे HttpOnlyध्वज सेट होने पर XSS हमलों के जोखिम को कम कर सकते हैं , क्योंकि कोई भी स्क्रिप्ट जो पृष्ठ में इंजेक्ट की जाती है, वह पढ़ने में सक्षम नहीं होगी कुकी।

CSRF: एक उपयोगकर्ता एक हमलावर की साइट पर एक लिंक (या छवियों को देखता है) पर क्लिक करता है, जो ब्राउज़र को पीड़ित की साइट पर अनुरोध भेजने का कारण बनता है। यदि पीड़ित कुकीज़ का उपयोग करता है, तो ब्राउज़र स्वचालित रूप से कुकी को अनुरोध में शामिल करेगा, और यदि GET अनुरोध किसी भी गैर-पढ़ने के लिए केवल कार्रवाई का कारण बन सकता है, तो पीड़ित साइट हमले के लिए असुरक्षित है।

XSS: एक हमलावर पीड़ित साइट में एक स्क्रिप्ट एम्बेड करता है (पीड़ित साइट केवल कमजोर होती है यदि इनपुट सही तरीके से साफ नहीं किए जाते हैं), और हमलावर की स्क्रिप्ट कुछ भी कर सकती है जावास्क्रिप्ट को पृष्ठ पर करने की अनुमति है। यदि आप JWT टोकन को स्थानीय भंडारण में संग्रहीत करते हैं, तो हमलावर की स्क्रिप्ट उन टोकन को पढ़ सकती है, और उन टोकन को एक सर्वर पर भी भेज सकती है जिन्हें वे नियंत्रित करते हैं। यदि आप HttpOnlyध्वज के साथ कुकीज़ का उपयोग करते हैं , तो हमलावर की स्क्रिप्ट आपके कुकी को शुरू करने के लिए नहीं पढ़ पाएगी। उस ने कहा, जिस स्क्रिप्ट को उन्होंने सफलतापूर्वक इंजेक्ट किया था, वह अभी भी कुछ भी कर सकती है जावास्क्रिप्ट कर सकती है, इसलिए आप अभी भी आईएमओ (यानी, जबकि वे कुकी को पढ़ने में सक्षम नहीं हो सकते हैं, इसे बाद में उपयोग के लिए अपने स्वयं के सर्वर पर भेज सकते हैं। , वे एक्सएचआर (वीएचआर) का उपयोग करते हुए सतर्क साइट पर अनुरोध भेज सकते हैं , जिसमें वैसे भी कुकी शामिल होगी)।

— Cwa
स्रोत

2

रेफरी - JSON वेब टोकन की आवश्यकता

कुकीज़

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

कुकीज़ की कमियां

कुकीज़ / सत्र आईडी स्वयं निहित नहीं है। यह एक संदर्भ टोकन है। प्रत्येक सत्यापन के दौरान Gmail सर्वर को इसके अनुरूप जानकारी प्राप्त करने की आवश्यकता होती है।
कई एपीआई और सर्वरों को शामिल करने वाले माइक्रोसर्विस आर्किटेक्चर के लिए उपयुक्त नहीं है

जेडब्ल्यूटी

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

— बैटमैन उठता है
स्रोत

टोकन आधारित प्रमाणीकरण के लिए JWT बनाम कुकीज़