दिलचस्प पोस्ट
CMake का उपयोग करके Boost के साथ C ++ प्रोग्राम को लिंक कैसे करें I अजगर 3.5: प्रकार त्रुटि: किसी बाइट-जैसे ऑब्जेक्ट की आवश्यकता होती है, फ़ाइल को लिखते समय 'str' नहीं तालिका पंक्ति में स्लाइड टॉगल SDK Manager.exe काम नहीं करता है PHP उत्पादन सर्वर – त्रुटि संदेश चालू करें NSUserDefaults में NSMutableArray में कस्टम ऑब्जेक्ट्स को संग्रहीत करना std :: फ़ंक्शन बनाम टेम्पलेट कैसे बढ़ावा :: फ़ंक्शन और बढ़ावा :: बाध्य कार्य रिमोट फाइल को अधिलेखित करने के लिए "git push" बल Google मानचित्र परिणामों पर "खोज क्षेत्र" रूपरेखा जोड़ें जावा सॉकेट / सीरियललाइज़ेशन, ऑब्जेक्ट अपडेट नहीं होगा URL का अंतिम सेगमेंट कैसे आईओएस अनुप्रयोगों के बीच चाबी का गुच्छा डेटा साझा करने के लिए एक इंटरफ़ेस लागू करने वाला JAXB क्लास जेनरेट कर रहा है आईपैड चित्र और लैंडस्केप मोड के लिए आकार देने वर्ग

अवैध JSON वेब टोकन

एक नई नोड.जेएस प्रोजेक्ट के लिए मैं काम कर रहा हूं, मैं एक कुकी आधारित सत्र दृष्टिकोण से स्विच करने के बारे में सोच रहा हूं (इसका मतलब, मेरा मान है, उपयोगकर्ता के ब्राउज़र में उपयोगकर्ता सत्र वाले कुंजी-मूल्य वाले स्टोर में एक आईडी जमा करना) JSON Web Tokens (jwt) का उपयोग कर एक टोकन-आधारित सत्र दृष्टिकोण (कोई कुंजी-मूल्य स्टोर नहीं)

परियोजना एक ऐसा खेल है जो socket.io का उपयोग करती है – एक टोकन-आधारित सत्र होने पर ऐसी स्थिति में उपयोगी होगा जहां एक सत्र (वेब ​​और सॉकेट.ओ) में कई संचार चैनल होंगे

कैसे एक jwt दृष्टिकोण का उपयोग कर सर्वर से टोकन / सत्र अमान्यता प्रदान करेगा?

मैं यह भी समझना चाहता हूं कि इस प्रकार के प्रतिमान के साथ मुझे क्या आम (या असामान्य) नुकसान / हमलों को देखना चाहिए उदाहरण के लिए, यदि यह प्रतिमान एक ही / विभिन्न प्रकार के हमलों के लिए सत्र की दुकान / कुकी-आधारित दृष्टिकोण के लिए कमजोर है।

तो, कहते हैं कि मेरे पास निम्न हैं ( इस और इस से अनुकूलित):

सत्र स्टोर लॉग इन:

app.get('/login', function(request, response) { var user = {username: request.body.username, password: request.body.password }; // Validate somehow validate(user, function(isValid, profile) { // Create session token var token= createSessionToken(); // Add to a key-value database KeyValueStore.add({token: {userid: profile.id, expiresInMinutes: 60}}); // The client should save this session token in a cookie response.json({sessionToken: token}); }); } 

टोकन-आधारित लॉगिन:

 var jwt = require('jsonwebtoken'); app.get('/login', function(request, response) { var user = {username: request.body.username, password: request.body.password }; // Validate somehow validate(user, function(isValid, profile) { var token = jwt.sign(profile, 'My Super Secret', {expiresInMinutes: 60}); response.json({token: token}); }); } 

सत्र स्टोर दृष्टिकोण के लिए एक लॉगआउट (या अमान्य) के लिए विशिष्ट टोकन के साथ KeyValueStore डेटाबेस में अपडेट की आवश्यकता होगी।

यह ऐसा प्रतीत होता है कि टोकन-आधारित दृष्टिकोण में ऐसी कोई तंत्र मौजूद नहीं होगा क्योंकि टोकन में वह जानकारी होती है जो सामान्यतः कुंजी-मूल्य वाले स्टोर में मौजूद होती है।

वेब के समाधान से एकत्रित समाधान "अवैध JSON वेब टोकन"

मैं भी इस प्रश्न पर शोध कर रहा हूं, और नीचे दिए गए विचारों में से कोई भी पूरा समाधान नहीं है, लेकिन वे दूसरों को विचारों को छोड़ने में मदद कर सकते हैं या आगे वाले लोगों को प्रदान कर सकते हैं।

1) बस ग्राहक से टोकन को हटा दें

जाहिर है यह सर्वर साइड सुरक्षा के लिए कुछ नहीं करता है, लेकिन यह अस्तित्व से टोकन (यानी वे लॉगआउट से पहले टोकन चुरा लेना होगा) को हटाकर एक हमलावर को रोक देता है।

2) एक टोकन ब्लैकलिस्ट बनाएँ

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

3) बस टोकन समाप्ति समय कम रखने और अक्सर उन्हें बारी बारी से

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

आकस्मिक योजनाएं

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

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

टोकन का उपयोग करके हमलों के संबंध में समानताएं / अंतर के संदर्भ में, यह प्रश्न इस प्रश्न को संबोधित करता है: http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

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

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

वास्तविक टोकन सामग्री (या लुकअप आईडी) में किसी भी संशोधन की आवश्यकता नहीं है।

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

यह मुख्य रूप से @ मेटवे द्वारा जवाब पर एक लंबा टिप्पणी का समर्थन और निर्माण कर रहा है

दिया हुआ:

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

(यदि आपकी साइट को अधिक मात्रा में अनधिकृत अनुरोध प्राप्त हो जाते हैं, तो जेडब्ल्यूटी उन्हें दैटस्टोर को मारने के बिना इनकार कर देगा, जो सहायक है। शायद ऐसा अन्य उपयोग मामलों की भी हो।)

दिया हुआ:

वास्तव में स्टेटलेस जेडब्ल्यूटी प्रमाणीकरण एक विशिष्ट, वास्तविक दुनिया वेब ऐप के लिए नहीं प्राप्त किया जा सकता क्योंकि स्टेटवेट जेडब्ल्यूटी के पास निम्नलिखित महत्वपूर्ण उपयोग के मामलों के लिए तत्काल और सुरक्षित समर्थन प्रदान करने का कोई तरीका नहीं है:

उपयोगकर्ता का खाता हटाया गया है / अवरुद्ध / निलंबित है

उपयोगकर्ता का पासवर्ड बदल रहा है।

उपयोगकर्ता की भूमिकाएं या अनुमतियाँ बदल जाती हैं।

उपयोगकर्ता द्वारा व्यवस्थापक द्वारा लॉग आउट किया गया है

साइट व्यवस्थापक द्वारा जेडब्ल्यूटी टोकन में किसी भी अन्य आवेदन महत्वपूर्ण डेटा को बदल दिया गया है।

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

इसलिए: मुझे लगता है कि @ मैट-वे, # 2 टोकन ब्लैकलिस्ट से जवाब, JWT आधारित प्रमाणीकरण के लिए आवश्यक स्थिति जोड़ने का सबसे प्रभावी तरीका होगा।

आपके पास एक ब्लैकलिस्ट है जो इन टोकनों को रखती है जब तक उनकी समाप्ति तिथि हिट नहीं हो जाती। टोकन की सूची उपयोगकर्ताओं की कुल संख्या की तुलना में काफी कम होगी, क्योंकि यह केवल उनकी समाप्ति तक ब्लैकलिस्ट किए गए टोकन को रखने के लिए है। मैं redis, memcached या एक अन्य स्मृति में datastore कि एक कुंजी पर समाप्ति समय सेट करने का समर्थन करता है में अमान्य टोकन डाल द्वारा लागू होगा।

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

मैं उपयोगकर्ता मॉडल पर jwt संस्करण संख्या का एक रिकॉर्ड रखना होगा। नया जेवीटी टोकन इस पर अपने संस्करण सेट करेंगे

जब आप jwt को मान्य करते हैं, तो बस यह जांचें कि उपयोगकर्ता के मौजूदा संस्करण jwt संस्करण के बराबर इसकी संस्करण संख्या है।

किसी भी समय आप पुराने जेवीटी को रद्द करना चाहते हैं, बस उपयोगकर्ताओं को jwt संस्करण संख्या को टक्कर दें।

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

लक्ष्य:

  • डेटा स्टोर (राज्य-कम) के उपयोग को मिटेट करें
  • सभी उपयोगकर्ताओं को लॉग इन करने के लिए मजबूर करने की क्षमता।
  • किसी भी समय किसी भी व्यक्ति को लॉग आउट करने की क्षमता।
  • किसी निश्चित समय के बाद पासवर्ड फिर से प्रवेश की आवश्यकता है।
  • एकाधिक ग्राहकों के साथ काम करने की योग्यता
  • जब एक उपयोगकर्ता किसी विशेष क्लाइंट से लॉगआउट को क्लिक करता है तो फिर से लॉग इन करने की क्षमता। (उपयोगकर्ता को दूर जाने के बाद किसी ग्राहक टोकन को "अन-हटाने" को रोकने के लिए – अतिरिक्त जानकारी के लिए टिप्पणियां देखें)

समाधान:

  • लंबे समय तक रहने वाले (कुछ घंटों) क्लाइंट को रीफ़्रेश-टोकन में रखे गए लघु-अवधि (<5m) पहुंच टोकन का उपयोग करें
  • प्रत्येक अनुरोध वैधता के लिए ऑथ या फिर रीफ्रेश टोकन की समाप्ति तिथि जांचता है
  • पहुंच टोकन की समय सीमा समाप्त होने पर, क्लायंट एक्सेस टोकन को रीफ़्रेश करने के लिए ताज़ा टोकन का उपयोग करता है।
  • रीफ़्रेश टोकन जांच के दौरान, सर्वर उपयोगकर्ता आईडी की एक छोटी ब्लैकलिस्ट जांचता है – अगर ताज़ा अनुरोध को अस्वीकार कर दिया गया।
  • जब कोई क्लाइंट एक वैध (समाप्त नहीं हुआ) रिफ्रेश या ऑथ टोकन नहीं करता है, तो उपयोगकर्ता को वापस लॉग इन करना होगा, क्योंकि अन्य सभी अनुरोध अस्वीकार कर दिए जाएंगे।
  • लॉगिन अनुरोध पर, प्रतिबंध लगाने के लिए उपयोगकर्ता डेटा स्टोर की जांच करें
  • लॉगआउट पर – उस उपयोगकर्ता को ब्लैकलिस्ट सत्र में जोड़ दें ताकि उन्हें वापस प्रवेश करना पड़े। आपको अतिरिक्त जानकारी संग्रहीत करने के लिए बहु उपकरणों के वातावरण में सभी उपकरणों से लॉग इन नहीं करना होगा, लेकिन यह एक उपकरण फ़ील्ड को जोड़कर किया जा सकता है उपयोगकर्ता ब्लैकलिस्ट
  • एक्स राशि के बाद पुनः प्रविष्टि को बाध्य करने के लिए – auth टोकन में अंतिम लॉगिन दिनांक बनाए रखें और प्रति अनुरोध जांचें।
  • सभी उपयोगकर्ताओं को लॉग आउट करने के लिए बाध्य करें – टोकन हैश कुंजी को रीसेट करें।

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

विपक्ष:

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

पेशेवरों:

  • वांछित कार्यक्षमता प्रदान करता है
  • सामान्य ऑपरेशन के तहत उपयोगकर्ता से टोकन कार्रवाई रीफ़्रेश होती है।
  • केवल प्रत्येक अनुरोध के बजाय ताज़ा अनुरोध पर डेटा स्टोर करने के लिए आवश्यक है। यानी 1 प्रति सेकंड के बजाय 1 प्रत्येक 15 मिनट
  • सर्वर साइड स्थिति को बहुत छोटी ब्लैकलिस्ट में छोटा करता है।

इस समाधान के साथ मेमोरी डेटा स्टोर जैसे रेडडिस की ज़रूरत नहीं है, कम से कम यूजर की जानकारी के लिए नहीं, जैसा कि आप सर्वर हैं, केवल हर 15 मिनट या मिनट में डीबी कॉल कर रहे हैं। यदि reddis का उपयोग करते हुए, एक मान्य / अमान्य सत्र सूची को संग्रहीत करते हैं तो इसमें बहुत तेज और सरल समाधान होगा एक ताज़ा टोकन के लिए कोई ज़रूरत नहीं है प्रत्येक ऑथ टोकन में एक सत्र आईडी और डिवाइस आईडी होती है, वे सृजन पर एक रेडीडिज़ तालिका में संग्रहित हो सकते हैं और उचित होने पर अमान्य हो सकते हैं। फिर उन्हें हर अनुरोध पर चेक किया जाएगा और जब अमान्य हो जाएगा।

मैं थोड़ी देर यहां हूँ, लेकिन मुझे लगता है कि मेरे पास एक सभ्य समाधान है।

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

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

मैं यह देख रहा हूं कि यह सबसे बड़ा नकारात्मक पहलू है कि यदि वे एकाधिक ब्राउज़रों में हैं, या मोबाइल ग्राहक भी हैं, तो उन्हें अपने सभी सत्रों से लॉग इन करना होगा

यह एक प्रणाली में सभी जेडब्ल्यूटी को अवैध बनाने के लिए एक अच्छा तंत्र भी हो सकता है। चेक का हिस्सा पिछले वैध iat टाइम के वैश्विक टाइमस्टैम्प के खिलाफ हो सकता है।

आप अपने उपयोगकर्ता के दस्तावेज़ / रिकॉर्ड पर अपने डीबी पर "अंतिम_की_काइज" फ़ील्ड रख सकते हैं।

जब उपयोगकर्ता उपयोगकर्ता के साथ लॉग करता है और पास करता है, तो एक नई यादृच्छिक स्ट्रिंग उत्पन्न करते हैं, उसे अंतिम_की_कियूल्ड फ़ील्ड में संग्रहीत करते हैं, और टोकन पर हस्ताक्षर करते समय उसे पेलोड में जोड़ते हैं।

जब टोकन का उपयोग करने में उपयोगकर्ता लॉग करता है, टोकन में एक से मेल करने के लिए डीबी में last_key_used की जांच करें।

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

  1. टोकन के लिए 1 दिन का समाप्ति समय दें
  2. दैनिक ब्लैकलिस्ट बनाए रखें
  3. ब्लैकलिस्ट में अमान्य / लॉगआउट टोकन रखें

टोकन मान्यकरण के लिए, टोकन की समाप्ति की समय पहले और फिर ब्लैकलिस्ट की जांच करें यदि टोकन की समय सीमा समाप्त नहीं हुई है।

लंबे सत्र की जरूरतों के लिए, टोकन की समाप्ति की अवधि बढ़ाने के लिए एक तंत्र होना चाहिए।

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

मैंने इसे निम्नलिखित तरीके से किया है:

  1. एक unique hash उत्पन्न करें, और फिर इसे redis और अपने JWT में स्टोर। इसे एक सत्र कहा जा सकता है
    • हम जेडब्ल्यूटी द्वारा किए गए अनुरोधों की संख्या भी जमा कर देंगे – हर बार जब एक सर्वर पर एक jwt भेजा जाता है, तो हम अनुरोध पूर्णांक बढ़ाते हैं। (यह वैकल्पिक है)

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

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

हम इस से विस्तार कर सकते हैं और हमारे जेडब्ल्यूटी को और अधिक सुरक्षित बना सकते हैं, यहां बताया गया है कि कैसे:

हर एक्स एक विशेष जेडब्ल्यूटी ने अनुरोध किया है कि हम एक नया अनूठा सत्र तैयार करते हैं, इसे हमारे जेडब्ल्यूटी में संग्रहीत करते हैं, और फिर पिछले एक को ब्लैकलिस्ट करते हैं।

इसका मतलब यह है कि जेडब्ल्यूटी लगातार बदल रहा है और बाक़ी जेडब्ल्यूटी को हैक किया जा रहा है, चोरी हो रहा है, या कुछ और

पार्टी के बाद, कुछ शोधों के बाद मेरे दो सेंट नीचे दिए गए हैं लॉगआउट के दौरान, सुनिश्चित करें कि निम्नलिखित चीजें हो रही हैं …

ग्राहक संग्रहण / सत्र साफ़ करें

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

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

अद्वितीय प्रति उपयोगकर्ता स्ट्रिंग, और वैश्विक स्ट्रिंग को एक साथ मिलाया गया है

के रूप में सेवा करने के लिए जेडब्ल्यूटी गुप्त भाग दोनों व्यक्ति और वैश्विक टोकन अवैध अनुमति देते हैं। डीबी लुकअप की लागत पर अधिकतम लचीलापन / अनुरोध auth के दौरान पढ़ें। कैश में भी आसान है, क्योंकि वे शायद ही कभी बदलते हैं।

logout मामले में केवल अलग secret साथ टोकन पर हस्ताक्षर करें, लेकिन सभी सुरक्षित संसाधनों में आप अभी भी logout संसाधन सहित मूल secret साथ टोकन डिकोड कर रहे हैं ….