क्या मुझे Django Rest Framework में जेडब्ल्यूटी या बेसिक टोकन प्रमाणीकरण का उपयोग करना चाहिए?

Question

मैं Django Rest Framework का उपयोग करके अपने एपीआई में टोकन प्रमाणीकरण को लागू करने वाला हूं। लेकिन मुझे यकीन है कि अगर मैं बुनियादी टोकन का उपयोग करना चाहिए डीआरएफ निर्माण में या का उपयोग JSON वेब टोकन (जेडब्ल्यूटी) मानक नहीं कर रहा हूँ केवल संदर्भ है कि मैंने पाया डीआरएफ डॉक्स में था (इस पैकेज djangorestframework-jwt उपयोग करते हुए):

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

क्या कोई अन्य अंतर, फायदे या नुकसान पर विचार करना है?

नोट: एपीआई वाला (AngularJS का उपयोग) वेबसाइट से पहुँचा जा रहा है और एक मोबाइल एप्लिकेशन द्वारा

Answer 1

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

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

इसके अलावा, एक जेडब्ल्यूटी टोकन अभी भी किसी भी भालू टोकन (क्लाइंट द्वारा संग्रहीत ऑथ एपी द्वारा जारी, प्राधिकरण शीर्षलेख में संसाधन एपीआई द्वारा पारित) के रूप में व्यवहार करता है, इसलिए वास्तव में इसका उपयोग करने के लिए कोई डाउनसाइड्स नहीं है I के बारे में सोच सकते हैं

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

Answer 2

जेडब्ल्यूटी: है कि यह सामान (पैसे के लिए इसी तरह जब खरीदने सामान) के लिए पूछ सकते

1. Any ग्राहक
2. कोई डेटाबेस देखने एक बार जारी - समाप्ति एम्बेडेड तय सत्यापन

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

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

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

कैशिंग और अन्य प्रदर्शन संवर्द्धन के साथ, किसी को ओवरहेड के बारे में चिंता करने की आवश्यकता नहीं हो सकती है, लेकिन प्रवाह की सुविधा और भविष्य के प्रमाणन की आवश्यकता नहीं है।

प्रमाणीकरण, प्रमाणीकरण और अमान्यता पर पूर्ण नियंत्रण रखना एक अच्छी बात है, इससे कोई फर्क नहीं पड़ता कि जेडब्ल्यूटी + ब्लैकलिस्ट या बेसिक टोकन ऑथ का उपयोग किया जाता है या नहीं।

इसलिए, मूल ऑथ टोकन may बेहतर हो सकता है यदि प्रवाह को आवश्यकताओं को पूरा करने के लिए अनुकूलित किया गया हो।