JWT समाप्ति और JWT पेलोड अपडेट

Question

हैंडलिंग मेरे पास मेरे व्यक्तिगत/शौक एप्लिकेशन के लिए कोआ आधारित नोड.जेएस बैकएंड है।

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

1. :

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

2. मुझे समय-समय पर समाप्त होने वाले जेडब्ल्यूटी टोकन को कैसे संभालना चाहिए? मेरे दिमाग में मेरे पास 3 (संभव) परिदृश्य हैं:

   2.1। जेडब्ल्यूटी 15 मिनट का कहना है कि छोटे जीवन में सेट है। यदि बैकएंड सर्वर 401 अनधिकृत 'अमान्य टोकन' के साथ जवाब देता है (मुझे लगता है कि यह koa-jwt का डिफ़ॉल्ट व्यवहार है) तो मैं अपने क्लाइंट को स्वचालित रूप से लॉग आउट करता हूं और पुनः प्रमाणीकरण की आवश्यकता होती है। लेकिन मैंने एक पूरक मिडलवेयर भी स्थापित किया जो रीफ्रेश किए गए समाप्ति के साथ टोकन को फिर से बनाने के लिए बैकएंड पर श्रृंखला में आखिरी है और ग्राहक रीफ्रेश किए गए एक के साथ मौजूदा टोकन को भी बदल देगा। इसलिए यदि उपयोगकर्ता सक्रिय है और सफलता के मामले में प्रत्येक संरक्षित एपीआई कॉल एप्लिकेशन का उपयोग करता है, तो पुराने टोकन को प्रतिस्थापित करने के लिए एक नया टोकन तैयार करेगा।

   2.2। जेडब्ल्यूटी लंबे समय तक जीवित है, 1 सप्ताह का कहना है, और यदि यह समाप्त हो जाता है तो मैं ग्राहक से पुनः प्रमाणीकरण में ऑप्ट-इन करता हूं।

   2.3। https://tools.ietf.org/html/rfc6749#section-1.5 कॉपी करें। सफल प्रमाणीकरण के बाद जेडब्ल्यूटी टोकन बनाते समय हम एक access_token के साथ-साथ refresh_token भेजते हैं। जब access_token की समयसीमा समाप्त हो जाती है और सर्वर HTTP 401 'अमान्य टोकन' (koa-jwt डिफ़ॉल्ट) के साथ प्रतिक्रिया करता है तो क्लाइंट बैक किए गए रीफ्रेश_टोकन को एक नई access_token (और वैकल्पिक रूप से एक नया refresh_token) की आवश्यकता होती है। इस मामले में मैं पूरी तरह से समझ नहीं पा रहा हूं कि नया टोकन प्रदान करने के लिए पुराने access_token के विरुद्ध refresh_token कैसे सत्यापित किया गया है? या हमें refresh_token क्यों करने की आवश्यकता है?

ऊपरी विषयों (जेडब्ल्यूटी अपडेट और जेडब्ल्यूटी एक्स समाप्ति) पर कोई सामान्य सलाह उपयोगी होगी।

Answer 1

मैं पहले दूसरे पर पहुंचने से पहले अपने दूसरे प्रश्न का उत्तर देना चाहता हूं।

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

{ 
"token_type":"bearer", 
"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiVlx1MDAxNcKbwoNUwoonbFPCu8KhwrYiLCJpYXQiOjE0NDQyNjI4NjYsImV4cCI6MTQ0NDI2Mjg4Nn0.Dww7TC-d0teDAgsmKHw7bhF2THNichsE6rVJq9xu_2s", 
"expires_in":10, 
"refresh_token":"7fd15938c823cf58e78019bea2af142f9449696b" 
} 

तो विचार प्राधिकरण सर्वर & संसाधन सर्वर (जो पहुँच टोकन/रीफ्रेश टोकन जनरेट) में आपके आवेदन अलग करने के है (एक्सेस को सत्यापित टोकन और संसाधनों का उपयोग)। आप प्राधिकरण सर्वर में एक्सेस टोकन के विरुद्ध रीफ्रेश टोकन को सत्यापित करने के लिए स्कीमा को बनाए रख सकते हैं। कृपया इस लिंक में उल्लिखित स्कीमा अनुभाग देखें जो आपको कुछ विचार दे सकता है। Oauth2। आप अपनी ज़रूरत के अनुसार स्कीमा को संशोधित कर सकते हैं। प्रत्येक अनुरोध कॉल के लिए आपको अपने एक्सेस टोकन के साथ अपना रीफ्रेश टोकन नहीं भेजने की आवश्यकता है। रीफ्रेश टोकन केवल नए एक्सेस टोकन उत्पन्न करने के लिए प्राधिकरण सर्वर पर भेजा जा सकता है। ताज़ा टोकन कैसे उत्पन्न करें? यदि मैं जावा का उपयोग कर रहा हूं, तो मैं अद्वितीय रीफ्रेश टोकन उत्पन्न करने के लिए UUID.randomUUID() का उपयोग करूंगा।

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

ताज़ा टोकन का उपयोग करने का मुख्य लाभ यह है कि प्रवेश टोकन ताज़ा टोकन

Answer 2

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

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

यह है कि विकल्प 2.3 मूल रूप से 2.2 रूप में ही है, जो एक बुरा विकल्प नहीं है का मतलब है,

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

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

आपका दृष्टिकोण थोड़ा अलग है क्योंकि आपके पास एक स्थानीय स्टेटस पर संग्रहीत एक स्टेटलेस जेडब्ल्यूटी टोकन (इसमें वास्तविक उपयोगकर्ता डेटा है) है। जैसा कि आपने कहा था, टोकन को अपडेट करने के लिए आपको एक नया उत्पन्न करना होगा, क्योंकि आपको एक नया हस्ताक्षर बनाना होगा।

हस्ताक्षर को सत्यापित करने के लिए कि जेडब्ल्यूटी के प्रेषक यह कौन कहता है यह है और यह सुनिश्चित करें कि संदेश तरह से नहीं बदला गया था है प्रयोग किया जाता है।

(जोर मेरी है; स्रोत JSON web tokens)

कि सभी ने कहा, मैं विचार करेंगे निम्नलिखित:

1. स्वयं से पूछें कि क्या तुम सच में जेडब्ल्यूटी के या यदि नियमित सत्र पहचानकर्ता के रूप में जमा की जरूरत है कुकीज़ (HTTP Only) आपके तर्क को सरल बनायेगी।
2. यदि जेडब्ल्यूटी की आवश्यकता है, उदाहरण के लिए, आपके पास एक और एपीआई है जो इन टोकन को प्रमाणीकरण के रूप में स्वीकार करेगी, तो मैं ब्राउजर-आधारित एप्लिकेशन के लिए रीफ्रेश टोकन के रूप में विकल्प 2.1 या 2.2 पर विचार करूंगा।

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

एक और मुद्दा है कि आपके आवेदन इंजेक्शन स्क्रिप्ट के रूप में एक हमलावर को पहुँच टोकन सामने आ जाएगी में XSS की तरह एक जोखिम, यह HTTP केवल सत्र कुकी भंडारण के पक्ष में एक अन्य बिंदु हो सकता है localStorage/sessionStorage से पढ़ने में सक्षम हो जाएगा ।