कुकी-आधारित बनाम सत्र बनाम टोकन-आधारित बनाम दावे-आधारित प्रमाणीकरण

Question

मैंने प्रमाणीकरणों के बारे में पढ़ा है और प्रकार वर्गीकरण के बारे में भ्रमित हो गया हूं।

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

• सत्र आईडी और इसलिए यह एक सत्र आधारित प्रमाणीकरण बन जाता है?
• दावे, और इसलिए इसे दावा-आधारित प्रमाणीकरण कहा जाना चाहिए?
• मैंने पाया है कि कुछ लोग कुकीज़ में JWT टोकन भी रखते हैं, लेकिन ऐसा लगता है कि यह स्वयं के प्रवाह का एक कस्टम कार्यान्वयन है ...

अब हम दावे-आधारित प्रमाणीकरण पर स्विच करते हैं। मुख्य तत्व दावा है और दावों का संग्रह कंटेनर के रूप में उपयोग कर सकता है

• कुकीज़ (जैसा कि ऊपर चर्चा की गई है)
• टोकन (उदाहरण के रूप में जेडब्ल्यूटी)।

दूसरी तरफ, जब हम टोकन के बारे में बात कर रहे हैं, तो इसमें किसी भी प्रकार की जानकारी हो सकती है ... उदाहरण के लिए सत्र आईडी ...

तो मैं क्या याद किया है? प्रमाणीकरण प्रकारों के बारे में बात करते समय लोग कुछ ऐसा क्यों Cookie-Session-basedया Token-Claims-basedप्रमाणों को परिभाषित नहीं करते हैं ?

Answer 1

मैं सहमत हूं कि विभिन्न अवधारणाओं का नामकरण भ्रामक है। जब एक वेब संदर्भ में प्रमाणीकरण के बारे में बात करते हैं, तो विचार करने के लिए कई पहलू हैं।

प्रमाणित करते समय ग्राहक क्या सूचना भेजता है?

• एक सत्र आईडी । इसका मतलब है कि सर्वर में एक सत्र भंडारण है जिसमें सक्रिय सत्र शामिल हैं। सर्वर साइड पर सत्र स्टेटफुल हैं ।
• दावों का एक सेट । दावों में जानकारी होती है कि ग्राहक कौन से ऑपरेशन कर सकता है। सर्वर प्रत्येक प्रमाणित क्लाइंट का ट्रैक नहीं रखता है, लेकिन दावों पर भरोसा करता है। दावे आमतौर पर सर्वर साइड पर स्टेटलेस होते हैं ।

ग्राहक प्रमाणीकरण सूचना कैसे भेजता है?

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

प्रमाणीकरण सूचना का प्रारूप क्या है?

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

बोनस: ग्राहक स्थानीय रूप से जानकारी को कैसे संग्रहीत करता है

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

जब वे कहते हैं लोग क्या मतलब है ...

• "कुकी आधारित प्रमाणीकरण" । मुझे लगता है कि इसका आम तौर पर मतलब है "सत्र आईडी, कुकी द्वारा भेजें, सादे पाठ के रूप में संभव है।"
• "टोकन आधारित प्रमाणीकरण" । आम तौर पर इसका मतलब है "दावा, प्रमाणीकरण हेडर का उपयोग करके भेजें, जोसन वेब टोकन के रूप में एन्कोडेड है।"
• "दावा आधारित प्रमाणीकरण" । एक सत्र आईडी के अलावा कुछ भी हो सकता है।

Comments

बहुत बढ़िया सारांश! एक बात ध्यान दें ... ये सभी भी मध्य हमलों में आदमी के लिए असुरक्षित हैं जहां एक तीसरी पार्टी कुकी / हेडर जानकारी को अपहृत कर सकती है, इसलिए HTTPS के माध्यम से सभी ट्रैफ़िक भेजना सुनिश्चित करें।

— ब्रैंडन

Answer 2

सीधे शब्दों में कहें,

1. कुकी-आधारित प्रमाणीकरण

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

2. सत्र-आधारित प्रमाणीकरण

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

3. टोकन-आधारित प्रमाणीकरण

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

4. दावे-आधारित प्रमाणीकरण

   • यह टोकन-आधारित प्रमाणीकरण के समान है, केवल यह कि यह क्लाइंट से जुड़े क्लाइंट और / या उपयोगकर्ता के बारे में टोकन में कुछ और डेटा जोड़ता है।
   • ये डेटा प्राधिकरण से संबंधित हैं, जो ग्राहक के संसाधन के भीतर क्या करेगा, इस बारे में बात करता है (जैसे: mail.read, mail.delete, Calendar.read)।