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 चिन्ह पुढील विनंतीच्या स्कीमबद्दल काहीही सांगत नाही।