OAuth brenda një VPN: cilat segmente kërkojnë ende TLS

Rrugëtimi privat vendos kush arrin te serveri; rregullat e transportit të OAuth vendosin si udhëton çdo mesazh. Një shfletues, një server autorizimi, një pikë fundore token-i dhe një server burimesh mund të jenë të gjithë pas të njëjtit VPN dhe prapë të shkëmbejnë mesazhe nëpër segmente të ndryshme. Çdo segment ka kërkesën e vet të transportit, dhe VPN-ja nuk lehtëson asnjërën prej tyre. Kufiri i VPN-së dhe kufiri i protokollit janë dy vija të ndryshme.

Vendimi është më i lehtë nëse ndaloni së pyeturi nëse rrjeti është i besuar dhe filloni të pyesni cila shkëmbim kalon cilin kufi.

Vendosni sipas segmentit, jo sipas rrjetit

Shkruani pikat fundore ndaras: pikë fundore autorizimi, pikë fundore token-i, URI ridrejtimi, URL-ja e serverit të burimeve, pika e përfundimit të TLS dhe porta e VPN-së. Pastaj shënoni cila palë nis çdo kërkesë dhe ku shkon përgjigja.

Një VPN që përfundon në një portë kripton segmentin deri në atë portë. Kërkesa mund të vazhdojë si HTTP i thjeshtë pas saj, dhe ai segment i mbetur nuk është bërë HTTPS sepse një segment i mëparshëm u kriptua. Pikërisht ai vazhdim është segmenti për të cilin interesohet protokolli. Kriptimi i kërcimit të parë nuk e bën të sigurt kërcimin e dytë.

Transporti mbart edhe një kontroll të identitetit të shërbimit. Shfletuesi validon certifikatën për URL-në e aplikacionit; një VPN nuk e kryen atë validim në emër të shfletuesit dhe nuk e bën të pranueshëm një pikë fundore të pavaliduar. Certifikata emërton pikën fundore që klienti mendon se po thërret. Një tunel drejt një porte nuk e riemërton atë pikë fundore dhe nuk e validon atë.

Përgjigja e autorizimit dhe URI-ja e ridrejtimit

Praktika më e mirë aktuale e sigurisë e OAuth ndalon transmetimin e përgjigjeve të autorizimit përmes lidhjeve të pakriptuara. Kjo përfshin ridrejtimin që sjell kodin e autorizimit ose token-at përsëri te klienti, jo vetëm kërkesën fillestare.

I njëjti udhëzim nuk lejon URI ridrejtimi HTTP, përveç rastit të specifikuar të loopback për klientët autoktonë. Një emër host i brendshëm nuk krijon një përjashtim të ri, dhe një emër DNS që zgjidhet vetëm brenda VPN-së është ende URL HTTP nëse skema thotë kështu. Kontrolloni skemën në URI-në e regjistruar, jo vetëm emrin e hostit.

Regjistroni URI-në e saktë të ridrejtimit HTTPS te serveri i autorizimit dhe mbani të aktivizuar validimin e certifikatave në klient. Një shkurtore zhvillimi që shtyp kërkesën për HTTPS prodhon një rrjedhë që sillet ndryshe nga konfigurimi i prodhimit që supozohet të modelojë.

Pika fundore e token-it dhe kërkesat me token bartës

Kërkesa për token mbart kredenciale ose një kod që mund të shkëmbehet me akses. Dërgimi i saj përmes një segmenti të pambrojtur ekspozon material të cilit serveri i burimeve do t'i besojë më vonë, edhe pse rrjeta përreth është private. Një proxy që mund të lexojë kërkesën mund të lexojë edhe kredencialin që ajo mbart.

Për kërkesat për burime me token bartës, RFC 6750 e trajton TLS si të detyrueshëm për t'u implementuar dhe përdorur në atë specifikim. Të quash të besuar nënrrjetën e zyrës nuk është përjashtimi i përgjithshëm i protokollit që i nevojitet një vendosjeje bartëse në tekst të thjeshtë.

Përdorni URL-të e sigurta të dokumentuara të pikave fundore për të dy segmentet. Nëse një bibliotekë refuzon të thërrasë një pikë fundore token-i HTTP, ai refuzim është specifikimi që funksionon, jo një defekt konfigurimi për t'u anashkaluar. Regjistroni atë URL në konfigurimin e klientit në vend që ta nxirrni në kohën e ekzekutimit.

Ku përfundon TLS dhe çfarë lë pas

Nëse TLS përfundon në një frontend të autorizuar, emërtoni atë frontend dhe rishikoni rrugën prej tij deri te aplikacioni. Frontend-i bëhet përgjegjës për përcjelljen, besimin dhe konfidencialitetin në segmentin e mbetur, dhe arkitektura e mbështetur e shërbimit duhet ta përshkruajë atë rregullim.

Një VPN diku tjetër në rrugë nuk i zgjidh ato përgjegjësi. Gjithashtu nuk ju thotë nëse URL-ja e aplikacionit që sheh shfletuesi përputhet me certifikatën që paraqet frontend-i.

Për një vendosje të brendshme, regjistroni pikën e përfundimit dhe identitetin që paraqet. Një frontend që e përfundon TLS me një certifikatë për një emër tjetër krijon një paralajmërim shfletuesi që operatorët shpesh e shtypin në vend që ta rregullojnë.

Përjashtimi i loopback autokton është i ngushtë

Përjashtimi i ridrejtimit loopback ka të bëjë me një kthim-thirrje në pajisjen e vetë përdoruesit, ku klienti dhe shfletuesi e ndajnë atë pajisje. Ky rregullim i takon një kthim-thirrjeje në një pajisje të vetme dhe nuk jep licencë për të shërbyer një server autorizimi normal ose një API që mbart token-a përmes HTTP për një nënrrjetë zyre.

Mbani përjashtimin të kufizuar në llojin e klientit dhe në kthim-thirrjen që përshkruan. Zbatimi i tij në një aplikacion web, në një shërbim të brendshëm të përbashkët ose në një URI ridrejtimi në një host tjetër ndryshon vendosjen, jo përjashtimin.

Provoni rrjedhën reale në çdo kufi dhe krahasojeni me llojin e klientit. Një ridrejtim që funksionon nuk thotë asgjë nëse çdo segment që mbarti një token përdori mbrojtjen e kërkuar, dhe një ikonë e gjelbër VPN nuk thotë asgjë për skemën e kërkesës së ardhshme.