क्रॉस डोमेन प्रमाणीकरण के लिए JWT का उपयोग करके एकल साइन-ऑन प्रवाह

Question

Json Web Tokenप्रमाणीकरण के लिए JWT ( ) का उपयोग करने के बारे में वेब पर बहुत सारी जानकारी है। लेकिन मुझे अभी भी स्पष्ट विवरण नहीं मिला कि एक मल्टीपल डोमेन एनवायरनमेंट में सिंगल साइन-ऑन सॉल्यूशन के लिए JWT टोकन का उपयोग करते समय प्रवाह क्या होना चाहिए ।

मैं एक ऐसी कंपनी के लिए काम करता हूं जिसमें विभिन्न होस्ट पर बहुत सारी साइटें हैं। चलो example1.com और example2.com का उपयोग करते हैं । हमें एक एकल साइन-ऑन समाधान की आवश्यकता है, जिसका अर्थ है कि यदि कोई उपयोगकर्ता example1.com पर प्रमाणित करता है , तो हम चाहते हैं कि वह भी example2.com पर स्वतः प्रमाणित हो जाए।

OpenId कनेक्ट प्रवाह का उपयोग करते हुए , मैं समझता हूं कि जो उपयोगकर्ता example1.com पर प्रमाणित करना चाहता है, उसे पहले प्रमाणीकरण सर्वर (या OP: "OpenId प्रदाता") पर पुनर्निर्देशित किया जाएगा । उपयोगकर्ता उस सर्वर पर प्रमाणित करता है, जो तब उसे हस्ताक्षरित JWT टोकन के साथ मूल example1.com साइट पर वापस भेज देता है । (मुझे लगता है कि एक और प्रवाह है जो एक मध्यवर्ती टोकन लौटाता है जिसे स्वयं वास्तविक JWT टोकन के लिए बाद में एक्सचेंज किया जा सकता है, लेकिन मुझे नहीं लगता कि यह हमारे लिए आवश्यक है) ...

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

पहला प्रश्न :

क्लाइंट पर JWT टोकन कैसे संग्रहीत किया जाना चाहिए? इस बारे में फिर से बहुत सारी जानकारी है, और लोग इस बात से सहमत दिख रहे हैं कि इसका उपयोग Web Storageकरना अच्छे पुराने के बजाय जाने का तरीका है cookies। हम चाहते हैं कि JWT ब्राउज़र रिस्टार्ट के बीच लगातार बना रहे ताकि हम उपयोग करें Local Storage, न कि Session Storage...

अब उपयोगकर्ता अपने ब्राउज़र को फिर से शुरू कर सकता है और वह अभी भी example1.com पर प्रमाणित होगा , जब तक कि JWT टोकन समाप्त नहीं होता है!

इसके अलावा, अगर example1.com को हमारे किसी अन्य डोमेन के लिए अजाक्स अनुरोध करने की आवश्यकता है , तो मुझे समझ में आता है कि CORS को कॉन्फ़िगर करने की अनुमति होगी। लेकिन हमारा मुख्य उपयोग मामला क्रॉस-डोमेन अनुरोध नहीं है, यह एकल साइन-ऑन समाधान है !

इसलिए, मुख्य सवाल:

अब, प्रवाह क्या होना चाहिए, अगर उपयोगकर्ता example2.com पर जाता है और हम चाहते हैं कि उसे जेडब्ल्यूटी टोकन का उपयोग करके पहले से ही प्रमाणित किया जाए? Local Storageलगता है कि इस बिंदु पर क्रॉस-डोमेन का उपयोग करने की अनुमति नहीं है इसलिए ब्राउज़र उदाहरण के लिए अनुरोध करने के लिए JWT टोकन नहीं पढ़ सकता है ।

चाहिए:

• उपयोगकर्ता को फिर से प्रमाणीकरण सर्वर पर भेज दिया जाएगा? जब उपयोगकर्ता example1.com के लिए प्रमाणित होता है , तो प्रमाणीकरण सर्वर ने उपयोगकर्ता पर एक कुकी सेट की हो सकती है, इसलिए example2.com के लिए यह नया प्रमाणीकरण अनुरोध उस कुकी का उपयोग कर सकता है यह देखने के लिए कि उपयोगकर्ता पहले से ही प्रमाणित है और तुरंत उसे वापस example2.com पर रीडायरेक्ट करता है उसी JWT टोकन के साथ?
• या, example2.com पर ब्राउज़र, JWT टोकन को फिर से प्रमाणीकरण सर्वर पर जाने के बिना एक्सेस कर सकता है ? मैं देखता हूं कि क्रॉस-स्टोरेज समाधान हैं , लेकिन क्या वे व्यापक रूप से उपयोग किए जाते हैं? क्या वे क्रॉस डोमेन SSO पर्यावरण के लिए सुझाए गए समाधान हैं?

हम कुछ भी नहीं चाहते फैंसी, हम ज्यादातर इस्तेमाल समाधान के साथ खुश होंगे!

Answer 1

उपयोगकर्ता को फिर से प्रमाणीकरण सर्वर पर पुनर्निर्देशित किया जाना चाहिए और एक नया टोकन (JWT) प्राप्त करना चाहिए, जो कि विशेष रूप से 2.com.com के लिए लक्षित है। यह है कि OpenID कनेक्ट और कोई अन्य क्रॉस-डोमेन फ़ेडरेटेड SSO प्रोटोकॉल कैसे काम करता है।

Comments

लेकिन उपयोगकर्ता एसएसओ के बाद से प्रमाणीकरण क्रेडेंशियल (उदाहरण के लिए उपयोगकर्ता नाम / पासवर्ड) को फिर से भेजने के बिना, सही है? तो उसे कैसे किया जाता है? क्या प्रमाणीकरण सर्वर को पहली बार उपयोगकर्ता पर एक मानक कुकी सेट करनी चाहिए, इसलिए यह स्वचालित रूप से उसे प्रमाणित कर सकता है जब यह उपयोगकर्ता एक नए डोमेन से वापस आ गया है?

— इलेक्ट्रोटाइप

लेकिन क्या होगा यदि उपयोगकर्ता सभी कुकीज़ को ब्लॉक करने के लिए ब्राउज़र को कॉन्फ़िगर करता है?

— क्रिस्टियान वेस्टरबेक

मुझे लगता है कि कुकीज़ के बारे में एक चेतावनी दी जानी चाहिए कि "साइट ठीक से काम नहीं कर सकती है यदि आपका ब्राउज़र कुकीज़ को अवरुद्ध करता है"

— AnBisw

एकल-साइनऑन का मतलब यह नहीं है कि उपयोगकर्ता के पास कुकी द्वारा ट्रैक किए गए एक सत्र है: इसकी परिभाषित विशेषता यह है कि एक ही पहचान प्रदाता के खिलाफ एक ही क्रेडेंशियल्स का उपयोग विभिन्न 3-पार्टी अनुप्रयोगों तक पहुंच प्राप्त करने के लिए किया जाता है अर्थात कोई कुकी आवश्यक नहीं है बस उसी क्रेडिट का फिर से उपयोग करें

— हंस जेड।

Answer 2

उपयोगकर्ता को केंद्रीय प्रमाणीकरण सेवा में पुनर्निर्देशित करना जब उपयोगकर्ता क्रेडेंशियल का अनुरोध करने के लिए लॉग इन नहीं किया जाता है और एक नया प्रमाणीकरण टोकन जारी करता है, तो ओउथ 2 या ओपनआईड जैसे प्रसिद्ध प्रोटोकॉल का उपयोग करते हुए एकल साइन ऑन सिस्टम में सामान्य परिदृश्य है कनेक्ट

हालाँकि जब इस स्कीमा का उपयोग पूरे डोमेन में किया जाता है, तो मुख्य दोष यह है कि उपयोगकर्ता को हर बार रीडायरेक्ट किया जाता है और प्रमाणित किया जाता है कि वह समान-मूल नीति के कारण अन्य डोमेन पर नेविगेट करता है : एक्सेस टोकन को डोमेन के बीच साझा नहीं किया जा सकता है ( example2.comडेटा का उपयोग नहीं किया जा सकता है) का example1.com), इसलिए लक्ष्य डोमेन अप्रमाणित के रूप में उपयोगकर्ता का इलाज, केंद्रीय SSO सेवा करने के लिए उसे पुनः निर्देशित करेंगे।

क्रेडेंशियल को फिर से अनुरोध करने से प्रमाणीकरण सेवा को रोकने के लिए, एक सत्र कुकी (एक एक्सेस टोकन नहीं) होना आम है, लेकिन ब्राउज़र लोकलस्टोरेज / कुकीज़ का उपयोग करके डोमेन में डेटा साझा करने के लिए एक टेक्निक है और एक मध्यवर्ती डोमेन के लिए एक iframe है sso.example.com

1. उपयोगकर्ता को प्रमाणित करने के लिए example1.com, उसे प्रमाणीकरण सर्वर में पुनर्निर्देशित करें, प्रमाणीकरण के sso.example.comबाद एक JWT जारी करें और इस डोमेन के स्थानीयस्टोर में संग्रहीत करें। इसके बाद, उपयोगकर्ता को मूल डोमेन example1.com पर पुनर्निर्देशित करें

2. example2.comइंगित करने के लिए एक आइफ्रेम बनाएं sso.example.com। Sso.example.com में iframe JWT टोकन पढ़ता है और मूल पृष्ठ पर एक संदेश भेजता है

3. मूल पृष्ठ संदेश प्राप्त करता है और SSO प्रवाह के साथ संलग्न टोकन प्राप्त करता है

समान-मूल नीति के साथ कोई समस्या नहीं है क्योंकि sso.example.comइसकी लोकलस्टोरेज तक पहुंच है और iframe और मूल पृष्ठ के बीच संचार की अनुमति है यदि मूल और लक्ष्य डोमेन एक दूसरे को पहचानते हैं (देखें http://blog.teamtreehouse.com/cross-domain- संदेश-साथ-पोस्टस्मेज )

विकास को सरल बनाने के लिए, हमने हाल ही में https://github.com/Aralink/sjjt पर JWT के साथ एक क्रॉस डोमेन SSO जारी किया है

यह विधि SSO प्रवाह के साथ पूरी तरह से संगत है। यह केवल पुनर्निर्देशन के बिना प्रमाणीकरण टोकन साझा करने और डोमेन के फ़ेडरेटेड होने पर अनावश्यक लॉग-इन से बचने का एक तरीका है

Comments

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

— हंस जेड।

धन्यवाद @ हंस। हमने दर्जनों अनुप्रयोगों और एक ही उपयोगकर्ताओं के साथ कई डोमेन का एक ही प्रशासन करने के लिए वास्तव में इस समाधान को लागू किया है। ऑपरेशन Google सिस्टम (अपेक्षाकृत बोलने वाला) के समान है

— पेड्रोफ

Answer 3

निश्चित नहीं है कि यह आपके द्वारा दिए गए प्रश्न का उत्तर देता है, लेकिन यदि आपका मुख्य लक्ष्य एकल साइन-ऑन है, तो मुझे लगता है कि एक सरल रिवर्स प्रॉक्सी आपकी समस्या को हल करेगा (कम से कम क्रॉस-डोमेन स्टोरेज एक)।

तो example1.com example2.com

कुछ ऐसा बन जाता

example.com/example1

example.com/example2

(और एक उपयोगकर्ता की ओर से, यह आमतौर पर क्लीनर है)

यदि वह विकल्प नहीं है, तो आपको सेट अप करना पड़ सकता है, ताकि जब कोई उपयोगकर्ता 1 डोमेन में प्रमाणित करता है, तो वह अन्य डोमेन के साथ प्रमाणीकरण बनाने के लिए AJAX / छिपे हुए iframes का उपयोग करता है और यदि आवश्यक हो तो url के माध्यम से 1 बार टोकन भेज रहा है। )।

और अगर यह विकल्प नहीं है, तो आपको उपयोगकर्ता नाम + पिन का सहारा लेना पड़ सकता है, क्योंकि ब्राउज़र क्रॉस-डोमेन इंटरैक्शन के बारे में सख्त हो रहे हैं।