कुकी आधारित प्रमाणीकरण कैसे काम करता है?

Question

क्या कोई मुझे बता सकता है कि कुकी आधारित प्रमाणीकरण कैसे काम करता है? मैंने कभी भी प्रमाणीकरण या कुकीज़ से संबंधित कुछ भी नहीं किया है। ब्राउज़र को क्या करने की आवश्यकता है? सर्वर को क्या करने की आवश्यकता है? किस क्रम में? हम चीजों को कैसे सुरक्षित रखते हैं?

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

Comments

howstuffworks.com/cookie.htm

— Cyclonecode

Answer 1

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

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

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

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

Comments

जो मैं समझता हूं कि ब्राउज़र कुकी को उसी डोमेन पर वापस भेजने में सक्षम है। उस संबंध में जब दो डोमेन के बीच अंतर होने पर ब्राउज़र सबडोमेन लेता है?

— आकाश

आप ब्राउज़र कैसे उपडोमेन संभालता है, इसके लिए आप HTTP हेडर में विकल्प सेट कर सकते हैं।

— कॉनर पैट्रिक

Answer 2

मुझे लगता है कि यह बहुत देर हो चुकी है, लेकिन मुझे लगा कि मैं कॉनर के जवाब पर विस्तार कर सकता हूं और चर्चा में थोड़ा और जोड़ सकता हूं।

क्या कोई मुझे बता सकता है कि कुकी आधारित प्रमाणीकरण कैसे काम करता है? मैंने कभी भी प्रमाणीकरण या कुकीज़ से संबंधित कुछ भी नहीं किया है। ब्राउज़र को क्या करने की आवश्यकता है? सर्वर को क्या करने की आवश्यकता है? किस क्रम में? हम चीजों को कैसे सुरक्षित रखते हैं?

चरण 1: क्लाइंट> साइन अप करना

कुछ और करने से पहले, उपयोगकर्ता को साइन अप करना होगा। क्लाइंट अपने HTTP यूजरनेम और पासवर्ड वाले HTTP अनुरोध को पोस्ट करता है।

चरण 2: सर्वर> हैंडलिंग साइन अप

सर्वर यह अनुरोध प्राप्त करता है और आपके डेटाबेस में उपयोगकर्ता नाम और पासवर्ड को संग्रहीत करने से पहले पासवर्ड को हैश करता है। इस तरह, यदि कोई आपके डेटाबेस तक पहुँच प्राप्त करता है, तो वे आपके उपयोगकर्ताओं के वास्तविक पासवर्ड नहीं देखेंगे।

चरण 3: क्लाइंट> उपयोगकर्ता लॉगिन

अब आपका उपयोगकर्ता लॉग इन करता है। वह अपना उपयोगकर्ता नाम / पासवर्ड प्रदान करता है और फिर से, यह सर्वर के लिए HTTP अनुरोध के रूप में पोस्ट किया जाता है।

चरण 4: सर्वर> लॉगिन मान्य

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

चरण 5: सर्वर> पहुंच टोकन उत्पन्न करना

यदि सब कुछ जांचता है, तो हम एक एक्सेस टोकन बनाने जा रहे हैं, जो विशिष्ट रूप से उपयोगकर्ता के सत्र की पहचान करता है। अभी भी सर्वर में, हम एक्सेस टोकन के साथ दो काम करते हैं:

1. इसे उस उपयोगकर्ता से जुड़े डेटाबेस में संग्रहीत करें
2. क्लाइंट को लौटाए जा रहे रिस्पांस कुकी से इसे संलग्न करें। उपयोगकर्ता के सत्र को सीमित करने के लिए एक समाप्ति तिथि / समय निर्धारित करना सुनिश्चित करें

इसके बाद, कुकीज़ क्लाइंट और सर्वर के बीच किए गए हर अनुरोध (और प्रतिक्रिया) से जुड़ी होंगी।

चरण 6: क्लाइंट> पेज अनुरोध करना

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

इससे आप कार्य शुरू कर पाएंगे। लॉगआउट पर कुकीज़ साफ़ करना सुनिश्चित करें!

Comments

वर्णन के लिए धन्यवाद। मुझे आश्चर्य है कि टोकन पहुंच सुरक्षा कैसे प्रदान करता है? क्या कोई कुकी चोरी कर सकता है, तो उपयोगकर्ता में एक प्रमाणित लॉग के रूप में? या एसएसएल द्वारा संरक्षित है?

— ऋचाक

@Richeek SSL अनुरोधों / प्रतिक्रियाओं के दौरान अवरोधन को सुरक्षित करता है, लेकिन एक हमलावर आपके कुकीज़ को समापन बिंदु (जैसे आपका ब्राउज़र) तक पहुंचा सकता है। सैद्धांतिक रूप से, वे तब तक उपयोगकर्ता में लॉग इन के रूप में पोज़ कर सकते थे जब तक कि कुकी समाप्त नहीं हो जाती। मैं कहता हूं कि "सैद्धांतिक रूप से" क्योंकि ऊपर कार्यान्वयन उस संभाल नहीं करता है। उपरोक्त कार्यान्वयन में, आपके डेटाबेस में एक्सेस टोकन अपडेट होने तक (यानी अगला लॉगिन) तक हमलावर का उपयोग होगा।

— pllx

आप अपने डेटाबेस में एक "समाप्ति तिथि" के साथ, शायद अपने आप को समाप्ति की पहुंच को अमान्य कर सकते हैं। या, आप JSON वेब टोकन (JWT) का उपयोग करने पर विचार कर सकते हैं, जो पहुंच टोकन की तरह हैं, लेकिन अन्य चीजों के बीच टोकन समाप्ति को संभाल सकते हैं। यहाँ JWT पर अधिक। यदि आपके पास टोकन / JWT है, तो एक हमलावर के पास कुछ समय के लिए आपके खाते तक पहुंच होगी, इसलिए आपको अपने समापन बिंदु भी सुरक्षित करने चाहिए।

— pllx

मुझे धन्यवाद कहने के लिए बहुत समय लगा! आपके स्पष्टीकरण के लिए धन्यवाद

— Richeek

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

— फाल्कोजर

Answer 3

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

कुकीज़ आधारित प्रमाणीकरण आम तौर पर इन 4 चरणों में काम करता है-

1. उपयोगकर्ता लॉगिन फ़ॉर्म में उपयोगकर्ता नाम और पासवर्ड प्रदान करता है और लॉग इन पर क्लिक करता है।
2. अनुरोध किए जाने के बाद, सर्वर डेटाबेस में क्वेरी करके उपयोगकर्ता को बैकएंड पर मान्य करता है। यदि अनुरोध मान्य है, तो यह डेटाबेस से प्राप्त उपयोगकर्ता जानकारी का उपयोग करके एक सत्र बनाएगा और उन्हें संग्रहीत करेगा, प्रत्येक सत्र के लिए सत्र आईडी नामक एक अद्वितीय आईडी बनाई जाती है, डिफ़ॉल्ट सत्र से आईडी क्लाइंट को ब्राउज़र के माध्यम से दी जाएगी।

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

4. उपयोगकर्ता द्वारा ऐप से लॉग आउट करने के बाद, सत्र क्लाइंट-साइड और सर्वर-साइड दोनों को नष्ट कर दिया जाता है।