ताज़ा और पहुंच टोकन के पीछे सरल कहानी

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

टोकन के पीछे की अवधारणा को समझने के लिए मैं एक सरल विचार प्रयोग करना चाहूंगा।

आइए कल्पना करें कि आप एक छात्र हैं जो पैसे पसंद करता है लेकिन अक्सर उसके खाते में शेष राशि लगभग शून्य होती है।

आपके विश्वविद्यालय के रास्ते में आप अपना खाता शेष राशि की जाँच करने के लिए अपना बैंक मोबाइल एप्लिकेशन खोलते हैं।

बैंक सर्वर के अनुरोध को निष्पादित करने के लिए आपको एक संतुलन आवेदन दिखाने की आवश्यकता है:

GET http://api.mybank.com/balance HTTP 1.1
और प्रतिक्रिया प्राप्त करता है

{ balance: '$0.0' }

अच्छा होगा यदि आपके अलावा कोई भी आपके बैंक खाते की जांच न कर सके। ऐसा करने के लिए, चलो उपयोगकर्ता नाम और आपके अद्वितीय पासवर्ड के साथ विशेष हेडर जोड़ते हैं:

`प्राधिकरण: उपयोगकर्ता नाम पासवर्ड

प्राधिकरण: JohnDwayson QWERTY1`

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

जब हम बस में 30 मिनट के लिए अपने मोबाइल एप्लिकेशन का उपयोग कर रहे हैं, तो यह 30 मिनट में कई बार आपके पासवर्ड को नेटवर्क पर भेज देगा।

हर requset में पासवर्ड होता है
चलिए हमारे विचार प्रयोग जारी रखें। आप अभी भी एक बस में हैं और आपका ऐप सर्वर को रिक्वेस्ट भेजता है।

क्या होगा यदि कोई धोखाधड़ी आपके बस में बैठी है और वह आपके मोबाइल फोन से बैंक सर्वर पर एक या कुछ http पैकेट को रोक सकता है?

यदि ऐप हर मिनट की जानकारी को अपडेट करता है, तो धोखाधड़ी में अनुरोधों को रद्द करने और अपना पासवर्ड प्राप्त करने की 30 संभावनाएं होंगी।

मान लें कि उसने 5-6 संदेश चुरा लिए हैं। अब आपका पासवर्ड समझौता कर लिया गया है और धोखाधड़ी आपके खाते की जानकारी तक पहुंचने के लिए इसका उपयोग कर सकती है।

बीच में आदमी पासवर्ड को सुन सकता है
वह इस जानकारी के साथ क्या कर सकता है? अच्छी खबर यह है कि वह आपके पैसे खर्च नहीं कर सकता है क्योंकि आपके पास यह नहीं है ... फिर भी :) वह आपका पासवर्ड भी नहीं बदल सकता है क्योंकि इस मामले में आप नोटिस करेंगे कि और पासवर्ड पुनर्प्राप्त करने के लिए बैंक से एसएमएस का उपयोग कर सकते हैं। इस मामले में पुराना चोरी का पासवर्ड अब मान्य नहीं होगा और छात्र अपना पैसा बचाएगा

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

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

अच्छा होगा यदि हम अपने पासवर्ड का उपयोग अक्सर अपने अनुरोधों में नहीं करेंगे। ऐसा करने के लिए हम विशेष समापन बिंदु दे सकते हैं: http://api.mybank.com/login । हम केवल इस एंडपॉइंट पर अपने क्रेडेंशियल्स भेजने जा रहे हैं और बदले में सर्वर हमारे लिए विशेष टोकन उत्पन्न करेगा। इसे केवल अद्वितीय स्ट्रिंग, GUID होने दें, जो सर्वर अपने डेटाबेस में संग्रहीत करता है। चलो इस अद्वितीय स्ट्रिंग को एक्सेस टोकन कहते हैं। हम सर्वर के साथ हर अनुरोध बात के हेडर में अपने उपयोगकर्ता नाम और पासवर्ड के बजाय इसका उपयोग करेंगे। पासवर्ड के समान चलो पहुँच टोकन के लिए समाप्ति समय सेट करें।

संतुलन अपडेट करने के लिए हमें पासवर्ड की आवश्यकता नहीं है
आइए अपने विचार प्रयोग को पुन: पेश करें।

हम बस में हैं और किसी ने संतुलन की जांच करने के लिए हमारे http अनुरोध को चुरा लिया है। लेकिन अब धोखाधड़ी में केवल टोकन तक पहुंच है।

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

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

अब परिणाम बेहतर हैं। फ्रॉड की हमारे डेटा तक पहुंच केवल 3 महीने के बजाय 10 मिनट के लिए है। लेकिन अभी भी हमारे पासवर्ड को चुराने के लिए उनके पास अच्छा बदलाव है और जब तक वह हमारे पैसे नहीं चुराते हैं तब तक हम इस पर ध्यान नहीं दे सकते।

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

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

ताज़ा और टोकन पहुँच के लिए नवीनीकृत प्रवाह
हर बार हमें एक्सेस टोकन को नवीनीकृत करने की आवश्यकता होती है, हमें केवल ताज़ा टोकन भेजने की आवश्यकता होती है। तो हमारा पासवर्ड महीने में केवल एक बार या कभी-कभार ही सर्वर पर भेजा जाएगा। मूल रूप से हमें केवल पासवर्ड की आवश्यकता है पहले टोकन को पुनः प्राप्त करने के लिए।

हमें अभी भी सर्वर से कुछ डेटा प्राप्त करने के अनुरोधों को निष्पादित करने के लिए एक्सेस टोकन की आवश्यकता है। तो:

POST /login with username and password returns us refresh token
POST /renew with refresh token returns us access token
POST /balance with access token returns us actual balance

चलिए हमारे प्रयोग को फिर से दोहराते हैं।

हम एक बस में हैं। हमारा छात्र अपना संतुलन जाँच रहा है।

लेकिन अब हमारा एप्लिकेशन रिफ्रेश टोकन का उपयोग करता है जो मोबाइल फोन की किसी फाइल में कहीं संग्रहीत है।

आवेदन जैसे अनुरोध भेज रहा है:

POST /renew
GET /balance
GET /balance
GET /balance
POST /renew
GET /balance
GET /balance
GET /balance

पहले की तरह, हैकर को बस में एक्सेस टोकन के साथ कुछ अनुरोधों को लगाया गया है।

पहुँच टोकन के लिए समाप्ति समय 15 मिनट है और हम हर 10 मिनट में टोकन अपडेट कर रहे हैं।

हैकर चोरी की गई जानकारी का उपयोग केवल 10 मिनट या उससे कम समय तक कर सकता है।

क्या होगा यदि उसने / नवीनीकृत अनुरोधों में से एक को इंटरसेप्ट किया है और टोकन को एक्सेस और एक्सेस किया है? सैद्धांतिक रूप से वह नए पहुंच टोकन प्राप्त करने के लिए एक महीने के लिए ताज़ा टोकन का उपयोग कर सकता है और फिर भी पैसे चुरा सकता है।

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

रिफ्रेश टोकन का एक और फायदा यह है कि हमें किसी एप्लिकेशन या ब्राउजर में पासवर्ड स्टोर करने और इसके बजाय केवल पिछले रिफ्रेश टोकन स्टोर करने की आवश्यकता नहीं है।

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

यह लेख विषय से थोड़ा हटकर है, लेकिन इसमें scope ।
क्या होगा यदि हम एक्सेस एक्सेस के लिए एंडपॉइंट केवल पूछेंगे / नवीनीकृत करेंगे, जिसका उपयोग विशेष रूप से बैलेंस चेक करने के लिए किया जा सकता है?
यदि उपयोगकर्ता कुछ पैसे खर्च करना चाहता है, तो उसे उसके लिए अतिरिक्त दूसरा टोकन प्राप्त करना चाहिए? इस पैरामीटर को हम 'स्कोप' कह सकते हैं।
तो हम पूछ सकते हैं / नवीनीकृत करने के लिए? स्कोप = [संतुलन, समाचार]। अगर हमारे हैकर अभी भी इस टोकन को इस्तेमाल करते हैं तो वह हमारे पैसे खर्च करने के लिए इसका इस्तेमाल नहीं कर सकते हैं!

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

टोकन के पीछे बुनियादी अवधारणा और वे कैसे काम करते हैं, यह मेरी व्याख्या थी।

एक अभ्यास पर इस अवधारणा के कुछ अलग कार्यान्वयन हैं जिन्हें आसानी से गुगुल किया जा सकता है।

पासवर्ड और टोकन के लिए समाप्ति समय चुनने में लचीलापन के बारे में छोटा नोट।

विशिष्ट समय समाप्ति समय हो सकता है:

पासवर्ड के लिए यह 3-6 महीने है। इस सीमा का होना अच्छा है। चूंकि डेटाबेस चुराया जा सकता है और उपयोगकर्ता सेवाओं में समान पासवर्ड का पुन: उपयोग कर सकता है।

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

एक्सेस समाप्ति समय 10 से 60 मिनट तक हो सकता है। कम समय के लिए नवीकरण के लिए अधिक अनुरोधों की आवश्यकता होती है, लेकिन अधिक समय धोखाधड़ी के लिए अधिक अवसर दे सकता है।

निष्कर्ष :

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