वसंत @EnableResourceServer बनाम @ EnableOAuth2Sso

Question

एपीआई गेटवे पर @EnableResourceServer के बजाय अब तक पढ़े गए अधिकांश ट्यूटोरियल @EnableOAuth2Sso का उपयोग करते हैं। क्या अंतर हैं? OAuth2Sso इसके विपरीत क्या है?

विवरण: मैं वसंत-आधारित माइक्रोस्कोविसेज और एकल पृष्ठ ऐप्स के लिए सुरक्षा/इन्फ्रा आर्किटेक्चर को कार्यान्वित कर रहा हूं। कुछ समय के लिए, जबकि हमारे पास सुरक्षा आवश्यकताओं नहीं थी, एसपीए ने विभिन्न मेजबानों (सीओआरएस पार्टी) पर माइक्रोस्कोप खोलने के लिए सीधे बात की।

अब मैं spring-oauth और spring-zuul का उपयोग कर सुरक्षा की एक परत और गेटवे पैटर्न जोड़ रहा हूं। तो मेरे पास @EnableAuthorizationServer के साथ एक सेवा (uaa-service) है और @EnableZuulProxy & @EnableResourceServer के साथ गेटवे है। मुझे केवल पासवर्ड अनुदान प्रकार की आवश्यकता है, इसलिए प्रत्येक एसपीए का अपना लॉगिन फॉर्म होता है और यूआ-सेवा टोकन एंडपॉइंट के साथ प्रमाणीकरण करता है, गेटवे को गहरा करता है, और फिर आगे के अनुरोधों के लिए उस टोकन का उपयोग करने के लिए आगे बढ़ता है।

क्या इस दृष्टिकोण के साथ कुछ गलत है? क्या मुझे @EnableOAuth2Sso का उपयोग करना चाहिए?

Answer 1

ये एनोटेशन आपकी सेवाओं को विभिन्न OAuth 2.0 roles के साथ चिह्नित करते हैं।

@EnableResourceServer एनोटेशन का अर्थ है कि आपकी सेवा (OAuth 2.0 - संसाधन सर्वर के संदर्भ में) अनुरोध को पूर्ववत करने के लिए एक्सेस टोकन की अपेक्षा करता है। संसाधन सर्वर को कॉल करने से पहले OAuth 2.0 क्लाइंट द्वारा प्रमाणीकरण सर्वर से एक्सेस टोकन प्राप्त किया जाना चाहिए।

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

• @EnableOAuth2Client:

  इसके अलावा, अगर आप @EnableOAuth2Sso एनोटेशन के स्रोत कोड में एक बार देख ले तो आपके पास दो दिलचस्प बातें देखेंगे। यह वह जगह है जहां आपकी सेवा OAuth 2.0 क्लाइंट बन जाती है। यदि आप उन सेवाओं को OAuth2RestTemplate के माध्यम से कॉल कर रहे हैं, तो डाउनस्ट्रीम सेवाओं तक पहुंच टोकन (इसे प्राधिकरण कोड के लिए आदान-प्रदान के बाद) को अग्रेषित करना संभव बनाता है।

• @EnableConfigurationProperties(OAuth2SsoProperties.class)। OAuth2SsoProperties में केवल एक ही संपत्ति String loginPath है जो डिफ़ॉल्ट रूप से /login है। यह /login पर OAuth2ClientAuthenticationProcessingFilter पर ब्राउज़र अनुरोधों को अवरुद्ध करेगा और उपयोगकर्ता को प्राधिकरण सर्वर पर रीडायरेक्ट करेगा।

क्या मुझे @ EnableOAuth2Sso का उपयोग करना चाहिए?

यह निर्भर करता है:

• आप अपने API प्रवेश द्वार एक OAuth 2 होना चाहते हैं।0 क्लाइंट जो प्राधिकरण कोड प्रवाह या संसाधन स्वामी पासवर्ड प्रमाण पत्र प्रवाह का उपयोग कर ब्राउज़र के साथ इंटरैक्ट करता है, तो उत्तर हाँ है, आपको शायद चाहिए। मैंने शायद कहा क्योंकि मुझे यकीन नहीं है कि @EnableOAuth2Sso संसाधन मालिक पासवर्ड प्रमाण पत्र प्रवाह का बहुत अच्छा समर्थन करता है। वैसे भी, मैं आपको प्राधिकरण कोड प्रवाह के साथ आगे बढ़ने का सुझाव दूंगा जबतक कि आपके पास वास्तव में ऐसा नहीं है (वास्तव में!) ऐसा करने के अच्छे कारण नहीं हैं। बीटीडब्ल्यू, प्राधिकरण कोड प्रवाह का उपयोग करते समय आप अपने डाउनस्ट्रीम माइक्रोस्कोप को @EnableResourceServer के रूप में चिह्नित करना चाहेंगे। फिर एपीआई गेटवे ओएथ 2.0 क्लाइंट होगा, और आपके माइक्रोवेरिस ओएथ 2.0 रिसोर्स सर्वर होंगे जो मेरे लिए तार्किक लगते हैं।
• आप ब्राउज़र के साथ बातचीत की जरूरत नहीं है (उदाहरण के लिए ग्राहक साख प्रवाह) या आप एसपीए कि अंतर्निहित प्रवाह तो आप का उपयोग करना चाहिए @EnableResourceServer का उपयोग करता है, जिसका अर्थ है कि यह वैध प्रवेश के साथ अनुरोध को स्वीकार करेंगे टोकन केवल ।