हाँ आप OAuth का उपयोग करके अपने वेबसाकेट कनेक्शन को सुरक्षित कर सकते हैं। Kaazing WebSocket Gateway में विभिन्न तरीकों (टोकन-आधारित, HTTP- आधारित, या कुकी-आधारित) का उपयोग करके प्रमाणीकरण और प्रमाणीकरण के लिए एक सुरुचिपूर्ण वास्तुकला है।
इसके अलावा यह वेब पर सुरक्षित है जहां आप अविश्वसनीय ग्राहकों से निपट सकते हैं। (या कम से कम, आपको हमेशा यह मानना चाहिए कि आप अविश्वसनीय ग्राहकों से निपट रहे हैं।)
जब कोई ग्राहक वेबस्केट कनेक्शन का प्रयास करता है, तो गेटवे अनुरोध प्राप्त करता है। यदि विशेष सेवा (यानी यूआरएल) को संरक्षित करने के लिए कॉन्फ़िगर किया गया है, तो ग्राहक को चुनौती दी जाएगी।
चुनौती प्राप्त करने पर ग्राहक को टोकन की आपूर्ति करने की आवश्यकता होती है (मान लीजिए कि इस मामले में कॉन्फ़िगर किया गया है)। यदि ग्राहक के पास पहले से टोकन है - क्योंकि उन्होंने पहले किसी अन्य सिस्टम या वेब पेज पर साइन ऑन किया है - तो बढ़िया। यदि नहीं तो यह एक प्राप्त किया जाना चाहिए। यह पूरी तरह से आपकी सुरक्षा की पसंद पर निर्भर करता है। इस मामले में यह टोकन प्राप्त करने के लिए OAuth टोकन प्रदाता से संपर्क करता है। इसका मतलब हो सकता है कि उपयोगकर्ता को प्रमाण-पत्र प्रदान करना है।
क्लाइंट के पास टोकन होने के बाद यह चुनौती के जवाब के रूप में गेटवे को भेजता है। गेटवे मानक जेएएएस आर्किटेक्चर का समर्थन करता है ताकि आप आवश्यक प्रमाणीकरण करने के लिए लॉगिन मॉड्यूल में प्लग कर सकें। इस मामले में यह टोकन प्रदाता को टोकन भेज सकता है ताकि यह निर्धारित किया जा सके कि यह वैध टोकन है या नहीं।
यदि यह है, तो वेबसाकेट कनेक्शन खोला गया है और जारी रख सकता है। यदि नहीं, अनुरोध अस्वीकार कर दिया गया है और कनेक्शन बंद है।
इसका आपके बैक-एंड अनुप्रयोगों की सुरक्षा का लाभ है - केवल वैध उपयोगकर्ता गेटवे से गुज़रेंगे। इसके अलावा, क्योंकि काज़िंग वेबसॉकेट गेटवे डीएमजेड में रह सकता है, गैर-प्रमाणीकृत उपयोगकर्ता कभी भी आपके मुख्य फ़ायरवॉल में विश्वसनीय नेटवर्क दर्ज नहीं करते हैं। वे बाहर पर तेजी से विफल हो जाते हैं।
यह वास्तुकला शक्तिशाली है, क्योंकि यह क्या सुरक्षा ढांचे आपके द्वारा चुनी गई कोई फर्क नहीं पड़ता, Kaazing के गेटवे यह करने के लिए प्लग होगा, बल्कि आप पर अपने स्वयं के सुरक्षा तंत्र लगाने से। इसके अलावा, ओएयूथ या ओएथ 2 के मामले में, इसे टोकन को समझने या डीकोड करने की आवश्यकता नहीं है। टोकन प्रदाता केवल एक ही इसे समझने की जरूरत है।लेकिन यदि आपका टोकन प्रदाता सत्र के लिए अवधि निर्दिष्ट करना चाहता है, जिसे टोकन के साथ शामिल किया जा सकता है और गेटवे इसका सम्मान करेगा।
यदि ब्राउज़र-आधारित एप्लिकेशन असुरक्षित हैं, तो मैं इसके साथ रह सकता हूं, लेकिन मैं यह सुनिश्चित करना चाहता हूं कि कम से कम वेब-आधारित अनुप्रयोगों में वेबसाईट तक पहुंचने का एक सुरक्षित तरीका हो।
वेब-आधारित और ब्राउज़र-आधारित अनुप्रयोगों को सही आर्किटेक्चर और कार्यान्वयन के साथ सुरक्षित बनाया जा सकता है। काज़िंग में हम हमेशा इस धारणा के तहत काम करते हैं कि आप वेब पर अविश्वसनीय ग्राहकों से निपट रहे हैं और तदनुसार हमारे वास्तुकला का निर्माण करते हैं।
सादर, रॉबिन उत्पाद प्रबंधक, Kaazing
एक अच्छा समाधान यदि कोई उपयोगकर्ता प्रमाणीकरण की जरूरत है कि, लेकिन मैं काफी यकीन है कि अगर यह काम करता है नहीं कर रहा हूँ अगर केवल क्लाइंट ओउथ -2 ड्राफ्ट http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.4 में क्लाइंट क्रेडेंशियल अनुदान में खुद को प्रमाणीकृत करने की आवश्यकता है। वहां यह भी कहता है कि इसे केवल गोपनीय ग्राहकों के लिए उपयोग किया जाना चाहिए। लेकिन यहां तक कि यदि आपके पास एक गोपनीय ग्राहक है और फिर आप ब्राउज़र को accesstoken भेजते हैं (ws कनेक्शन स्थापित करने के लिए), यह खुलासा किया गया है। तो इसे पुन: उपयोग करने से बचाने के लिए आप इस एक्सेस को अनुमति देंगे, केवल थोड़े समय के लिए इस्तेमाल किया जा सकता है या एक तक पहुंच प्रतिबंधित कर सकता है। – JustGoscha