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 అవసరాన్ని అణచివేసే అభివృద్ధి షార్ట్కట్, అది అనుకరించాల్సిన ఉత్పత్తి కాన్ఫిగరేషన్ నుండి భిన్నంగా ప్రవర్తించే ప్రవాహాన్ని ఉత్పత్తి చేస్తుంది.

టోకెన్ ఎండ్పాయింట్ మరియు బేరర్ టోకెన్ అభ్యర్థనలు

టోకెన్ అభ్యర్థన యాక్సెస్ కోసం మార్పిడి చేయగల ఆధారాలు లేదా కోడ్ను మోస్తుంది. రక్షించని భాగంపై దాన్ని పంపడం, చుట్టుపక్కల నెట్వర్క్ ప్రైవేట్గా ఉన్నా, వనరుల సర్వర్ తర్వాత నమ్మే పదార్థాన్ని బహిర్గతం చేస్తుంది. అభ్యర్థనను చదవగల ప్రాక్సీ అది మోసే ఆధారాన్ని కూడా చదవగలదు.

బేరర్ టోకెన్తో వనరుల అభ్యర్థనలకు, ఆ స్పెసిఫికేషన్లో TLSను అమలు చేయడం మరియు ఉపయోగించడం RFC 6750 తప్పనిసరి అని భావిస్తుంది. కార్యాలయ ఉపనెట్వర్క్ను విశ్వసనీయమని పిలవడం సాదా పాఠ్య బేరర్ అమరికకు అవసరమైన సాధారణ ప్రోటోకాల్ మినహాయింపు కాదు.

రెండు భాగాలకూ పత్రీకరించిన సురక్షిత ఎండ్పాయింట్ URLలను ఉపయోగించండి. ఒక లైబ్రరీ HTTP టోకెన్ ఎండ్పాయింట్ను పిలవడానికి నిరాకరిస్తే, ఆ నిరాకరణ స్పెసిఫికేషన్ పని చేస్తున్నట్టు, తప్పించుకోవాల్సిన కాన్ఫిగరేషన్ లోపం కాదు. ఆ URLను రన్టైమ్లో పొందడం బదులు క్లయింట్ కాన్ఫిగరేషన్లో నమోదు చేయండి.

TLS ఎక్కడ ముగుస్తుంది మరియు అది ఏమి మిగులుస్తుంది

TLS అధికారిక ఫ్రంట్ఎండ్ వద్ద ముగిస్తే, ఆ ఫ్రంట్ఎండ్ను పేర్కొని, దాని నుండి అప్లికేషన్ వరకు మార్గాన్ని సమీక్షించండి. మిగిలిన భాగంలో ఫార్వార్డింగ్, విశ్వాసం మరియు గోప్యతకు ఫ్రంట్ఎండ్ బాధ్యత వహిస్తుంది, సేవ యొక్క మద్దతు నిర్మాణం ఆ ఏర్పాటును వివరించాలి.

మార్గంలో వేరే చోట ఉన్న VPN ఆ బాధ్యతలను పరిష్కరించదు. బ్రౌజర్ చూసే అప్లికేషన్ URL ఫ్రంట్ఎండ్ చూపించే ధృవపత్రంతో సరిపోతుందో లేదో కూడా అది చెప్పదు.

అంతర్గత అమరిక కోసం, ముగింపు బిందువును మరియు అది చూపించే గుర్తింపును నమోదు చేయండి. వేరే పేరు కోసం ధృవపత్రంతో TLSను ముగించే ఫ్రంట్ఎండ్, నిర్వాహకులు సరిచేయడం బదులు తరచుగా అణచివేసే బ్రౌజర్ హెచ్చరికను సృష్టిస్తుంది.

నేటివ్ లూప్బ్యాక్ మినహాయింపు ఇరుకైనది

లూప్బ్యాక్ రీడైరెక్ట్ మినహాయింపు వినియోగదారు స్వంత పరికరంలో జరిగే తిరిగి-కాల్కు సంబంధించినది, అక్కడ క్లయింట్ మరియు బ్రౌజర్ ఆ పరికరాన్ని పంచుకుంటాయి. ఆ ఏర్పాటు ఒకే పరికరంపై తిరిగి-కాల్కు చెందుతుంది, కార్యాలయ ఉపనెట్వర్క్కు HTTP ద్వారా సాధారణ అనుమతి సర్వర్ను లేదా టోకెన్ మోసే APIని అందించడానికి అది అనుమతి ఇవ్వదు.

మినహాయింపును అది వివరించే క్లయింట్ రకం మరియు తిరిగి-కాల్కు పరిమితంగా ఉంచండి. దాన్ని వెబ్ అప్లికేషన్, పంచుకున్న అంతర్గత సేవ లేదా మరో హోస్ట్లోని రీడైరెక్ట్ URIకు వర్తింపజేయడం అమరికను మారుస్తుంది, మినహాయింపును కాదు.

ప్రతి సరిహద్దులో వాస్తవ ప్రవాహాన్ని పరీక్షించి క్లయింట్ రకంతో పోల్చండి. పని చేసే రీడైరెక్ట్, టోకెన్ మోసిన ప్రతి భాగం అవసరమైన రక్షణను ఉపయోగించిందా అనే దాని గురించి ఏమీ చెప్పదు, ఆకుపచ్చ VPN చిహ్నం తదుపరి అభ్యర్థన స్కీమ్ గురించి ఏమీ చెప్పదు.