स्टेटलेस स्प्रिंग सुरक्षा oauth2 प्रदाता

Question

मैं बसंत-बूट, वसंत-सुरक्षा और वसंत-ओथ 2 के आधार पर एक साधारण OAuth2 प्रदाता सेट करना चाहता हूं।

मुझे एक ही इंस्टेंस मशीन पर काम करने वाली सबकुछ मिल गई: ओएथ 2 प्रमाणीकरण के लिए, उपयोगकर्ता को /oauth/authorize पर भेजा गया है। अधिकांश उपयोगकर्ता लॉग इन नहीं होते हैं, इसलिए उन्हें वसंत सुरक्षा द्वारा /login पर रीडायरेक्ट किया जाता है और फिर प्रमाणीकरण को समाप्त करने के लिए वापस टी /oauth/authorize पर रीडायरेक्ट किया जाता है।

डिफ़ॉल्ट कॉन्फ़िगरेशन में, वसंत-सुरक्षा उपयोगकर्ता के ब्राउज़र में एक सत्र-आईडी के साथ एक कुकी सेट करता है और सत्र डेटा को संग्रहीत करता है।

public static class SecurityConfiguration extends WebSecurityConfigurerAdapter { 
    @Override 
    protected void configure(HttpSecurity http) throws Exception { 
     http 
      .authorizeRequests() 
      .and() 
      .formLogin() 
      .loginPage("/login") 
      .permitAll(); 
    } 
[...] 

आदेश उपयोगकर्ता सत्र खो बिना लोड संतुलन और नीले-हरे तैनाती सक्षम करने के लिए, (मुझे लगता है कि) मैं निम्न चरणों का पालन करना होगा:

• सर्वर साइड सत्र अक्षम - एक एपीआई के लिए यह केवल OAuth2 प्रमाणीकरण के लिए ज़िम्मेदार है, मुझे नहीं लगता कि सत्रों के लिए साझा डेटाबेस होना जरूरी है।
• इसके बजाय, प्राधिकरण के दौरान उपयोगकर्ता प्रमाणीकरण, टेम्पोरारिली युक्त याद रखने वाली कुकी को सक्षम करें।
• स्टोर /login के लिए पुनर्निर्देश url एक अलग जगह
  • यह लॉगिन प्रपत्र या उपयोगकर्ता कुकी में इस स्टोर करने के लिए संभव है पर अनुप्रेषित? या "सत्रहीन" विकल्प क्या होगा?
• अक्षम CSRF (मुझे पता है कि क्या करना है और OAuth2। Auth_codes जो मुझे लगता है कि एक समान उद्देश्य है है बस संपूर्णता के लिए कैसे।)

कि दृष्टिकोण क्या मतलब? क्या परिवर्तन आवश्यक हैं?

Answer 1

1. उपयोगकर्ता के बाद अपने प्रदाता के लिए एक लॉगिन करता है, तो आप एक प्राधिकरण कोड जो क्लाइंट अनुप्रयोग (पुन: निर्देशन (कॉलबैक) यूआरएल के माध्यम से) को भेज है उत्पन्न करते हैं।

2. बाद में क्लाइंट एप्लिकेशन एक्सेस टोकन प्राप्त करने के लिए आपके सर्वर से अनुरोध करता है। इस अनुरोध में यह ऑटोराइजेशन कोड प्रदान करता है।

3. उस बिंदु पर आपको क्लाइंट एप्लिकेशन द्वारा भेजे गए प्राधिकरण कोड की तुलना पहले स्थान पर जेनरेट करने के लिए करने में सक्षम होना चाहिए। यह वह जगह है जहां आपको साझा स्मृति की आवश्यकता होती है।

आप प्रोटोकॉल section-4.1 आप बिंदु सी और डी के बीच साझा स्मृति की जरूरत के इस भाग को देखें, तो

यह आपके सर्वर के बाहर कुछ भी साथ प्राप्त नहीं किया जा सकता क्योंकि इस बिंदु जहां है आप सत्यापित करते हैं कि क्लाइंट एप्लिकेशन अधिकृत है।

प्रक्रिया में बाद में एक्सेस और रीफ्रेश टोकन के साथ मामला इसी तरह का मामला है।

लॉगिन चरण (बिंदु ए और बी) के लिए - यह लॉगिन प्रपत्र के अंदर रीडायरेक्ट url (और क्लाइंट स्थिति - अनुभाग-4.1 देखें) ठीक लग रहा है। यदि यह एकमात्र ऐसा स्थान है जहां सत्र का उपयोग किया जाता है - तो आप इससे छुटकारा पा सकते हैं। लेकिन आपको प्राधिकरण कोड के लिए अभी भी साझा मेमोरी (साझा डेटाबेस) की आवश्यकता होगी।

Answer 2

यह वितरित सत्र संग्रहण की क्लासिक समस्या है। सबसे पहले, "सत्र" (सत्र आईडी 'और कुकीज़) की अवधारणाएं "स्टेटलेस" के साथ मिलकर एक विरोधाभास है।

OAuth2 एक "राज्यविहीन" नियुक्त प्राधिकरण ढांचे प्रदान की माना जाता है आप जारी रहती प्रारंभिक इनपुट अनुरोध एक्सेस कोड जनरेट होने से पहले सर्वर साइड पर (रीडायरेक्ट URL सहित)।

प्रमाण-पत्र प्राप्त करने से पहले कुकीज़ पर उन विवरणों को लेना सुरक्षा शोषण के लिए आपको उजागर कर सकता है। आप यह सुनिश्चित कर जोखिम को कम कर सकते हैं कि कुकी हैटप केवल (जेएस द्वारा उपलब्ध नहीं है) और सुरक्षित (केवल httpS पर रिलीज़) है, लेकिन मैं वैसे भी उस दृष्टिकोण की अनुशंसा नहीं करता।

आपके अन्य बिंदु के बारे में: स्प्रिंग सिक्योरिटी की याद रखने की सुविधा केवल प्रमाणीकरण प्रमाण-पत्रों के संदर्भ में तैयार की गई है, न कि प्रारंभिक auth2 अनुरोधों के विवरण। इसके अलावा, लगातार विकल्प (PersistentTokenBasedRememberMeServices) डिफ़ॉल्ट रूप से स्मृति (एकल नोड) और जेडीबीसी स्वाद का समर्थन करता है।

आपकी आवश्यकताओं के लिए समायोजित करने में काफी बदलाव की आवश्यकता होगी। करने योग्य लेकिन बहुत प्रयास की आवश्यकता है।

मेरे अनुभव में, वहाँ दो विकल्प जो मन में आता है:

1. कॉन्फ़िगर चिपचिपा सत्र एक सामने लोड संतुलन का उपयोग कर (उदाहरण के लिए: haproxy, nginx, F5, आदि ...)। उपयोगकर्ता सत्र नोड से बंधेगा जहां जमा किए गए प्रमाण पत्र। निहितार्थ यह है कि अगर वह नोड नीचे चला जाता है; उपयोगकर्ता को नए एक्सेस टोकन बनाने के लिए पुनः प्रमाणीकरण करना होगा, लेकिन अन्य नोड्स के खिलाफ उपयोग किए जाने वाले एक्सेस टोकन को ठीक से ठीक किया जाना चाहिए।

2. पारदर्शी वितरित वेब सत्र संग्रहण को कॉन्फ़िगर/कार्यान्वित करें। कुछ वितरित मेमोरी स्टोरेज प्रदाताओं (उदा .: hazelcast) plugins प्रदान करते हैं जो उपयोगकर्ता के लिए यह पारदर्शी बनाने के लिए एप्लिकेशन सर्वर पर कॉन्फ़िगर किया गया है। इस पर कुछ अतिरिक्त ओवरहेड लगाया गया है, लेकिन आपकी आवश्यकता को पूरा करने के लिए लगभग कोई अतिरिक्त कोड आवश्यक नहीं है।