JSON वेब टोकन समाप्ति

Question

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

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

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

अग्रिम धन्यवाद।

Answer 1

RFC 7009निर्दिष्ट करता है OAuth 2.0 टोकन निरसन। असल में आपके पास एक एंडपॉइंट है जहां आप access_tokens को निरस्त कर सकते हैं।

Answer 2

यह स्पष्ट नहीं है कि आप अपने प्रश्न से ओएथ प्रवाह का उपयोग कर रहे हैं, या आप ओथ के बजाय ओपनआईडी कनेक्ट का जिक्र कर रहे हैं या नहीं।

ताज़ा टोकन का उपयोग करने पर विचार करें और आपके एक्सेस टोकन पर बहुत कम समाप्ति है - उदा। तीस मिनट।

इस परिदृश्य में, उपयोगकर्ता (resource owner) को प्रमाणीकरण जारी रखने की आवश्यकता नहीं है, और आपके API (Resource Server) को यह जांचने की आवश्यकता नहीं है कि उपयोगकर्ता प्रत्येक अनुरोध पर अभी भी मान्य है।

एक बार पहुँच टोकन समाप्त हो रहा है, अपने client (आवेदन अपने एपीआई बुला) अपने डीबी (Authorisation Server) से संपर्क करें और एक नया पहुँच टोकन के लिए अपने ताज़ा टोकन चाहिए - और आम तौर पर एक नया ताज़ा टोकन - उपयोगकर्ता प्रदान अभी भी एक मान्य है आपके डीबी पर उपयोगकर्ता और उपयोगकर्ता ने क्लाइंट एप्लिकेशन के लिए एपीआई पर अपने डेटा तक पहुंच निरस्त नहीं की है।

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

Answer 3

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

Answer 4

यदि असंभव नहीं है तो जेडब्ल्यूटी-आधारित एक्सेस टोकन को रद्द करना मुश्किल है।

एक्सेस टोकन का प्रतिनिधित्व कैसे किया जाना चाहिए? दो प्रमुख तरीके हैं।

1. एक अर्थहीन यादृच्छिक स्ट्रिंग के रूप में। किसी एक्सेस टोकन से जुड़े जानकारी को प्राधिकरण सर्वर के पीछे डेटाबेस तालिका में संग्रहीत किया जाता है।
2. एक स्व-निहित स्ट्रिंग के रूप में जो base64url या कुछ समान द्वारा एन्कोडिंग एक्सेस टोकन जानकारी का परिणाम है।

इन तरीकों के बीच एक विकल्प निम्न तालिका में वर्णित परिणामी मतभेदों का कारण बन जाएगा।

"7. पहुंच टोकन" "Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings" पेशेवरों और पहुँच टोकन प्रतिनिधित्व के तरीकों में से विपक्ष के लिए में देखें।

यदि आपके एक्सेस टोकन जेडब्ल्यूटी-आधारित हैं, तो आपके सिस्टम को (1) समाप्त होने तक निरस्त एक्सेस टोकन याद रखना होगा। एक और समझौता (2) तक पहुंचने के लिए पर्याप्त टोकन का जीवनकाल बना देता है और को रद्द कर देता है।

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