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 आइकन अगले अनुरोध की स्कीम के बारे में कुछ नहीं कहता।