टोकन प्रमाणीकरण बनाम कुकीज़


141

कुकीज़ का उपयोग करके टोकन प्रमाणीकरण और प्रमाणीकरण के बीच अंतर क्या है?

मैं एम्बर प्रामाणिक रेल्स डेमो को लागू करने की कोशिश कर रहा हूं, लेकिन मैं टोकन प्रमाणीकरण का उपयोग करने के पीछे के कारणों को समझ नहीं पा रहा हूं जैसा कि प्रश्न पर एम्बर प्रामाणिक प्रश्न "टोकन प्रमाणीकरण क्यों है?"


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

2
देखें लेख auth0.com/blog/cookies-vs-tokens-definitive-guide 2016 में लिखा
माइकल Freidgeim

जवाबों:


34

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

Ember.js में चीजें अलग हैं। क्योंकि यह वास्तव में रखती है Ember.js आसान प्रोग्रामर की नौकरी करता है राज्य आप के लिए, ग्राहक में, यह के बारे में हर पल जानने राज्य सर्वर के लिए पूछ के लिए एक अनुरोध बनाने के लिए बिना राज्य डेटा।

हालांकि, पकड़े राज्य क्लाइंट में भी कभी कभी संगामिति मुद्दों है कि बस में मौजूद नहीं हैं लागू कर सकते हैं राज्यविहीन स्थितियों। हालांकि, Ember.js आपके लिए इस मुद्दे से संबंधित है, विशेष रूप से ember-data को ध्यान में रखकर बनाया गया है। अंत में, Ember.js एक फ्रेमवर्क है जो स्टेटफुल क्लाइंट्स के लिए बनाया गया है।

Ember.js एक सामान्य स्टेटलेस वेब ऐप की तरह काम नहीं करता है जहाँ सत्र , राज्य और संबंधित कुकीज़ को सर्वर द्वारा लगभग पूरी तरह से संभाला जाता है। Ember.js यह धारण राज्य जावास्क्रिप्ट में पूरी तरह से (ग्राहक की स्मृति में, और कुछ अन्य फ्रेमवर्क की तरह डोम में नहीं) और सत्र का प्रबंधन करने के लिए सर्वर की जरूरत नहीं है। इसके परिणामस्वरूप Ember.js कई स्थितियों में अधिक बहुमुखी है, उदाहरण के लिए जब आपका ऐप ऑफ़लाइन मोड में है।

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

मेरी राय में, एम्बर प्रामाणिक एफएक्यू में बताए गए कुकीज़ के बजाय प्रमाणीकरण टोकन का उपयोग करने का मुख्य कारण मुख्य रूप से एम्बर.जेएस फ्रेमवर्क की प्रकृति के कारण है और यह भी क्योंकि यह स्टेटफुल वेब ऐप प्रतिमान के साथ अधिक फिट बैठता है । इसलिए Ember.js ऐप बनाते समय कुकी तंत्र सबसे अच्छा तरीका नहीं है।

मुझे आशा है कि मेरा उत्तर आपके प्रश्न को अधिक अर्थ देगा।


84
मुझे अभी भी समझ नहीं आया कि एक कुकी से टोकन बेहतर / अलग क्यों है। एक तरह से या किसी अन्य आप आपी सर्वर को कुछ भेज रहे हैं जो एक वैध सत्र की पहचान करता है। यह मानते हुए कि आप एक ही डोमेन पर सब कुछ चला रहे हैं (और भले ही एम्बर और आपी अलग-अलग सर्वरों पर हों, यह पूरा करने के लिए आपको एक सीडीएन के पीछे भागना होगा, जिसे आपको शायद वैसे भी करना चाहिए) क्या लाभ प्रदान करते हैं: वारंट अतिरिक्त सेटअप कार्य और समय के हमलों के लिए अतिरिक्त संवेदनशीलता?
माइकल जॉन्सटन

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

5
मैं यहां दोनों टिप्पणियों से सहमत हूं ... वास्तव में, मुझे लगता है कि पूरे "यह एम्बर तरीका है" एक पुलिस-आउट का थोड़ा सा है
ग्राफो

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

15
Ember.js का विज्ञापन उस सवाल पर केंद्रित न करें .. जो अशिष्ट हो।
Vick_Pk

336

Http स्टेटलेस है। आपको अधिकृत करने के लिए, आपको सर्वर पर आपके द्वारा भेजे जा रहे हर एक अनुरोध पर "हस्ताक्षर" करना होगा।

टोकन प्रमाणीकरण

  • सर्वर के लिए एक अनुरोध "टोकन" द्वारा हस्ताक्षरित है - आमतौर पर इसका अर्थ है विशिष्ट http हेडर सेट करना, हालांकि, उन्हें http अनुरोध (POST बॉडी, आदि) के किसी भी भाग में भेजा जा सकता है।

  • पेशेवरों:

    • आप केवल उन अनुरोधों को अधिकृत कर सकते हैं जिन्हें आप अधिकृत करना चाहते हैं। (कुकीज़ - यहां तक ​​कि प्राधिकरण कुकी को हर एक अनुरोध के लिए भेजा जाता है।)
    • XSRF के लिए Immune (XSRF का संक्षिप्त उदाहरण - मैं आपको ईमेल में एक लिंक भेजूंगा जो आपको पसंद आएगा <img src="http://bank.com?withdraw=1000&to=myself" />, और यदि आप bank.com में कुकी प्रमाणीकरण के माध्यम से लॉग इन हैं, और bank.com के पास XSRF का कोई साधन नहीं है सुरक्षा, मैं आपके खाते से केवल इस तथ्य से पैसे निकालूंगा कि आपका ब्राउज़र उस url के लिए अधिकृत GET अनुरोध को ट्रिगर करेगा।) ध्यान दें कि एंटी-वेरी माप है जो आप कुकी-आधारित प्रमाणीकरण के साथ कर सकते हैं - लेकिन आपको उन्हें लागू करना होगा।
    • कुकीज़ एकल डोमेन से बंधी हैं। डोमेन foo.com पर बनाई गई कुकी को डोमेन bar.com द्वारा पढ़ा नहीं जा सकता है, जबकि आप अपनी पसंद के किसी भी डोमेन को टोकन भेज सकते हैं। यह एकल पृष्ठ अनुप्रयोगों के लिए विशेष रूप से उपयोगी है जो कई सेवाओं का उपभोग कर रहे हैं जो प्राधिकरण की आवश्यकता होती है - इसलिए मैं डोमेन myapp.com पर एक वेब ऐप रख सकता हूं जो myservice1.com और myservice2.com के लिए अधिकृत क्लाइंट-साइड अनुरोध कर सकता है।
  • विपक्ष:
    • आपको टोकन को कहीं स्टोर करना होगा; जबकि कुकीज़ "बॉक्स से बाहर" संग्रहीत की जाती हैं। वे स्थान जो मन में आते हैं, वे स्थानीय हैं। अनाम) और कुकीज़ (प्रो: ब्राउज़र विंडो को बंद करने के बाद टोकन को छोड़ दिया जाता है। यदि आप एक सत्र कुकी का उपयोग करते हैं, तो एक नए टैब में लिंक खोलते समय आपको प्रमाणित किया जाएगा, और आप XSRF से प्रतिरक्षा कर रहे हैं क्योंकि आप अनदेखी कर रहे हैं। प्रमाणीकरण के लिए कुकी, आप इसे टोकन संग्रहण के रूप में उपयोग कर रहे हैं। Con: कुकीज़ को हर एक अनुरोध के लिए भेजा जाता है। यदि यह कुकी केवल https के रूप में चिह्नित नहीं है, तो आप मध्य हमलों में आदमी के लिए खुले हैं।)
    • टोकन आधारित प्रमाणीकरण के खिलाफ XSS हमला करना थोड़ा आसान है (यानी अगर मैं आपकी साइट पर एक इंजेक्टेड स्क्रिप्ट चलाने में सक्षम हूं, तो मैं आपका टोकन चुरा सकता हूं; हालांकि, कुकी आधारित प्रमाणीकरण या तो चांदी की गोली नहीं है - जबकि कुकीज़ के रूप में चिह्नित किया गया है। http-केवल ग्राहक द्वारा पढ़ा नहीं जा सकता है, ग्राहक अभी भी आपकी ओर से अनुरोध कर सकता है जो स्वचालित रूप से प्राधिकरण कुकी को शामिल करेगा।)
    • एक फ़ाइल डाउनलोड करने का अनुरोध, जो केवल अधिकृत उपयोगकर्ताओं के लिए काम करना है, आपको फ़ाइल एपीआई का उपयोग करने की आवश्यकता है। कुकी-आधारित प्रमाणीकरण के लिए समान अनुरोध बॉक्स से बाहर काम करता है।

कुकी प्रमाणीकरण

  • सर्वर के लिए एक अनुरोध हमेशा प्राधिकरण कुकी द्वारा हस्ताक्षरित होता है।
  • पेशेवरों:
    • कुकीज़ को "http-only" के रूप में चिह्नित किया जा सकता है जो उन्हें क्लाइंट साइड पर पढ़ना असंभव बनाता है। यह XSS- हमले से सुरक्षा के लिए बेहतर है।
    • बॉक्स से बाहर आता है - आपको क्लाइंट की तरफ कोई कोड लागू करने की आवश्यकता नहीं है।
  • विपक्ष:
    • एक एकल डोमेन के लिए बाध्य। (इसलिए यदि आपके पास एक एकल पृष्ठ अनुप्रयोग है जो कई सेवाओं के लिए अनुरोध करता है, तो आप एक रिवर्स की तरह पागल सामान कर सकते हैं।)
    • XSRF के लिए कमजोर। आपको अपनी साइट को क्रॉस साइट अनुरोध जालसाजी के खिलाफ संरक्षित करने के लिए अतिरिक्त उपायों को लागू करना होगा।
    • हर एक अनुरोध के लिए भेजा जाता है, (उन अनुरोधों के लिए भी जिन्हें प्रमाणीकरण की आवश्यकता नहीं होती है)।

कुल मिलाकर, मैं कहूंगा कि टोकन आपको बेहतर लचीलापन देते हैं, (क्योंकि आप एकल डोमेन के लिए बाध्य नहीं हैं)। नकारात्मक पक्ष यह है कि आपको खुद से काफी कुछ कोडिंग करनी होगी।


56
यह उत्तर स्वीकार किए जाते हैं की तुलना में एक विहित जवाब के करीब है।
xlecoustillier

3
धन्यवाद @ ondrej-svejdar यह अब तक का सबसे अच्छा जवाब है! मैं केवल "काफी कुछ कोडिंग" भाग के साथ बहस करूंगा। किसी भी भाषा के लिए बहुत अच्छी संख्या में पुस्तकालय उपलब्ध हैं। इसलिए जब तक आप वास्तव में जेडब्ल्यूटी कार्यान्वयन के यांत्रिकी को जानना चाहते हैं, तो खरोंच से शुरू करने की कोई आवश्यकता नहीं है।
फुलस्टैकफ़ॉगर

2
Are send out for every single requestटोकन हर अनुरोध के लिए भी भेजे जाते हैं
यूजेन कोनकोव

10
@EugenKonkov सं। आवश्यकता नहीं है। यदि आप शीर्ष लेख जोड़ते हैं। यदि आप चाहते हैं या नहीं चाहते हैं तो कुकीज़ ब्राउज़र से भेजी जाती हैं
रॉय नामीर

2
@Zack - यह मायने रखता है। कुकीज़ के साथ समस्या यह है कि वे ब्राउज़र द्वारा स्वचालित रूप से अनुरोध करने के लिए संलग्न हैं। दूसरी ओर टोकन को जावास्क्रिप्ट द्वारा XHR अनुरोध में जोड़ा जाता है। Evildomain.com के लिए mysite.com (btw) के लिए स्थानीय भंडारण तक पहुँच प्राप्त करना असंभव है। मैं स्थानीय स्टोरेज को टोकन रखने की जगह के रूप में नहीं सुझाता हूं) या राम को चर को अलग-अलग ब्राउज़र विंडो में सैंडबॉक्स किया जाता है।
ओंद्रेज स्वेजदार

34
  • टोकन कहीं संग्रहीत करने की आवश्यकता है (स्थानीय / सत्र भंडारण या कुकीज़)

  • टोकन कुकीज़ की तरह समाप्त हो सकते हैं, लेकिन आपके पास अधिक नियंत्रण है

  • स्थानीय / सत्र संग्रहण डोमेन पर काम नहीं करेगा, एक मार्कर कुकी का उपयोग करें

  • प्रत्येक कोर अनुरोध पर प्रीफ़लाइट अनुरोध भेजे जाएंगे

  • जब आपको कुछ स्ट्रीम करने की आवश्यकता होती है, तो हस्ताक्षरित अनुरोध प्राप्त करने के लिए टोकन का उपयोग करें

  • एक्सआरआरएफ की तुलना में एक्सएसएस से निपटना आसान है

  • हर अनुरोध पर टोकन भेजा जाता है, उसका आकार देखें

  • यदि आप गोपनीय जानकारी संग्रहीत करते हैं, तो टोकन एन्क्रिप्ट करें

  • JSON वेब कैम का उपयोग OAuth में किया जा सकता है

  • टोकन चांदी की गोलियां नहीं हैं, अपने प्राधिकरण के मामलों के बारे में सावधानी से सोचें

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/


14
यह स्पष्ट नहीं है कि आपके अंक कुकीज़ या टोकन के लिए हैं, वे किस तरह के दौर हैं?
प्योरफेरेट

6
मुझे समझ में नहीं आ रहा है कि कुकीज़ से अधिक टोकन पर आपका "अधिक नियंत्रण" क्यों है।
हारून

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

18

गोगलर्स के लिए :

  • मिश्रण मत करो statefulness साथ राज्य हस्तांतरण तंत्र

STATEFULNESS

  • स्टेटफुल = सर्वर साइड पर ऑथराइजेशन की जानकारी सेव करें, यह पारंपरिक तरीका है
  • स्टैटेलेस = ग्राहक पक्ष पर प्राधिकरण जानकारी को बचाने के लिए, हस्ताक्षर के साथ अखंडता सुनिश्चित करने के लिए

तंत्र

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

STATEFULNESS COMPARISON

  • "स्टेटफुल ऑथराइजेशन" का मतलब है सर्वर और स्टोर पर यूजर ऑथराइजेशन की जानकारी रखता है, जिससे ऑथराइजेशन एप्लिकेशन स्टेट का हिस्सा बन जाता है
  • इसका मतलब यह है कि क्लाइंट को केवल "ऑर्टिफिशियल आईडी" रखने की जरूरत है और सर्वर अपने डेटाबेस से ऑर्टिकल डिटेल पढ़ सकता है
  • इसका मतलब यह है कि सर्वर सक्रिय ऑर्टर्स (लॉग इन किए गए उपयोगकर्ता) का एक पूल रखता है और इस जानकारी को हर अनुरोध के लिए क्वेरी करेगा
  • "स्टेटलेस अथॉराइजेशन" का अर्थ है कि सर्वर उपयोगकर्ता की ऑर्किटेक्ट जानकारी को स्टोर और मेन्टेन नहीं करता है, यह बस यह नहीं जानता है कि किन यूजर्स में साइन इन किया गया है और कॉन्टोर इंफोर्मेशन का उत्पादन करने के लिए क्लाइंट पर भरोसा करते हैं।
  • ग्राहक संपूर्ण सूचनाओं को संग्रहीत करेगा जैसे कि आप कौन हैं (उपयोगकर्ता आईडी), और संभवतः अनुमतियाँ, समय समाप्ति, आदि, यह सिर्फ सामान्य आईडी से अधिक है, इसलिए इसे एक नया नाम दिया गया है टोकन
  • स्पष्ट रूप से क्लाइंट पर भरोसा नहीं किया जा सकता है, इसलिए डेटा को जेनरेट किया गया हस्ताक्षर के साथ संग्रहीत किया जाता है hash(data + secret key), जहां से गुप्त कुंजी केवल सर्वर के लिए जानी जाती है, इसलिए टोकन डेटा की अखंडता को सत्यापित किया जा सकता है
  • ध्यान दें कि टोकन तंत्र केवल अखंडता सुनिश्चित करता है, लेकिन गोपनीयता नहीं, क्लाइंट को इसे लागू करना होगा
  • यह भी हर अनुरोध के लिए ग्राहक को एक पूर्ण टोकन जमा करना होता है, जो अतिरिक्त बैंडविड्थ को बढ़ाता है

मैकेनिक कम्पास

  • "कुकी" सिर्फ एक हेडर है, लेकिन ब्राउज़रों पर कुछ प्रीलोडेड ऑपरेशन के साथ
  • कुकी को सर्वर द्वारा सेट किया जा सकता है और क्लाइंट द्वारा ऑटो-सेव किया जा सकता है, और उसी डोमेन के लिए ऑटो-सेंड करेगा
  • कुकी को httpOnlyइस प्रकार चिन्हित किया जा सकता है कि क्लाइंट जावास्क्रिप्ट एक्सेस को रोका जा सके
  • प्रीलोड किए गए ऑपरेशन ब्राउज़र (जैसे मोबाइल) के अलावा अन्य प्लेटफार्मों पर उपलब्ध नहीं हो सकते हैं, जिससे अतिरिक्त प्रयास हो सकते हैं
  • "कस्टम हेडर" प्रीलोडेड ऑपरेशन के बिना सिर्फ कस्टम हेडर हैं
  • ग्राहक प्रत्येक अनुरोध के लिए कस्टम हेडर सेक्शन को प्राप्त करने, स्टोर करने, सुरक्षित करने, जमा करने और अपडेट करने के लिए जिम्मेदार है, इससे कुछ सरल दुर्भावनापूर्ण URL एम्बेडिंग को रोकने में मदद मिल सकती है

अंदाज़ करना

  • कोई जादू नहीं है, किसी भी स्थिति को सर्वर या क्लाइंट पर संग्रहीत किया जाना है
  • आप कुकी या अन्य कस्टम हेडर के साथ स्टेटफुल / स्टेटलेस लागू कर सकते हैं
  • जब लोग उन चीजों के बारे में बात करते हैं जो उनकी डिफ़ॉल्ट मानसिकता ज्यादातर होती है: स्टेटलेस = टोकन + कस्टम हेडर, स्टेटफुल = ऑस्ट्रियाई आईडी + कुकी; ये एकमात्र संभव विकल्प नहीं हैं
  • उनके पास पेशेवरों और विपक्ष हैं, लेकिन यहां तक ​​कि एन्क्रिप्टेड टोकन के लिए आपको संवेदनशील जानकारी संग्रहीत नहीं करनी चाहिए

संपर्क


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

बहुत बहुत अच्छे। अधिक विवरण लाता है और वास्तव में बेहतर तरीके से कैसे और क्यों बताता है।
कॉलिनवोंग

8

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

इसलिए, एक उपयोगकर्ता इस बात से चिंतित है कि Google या Facebook द्वारा उनके कुकी डेटा का उपयोग किया जा सकता है। लेकिन, उनके पास वेब स्टोरेज को बंद करने का कम कारण है (जब तक कि विज्ञापनदाताओं के पास इसका उपयोग करने का तरीका नहीं है)।

तो, यह कुकी आधारित और टोकन आधारित के बीच का अंतर है, बाद वाला वेब स्टोरेज का उपयोग करता है।


5

टोकन आधारित प्रमाणीकरण स्टेटलेस है, सर्वर को सत्र में उपयोगकर्ता की जानकारी संग्रहीत करने की आवश्यकता नहीं है। यह जहां उपयोगकर्ता ने लॉग इन किया है, वहां चिंता किए बिना आवेदन को स्केल करने की क्षमता देता है। कुकी के लिए वेब सर्वर फ्रेमवर्क आत्मीयता है, जबकि यह टोकन आधारित समस्या नहीं है। तो उसी टोकन का उपयोग हमारे द्वारा लॉग किए गए डोमेन के अलावा किसी अन्य डोमेन से सुरक्षित संसाधन प्राप्त करने के लिए किया जा सकता है, जो किसी अन्य uid / pwd प्रमाणीकरण से बचा जाता है।

बहुत अच्छा लेख यहाँ:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs


3

टोकन का उपयोग करें जब ...

फेडरेशन वांछित है। उदाहरण के लिए, आप टोकन जारीकर्ता के रूप में एक प्रदाता (टोकन डिस्पेंसर) का उपयोग करना चाहते हैं, और फिर टोकन सत्यापनकर्ता के रूप में अपने एपीआई सर्वर का उपयोग करें। एक ऐप टोकन डिस्पेंसर को प्रमाणित कर सकता है, एक टोकन प्राप्त कर सकता है और फिर उस टोकन को आपके एपीआई सर्वर पर सत्यापित करने के लिए प्रस्तुत कर सकता है। (वही Google साइन-इन या पेपाल या Salesforce.com के साथ काम करता है।)

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

Cient हस्ताक्षरित अनुरोध की आवश्यकता है। यहां, ग्राहक द्वारा निजी कुंजी का उपयोग करके अनुरोध पर हस्ताक्षर किए जाते हैं और सर्वर ग्राहक की पहले से पंजीकृत सार्वजनिक कुंजी का उपयोग करके मान्य होगा।


1

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

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

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

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

इसलिए सामान्य तौर पर टोकन प्रमाणीकरण को प्रदान करने से जुड़े घर्षण और लागत को कम करते हैं और एक सुरक्षित वेब के विभिन्न पहलुओं का बोझ केंद्रीकृत पार्टियों को बेहतर ढंग से लागू करने और सुरक्षा प्रणालियों को बनाए रखने में सक्षम होते हैं।

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