VPN भित्रको OAuth: कुन चरणहरूलाई अझै TLS चाहिन्छ

निजी रुटिङले कसले सर्भरमा पुग्छ भन्ने निर्धारण गर्छ; OAuth का यातायात नियमहरूले प्रत्येक सन्देश कसरी यात्रा गर्छ भन्ने निर्धारण गर्छन्। ब्राउजर, अनुमति सर्भर, टोकन अन्त्य बिन्दु र स्रोत सर्भर सबै एउटै VPN पछाडि हुन सक्छन् र तैपनि फरक फरक चरणहरूबाट सन्देश आदानप्रदान गर्न सक्छन्। प्रत्येक चरणको आफ्नै यातायात आवश्यकता छ, र VPN ले तीमध्ये कुनैलाई पनि खुकुलो बनाउँदैन। VPN को सीमा र प्रोटोकलको सीमा दुई फरक रेखा हुन्।

नेटवर्क विश्वसनीय छ कि छैन भनेर सोध्न छोडेर कुन आदानप्रदान कुन सीमा पार गर्छ भनेर सोध्न थाल्नुभयो भने निर्णय सजिलो हुन्छ।

नेटवर्क अनुसार होइन, चरण अनुसार निर्णय गर्नुहोस्

अन्त्य बिन्दुहरू अलग अलग लेख्नुहोस्: अनुमति अन्त्य बिन्दु, टोकन अन्त्य बिन्दु, रिडिरेक्ट URI, स्रोत सर्भरको URL, TLS अन्त्य बिन्दु र VPN गेटवे। त्यसपछि प्रत्येक अनुरोध कुन पक्षले सुरु गर्छ र प्रतिक्रिया कहाँ जान्छ चिन्ह लगाउनुहोस्।

गेटवेमा अन्त्य हुने VPN ले त्यो गेटवेसम्मको खण्ड इन्क्रिप्ट गर्छ। अनुरोध त्यसको पछाडि साधारण HTTP को रूपमा जारी रहन सक्छ, र अघिल्लो खण्ड इन्क्रिप्ट भएकोले त्यो बाँकी चरण HTTPS भएको छैन। त्यही निरन्तरता नै प्रोटोकललाई महत्त्वपूर्ण चरण हो। पहिलो फड्को इन्क्रिप्ट गर्दा दोस्रो फड्को सुरक्षित हुँदैन।

यातायातले सेवा पहिचानको जाँच पनि बोक्छ। ब्राउजरले अनुप्रयोगको URL को प्रमाणपत्र प्रमाणित गर्छ; VPN ले त्यो जाँच ब्राउजरको तर्फबाट गर्दैन, र अप्रमाणित अन्त्य बिन्दुलाई स्वीकार्य बनाउँदैन। प्रमाणपत्रले ग्राहकले कल गरिरहेको ठान्ने अन्त्य बिन्दुको नाम दिन्छ। गेटवेतर्फ जाने सुरुङले त्यो अन्त्य बिन्दुको नाम परिवर्तन गर्दैन वा प्रमाणित गर्दैन।

अनुमति प्रतिक्रिया र रिडिरेक्ट URI

OAuth को वर्तमान उत्कृष्ट सुरक्षा अभ्यासले इन्क्रिप्ट नगरिएका जडानहरूमा अनुमति प्रतिक्रियाहरू पठाउन निषेध गर्छ। यसले प्रारम्भिक अनुरोध मात्र नभई अनुमति कोड वा टोकन ग्राहकतर्फ फर्काउने रिडिरेक्ट पनि समेट्छ।

त्यही मार्गदर्शनले निर्दिष्ट नेटिभ-ग्राहक लुपब्याक अवस्था बाहेक HTTP रिडिरेक्ट URI लाई अनुमति दिँदैन। आन्तरिक होस्टनामले नयाँ अपवाद सिर्जना गर्दैन, र VPN भित्र मात्र समाधान हुने DNS नाम, स्किमले त्यसो भन्यो भने, अझै HTTP URL हो। दर्ता गरिएको URI मा स्किम जाँच्नुहोस्, होस्टनाम मात्र होइन।

ठ्याक्कै HTTPS रिडिरेक्ट URI अनुमति सर्भरमा दर्ता गर्नुहोस् र ग्राहकमा प्रमाणपत्र प्रमाणीकरण खुला राख्नुहोस्। HTTPS आवश्यकता दबाउने विकास सर्टकटले आफूले अनुकरण गर्नुपर्ने उत्पादन कन्फिगरेसनभन्दा फरक व्यवहार गर्ने प्रवाह उत्पादन गर्छ।

टोकन अन्त्य बिन्दु र बियरर टोकन अनुरोधहरू

टोकन अनुरोधले पहुँचसँग साट्न सकिने प्रमाणहरू वा कोड बोक्छ। असंरक्षित चरणमा पठाउँदा वरपरको नेटवर्क निजी भए पनि स्रोत सर्भरले पछि विश्वास गर्ने सामग्री खुलासा हुन्छ। अनुरोध पढ्न सक्ने प्रोक्सीले त्यसले बोकेको प्रमाण पनि पढ्न सक्छ।

बियरर टोकन भएका स्रोत अनुरोधहरूका लागि RFC 6750 ले त्यो स्पेसिफिकेसनमा TLS लाई कार्यान्वयन र प्रयोग गर्न अनिवार्य मान्छ। कार्यालय सबनेटलाई विश्वसनीय भन्नु साधारण पाठ बियरर तैनाथीलाई चाहिने सामान्य प्रोटोकल अपवाद होइन।

दुवै चरणका लागि कागजात गरिएका सुरक्षित अन्त्य बिन्दु URL प्रयोग गर्नुहोस्। यदि पुस्तकालयले HTTP टोकन अन्त्य बिन्दु कल गर्न अस्वीकार गर्छ भने त्यो अस्वीकार स्पेसिफिकेसन काम गरिरहेको हो, छल्नुपर्ने कन्फिगरेसन त्रुटि होइन। त्यो URL रनटाइममा निकाल्नुको सट्टा ग्राहक कन्फिगरेसनमा लेख्नुहोस्।

TLS कहाँ अन्त्य हुन्छ र त्यसले के छोड्छ

यदि TLS अधिकृत फ्रन्टएन्डमा अन्त्य हुन्छ भने त्यो फ्रन्टएन्डको नाम लिनुहोस् र त्यहाँबाट अनुप्रयोगसम्मको बाटो समीक्षा गर्नुहोस्। फ्रन्टएन्ड बाँकी खण्डमा अग्रसरण, विश्वास र गोपनीयताको जिम्मेवार हुन्छ, र सेवाको समर्थित वास्तुकलाले त्यो व्यवस्था वर्णन गर्नुपर्छ।

बाटोमा अन्यत्र रहेको VPN ले ती जिम्मेवारीहरू समाधान गर्दैन। ब्राउजरले देख्ने अनुप्रयोग URL फ्रन्टएन्डले प्रस्तुत गर्ने प्रमाणपत्रसँग मिल्छ कि मिल्दैन भन्ने पनि यसले बताउँदैन।

आन्तरिक तैनाथीका लागि अन्त्य बिन्दु र यसले प्रस्तुत गर्ने पहिचान लेख्नुहोस्। फरक नामको प्रमाणपत्रसँग TLS अन्त्य गर्ने फ्रन्टएन्डले ब्राउजर चेतावनी सिर्जना गर्छ जसलाई अपरेटरहरूले सुधार गर्नुको सट्टा प्रायः दबाउँछन्।

नेटिभ लुपब्याक अपवाद साँघुरो छ

लुपब्याक रिडिरेक्ट अपवाद प्रयोगकर्ताको आफ्नै उपकरणमा हुने कलब्याकसँग सम्बन्धित छ, जहाँ ग्राहक र ब्राउजरले त्यो उपकरण साझा गर्छन्। त्यो व्यवस्था एउटै उपकरणको कलब्याकसँग सम्बन्धित छ, र यसले कार्यालय सबनेटलाई HTTP मार्फत सामान्य अनुमति सर्भर वा टोकन बोक्ने API उपलब्ध गराउन अनुमति दिँदैन।

अपवादलाई यसले वर्णन गर्ने ग्राहक प्रकार र कलब्याकमा सीमित राख्नुहोस्। यसलाई वेब अनुप्रयोग, साझा आन्तरिक सेवा वा अर्को होस्टको रिडिरेक्ट URI मा लागू गर्दा तैनाथी बदलिन्छ, अपवाद होइन।

प्रत्येक सीमामा वास्तविक प्रवाह परीक्षण गर्नुहोस् र ग्राहक प्रकारसँग तुलना गर्नुहोस्। काम गर्ने रिडिरेक्टले टोकन बोकेको प्रत्येक चरणले आवश्यक सुरक्षा प्रयोग गर्यो कि भन्ने बारे केही भन्दैन, र हरियो VPN प्रतीकले अर्को अनुरोधको स्किमबारे केही भन्दैन।