टोकन जोड़ें

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

सुरक्षा बढ़ाएं

मैं पाठकों को सुझाव देता हूं कि स्वतंत्र रूप से आगे बढ़ने से पहले, यह सोचने के लिए कि हम सुरक्षा के साथ क्या कर सकते हैं।

यहां कुछ दृष्टिकोण दिए गए हैं जो सुरक्षा में सुधार कर सकते हैं। आप टिप्पणियों में लिख सकते हैं कि अन्य दृष्टिकोण क्या हैं - मैं उन्हें जोड़ूंगा।

1. https प्रोटोकॉल का उपयोग करना, जो इंटरनेट पर डेटा चैनल की सुरक्षा करता है। वास्तव में, यह http पर एक आवरण है, जो अतिरिक्त क्रिप्टोग्राफिक प्रोटोकॉल - SSL और TLS लगाता है
2. payload IP जानकारी जोड़ना। फिर अन्य IP से टोकन सत्यापन को पास नहीं करेगा। लेकिन IP को फेक किया जा सकता है, और डायनेमिक IP एड्रेस के साथ या जब कोई यूजर किसी कैफ़े या मेट्रो में फोन से कनेक्ट होता है तो क्या करना है। इसलिए, हम इस दृष्टिकोण का उपयोग नहीं करेंगे।
3. RS256 उपयोग करें। यह निजी कुंजी की सुरक्षा को सुनिश्चित करता है। लेकिन टोकन के साथ, सब कुछ बिल्कुल वैसा ही बना हुआ है जैसा कि था। हमें RS256 की आवश्यकता है जब हम गुप्त कुंजी को अन्य सर्वरों को पास करने से डरते हैं, जो अविश्वसनीय हो सकता है। हम उन्हें केवल एक टोकन प्रमाणीकरण उपकरण देते हैं, जो एक हमलावर के लिए बिल्कुल बेकार है।
4. अल्पकालिक टोकन का उपयोग करें। लेकिन तब उपयोगकर्ता को हर बार उसके समाप्त होने पर फिर से लॉगिन करना होगा। उपयोगकर्ता जल्दी या बाद में ऊब जाएगा और वह हमारे संसाधन को छोड़ देगा।
5. लेकिन क्या होगा यदि आप वैसे भी अल्पकालिक टोकन का उपयोग करते हैं, लेकिन इसे एक और टोकन दें, जिसका उद्देश्य केवल एक नया प्राधिकरण के बिना एक नया अल्पकालिक टोकन प्राप्त करना है? इस तरह के एक टोकन को रिफ्रेश टोकन कहा जाता है और इसे केवल एक बार उपयोग करना संभव होगा। यह मेरा लेख होगा।

क्या JWT याद है

JWT JWS (सिग्नेचर) और JWE (एनक्रिप्टिंग) कोडिंग JWE लाभ उठाता है। हस्ताक्षर किसी को गुप्त कुंजी के बारे में जानकारी के बिना एक टोकन को नकली करने की अनुमति नहीं देता है, और तीसरे पक्ष द्वारा डेटा पढ़ने के खिलाफ एन्कोडिंग सुरक्षा करता है।

आइए देखें कि साइट पर उपयोगकर्ता को प्रमाणित करने और अधिकृत करने में वे हमारी मदद कैसे कर सकते हैं।

प्रमाणीकरण (अंग्रेजी प्रमाणीकरण; ग्रीक से। τνκόςι authent [प्रमाणिक]] - वास्तविक, प्रामाणिक, α authentν [प्रामाणिक] से - लेखक) - प्रमाणीकरण प्रक्रिया। हमारे मामले में, हम उपयोगकर्ता डेटा के डेटाबेस में प्रवेश के साथ एक मैच के लिए लॉगिन + पासवर्ड की जांच करते हैं।

प्राधिकरण (अंग्रेजी प्राधिकरण - अनुमति, प्राधिकरण) - उपयोगकर्ता को कुछ कार्यों को करने का अधिकार प्रदान करता है; और इन कार्यों को करने की कोशिश करते समय इन अधिकारों की जाँच (पुष्टि) की प्रक्रिया भी।

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

टोकन के प्रकार

• एक्सेस टोकन (JWTs) टोकन हैं जिनका उपयोग संरक्षित संसाधनों तक पहुंचने के लिए किया जा सकता है। वे अल्पकालिक हैं , लेकिन पुन: प्रयोज्य हैं । उनमें अतिरिक्त जानकारी हो सकती है, जैसे जीवनकाल, या IP पता जहां से अनुरोध आ रहा है। यह सब डेवलपर की इच्छा पर निर्भर करता है।
• टोकन टोकन (आरटी) - ये टोकन केवल एक विशिष्ट कार्य करते हैं - एक नया एक्सेस टोकन प्राप्त करना। और इस समय आप एक प्राधिकरण सर्वर के बिना नहीं कर सकते। वे लंबे समय से जीवित हैं , लेकिन डिस्पोजेबल हैं ।

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

टोकन पृथक्करण का मुख्य विचार यह है कि, एक ओर , प्राधिकरण टोकन हमें आसानी से प्राधिकरण सर्वर के बिना एक उपयोगकर्ता को सत्यापित करने की अनुमति देता है, बस हस्ताक्षर की तुलना करके।

 const validateToken = token => { const [ header, payload, signature ] = token.split('.'); return signature === HS256(`${header}.${payload}`, SECRET_KEY); } 

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

निष्कर्ष में

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

उपयोगी लिंक

1. यदि मुझे टोकन प्राप्त है तो मुझे टोकन को रिफ्रेश करने की आवश्यकता क्यों है?
2. रीफ्रेश टोकन: कब उनका उपयोग करें और वे जेडब्ल्यूटी के साथ कैसे बातचीत करते हैं
3. अधिक OAuth 2.0 आश्चर्य: ताज़ा टोकन