Jwt-auth: [प्रश्न] हेडलेस एपीआई उपयोग के मामले

इस प्लगइन में लेख प्रवाह की वास्तुकला बहुत अच्छी है; मैं सुरक्षा चिंताओं को समझता हूं। हालांकि यह शायद इस तरह की सुविधा के प्राथमिक उपयोग-मामले को अक्षम करता है: वर्डप्रेस एक हेडलेस सीएमएस के रूप में।

हेडलेस सीएमएस प्रमाणीकरण अक्षम करता है

एक हेडलेस सीएमएस के लिए उपयोगकर्ताओं को username और password के माध्यम से लॉगिन करना होगा। एक बार जब उपयोगकर्ता के पास एक JWT होता है, तो वे संरक्षित संसाधनों के लिए प्रमाणित अनुरोध भेज सकते हैं, एक हेडलेस CMS वातावरण में यह निषेधात्मक और प्रति-सहज होगा कि उपयोगकर्ताओं को API टोकन उत्पन्न करने के लिए कहें।

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

वास्तविक सुरक्षा चिंताओं को दूर करने के लिए:

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

क्या यह सिर्फ OAuth2 नहीं है?

यह दृष्टिकोण अनिवार्य रूप से एक oAuth2 "personal access" टोकन अनुदान परिदृश्य है। इस प्रकार मैं एक उचित oAuth2 मानक कार्यान्वयन पर इस तरह के एक कस्टम टोकन ऑथ सर्वर दृष्टिकोण की योग्यता पर सवाल उठाऊंगा? यदि सुरक्षा यहां प्राथमिक चिंता है, तो यह दृष्टिकोण वास्तव में सुरक्षा जोखिम प्रस्तुत करता है? उदाहरण के लिए oAuth2 का युद्ध परीक्षण कार्यान्वयन जैसे php-league-oatuh-2

मुझे वर्तमान प्रमाणीकरण प्रवाह application-to-application प्रमाणीकरण के लिए एकमात्र व्यवहार्य उपयोग मामला दिखाई दे रहा है? oAuth2 टोकन प्रदान करने के लिए कई प्रमाणीकरण प्रवाह विधियाँ प्रदान करता है। एक यह है कि यह दृष्टिकोण "personal access" का उपयोग करता है और दूसरा वह है जो मैं "password access" टोकन का वर्णन कर रहा हूं। एक पूर्ण oAuth2 कार्यान्वयन इन दोनों परिदृश्यों और अधिक की अनुमति देगा...

आगे

हमारा मानना ​​​​है कि WP-API के उत्थान और इस प्रकार सामान्य रूप से Wordpress पारिस्थितिकी तंत्र के आधुनिकीकरण को बहुत बढ़ाया जाएगा यदि स्टेटलेस API ऑथ जैसी चीजें डेवलपर्स के लिए आसानी से सुलभ थीं।

ये सिर्फ विचार हैं और चर्चा और योगदान करना पसंद करेंगे!

महान काम!

डब्ल्यूपी-हेडलेस टीम