OAuth sa loob ng VPN: aling mga bahagi ang kailangan pa rin ng TLS

Ang pribadong ruta ang nagpapasya kung sino ang nakakaabot sa server; ang mga patakaran sa transportasyon ng OAuth ang nagpapasya kung paano naglalakbay ang bawat mensahe. Ang browser, authorization server, token endpoint at resource server ay maaaring lahat nasa likod ng iisang VPN at nagpapalitan pa rin ng mga mensahe sa magkakaibang bahagi. May sariling pangangailangan sa transportasyon ang bawat bahagi, at hindi binibigyang-luwag ng VPN ang alinman sa mga ito. Magkaibang linya ang hangganan ng VPN at ang hangganan ng protocol.

Mas madali ang desisyon kung ititigil mo ang pagtatanong kung mapagkakatiwalaan ang network at magsimula kang magtanong kung aling palitan ang tumatawid sa aling hangganan.

Magpasya ayon sa bahagi, hindi ayon sa network

Isulat nang hiwalay ang mga endpoint: authorization endpoint, token endpoint, redirect URI, URL ng resource server, punto ng pagtatapos ng TLS at VPN gateway. Pagkatapos, markahan kung aling partido ang nagpapasimula ng bawat kahilingan at saan napupunta ang tugon.

Ang VPN na nagtatapos sa isang gateway ay nag-e-encrypt ng bahagi papunta sa gateway na iyon. Maaaring magpatuloy ang kahilingan bilang plain HTTP sa likod nito, at ang natitirang bahaging iyon ay hindi naging HTTPS dahil na-encrypt ang naunang bahagi. Ang pagpapatuloy na iyon ang bahaging pinapahalagahan ng protocol. Ang pag-encrypt sa unang hop ay hindi ginagawang secure ang ikalawang hop.

May dalang pagsusuri ng pagkakakilanlan ng serbisyo ang transportasyon. Pinapatunayan ng browser ang certificate para sa URL ng application; hindi ginagawa ng VPN ang pagsusuring iyon sa ngalan ng browser, at hindi nito ginagawang katanggap-tanggap ang isang endpoint na hindi napatunayan. Pinapangalanan ng certificate ang endpoint na inaakalang tinatawagan ng client. Ang tunnel papunta sa gateway ay hindi nagpapalit ng pangalan ng endpoint na iyon ni nagbibigay-katwiran dito.

Ang tugon ng awtorisasyon at ang redirect URI

Ipinagbabawal ng kasalukuyang pinakamahusay na kasanayan sa seguridad ng OAuth ang pagpapadala ng mga tugon ng awtorisasyon sa mga koneksyong hindi naka-encrypt. Sakop nito ang redirect na nagdadala ng authorization code o token pabalik sa client, hindi lamang ang paunang kahilingan.

Ipinagbabawal din ng parehong patnubay ang mga redirect URI na HTTP maliban sa tinukoy na kaso ng loopback ng native client. Ang panloob na hostname ay hindi gumagawa ng bagong eksepsyon, at ang pangalang DNS na lumulutas lamang sa loob ng VPN ay HTTP URL pa rin kung sinasabi ng scheme. Suriin ang scheme sa nakarehistrong URI, hindi lamang ang hostname.

Irehistro ang eksaktong HTTPS redirect URI sa authorization server at panatilihing naka-enable ang pagpapatunay ng certificate sa client. Ang shortcut sa pag-develop na nag-aalis ng pangangailangang HTTPS ay gumagawa ng flow na kumikilos nang iba sa production configuration na dapat nitong gayahin.

Ang token endpoint at ang mga kahilingang bearer-token

Nagdadala ang kahilingan ng token ng mga kredensyal o code na maaaring ipalit sa access. Ang pagpapadala nito sa bahaging walang proteksyon ay naglalantad ng materyal na pagtitiwalaan ng resource server sa kalaunan, kahit pribado ang nakapaligid na network. Ang proxy na makababasa ng kahilingan ay makababasa rin ng kredensyal na dala nito.

Para sa mga kahilingan sa resource na bearer-token, itinuturing ng RFC 6750 na mandatory ang TLS na ipatupad at gamitin para sa espesipikasyong iyon. Ang pagsabing mapagkakatiwalaan ang subnet ng opisina ay hindi ang pangkalahatang eksepsyon sa protocol na kailangan ng plaintext bearer deployment.

Gamitin ang mga dokumentadong secure endpoint URL para sa parehong bahagi. Kung tumatanggi ang isang library na tawagan ang HTTP token endpoint, ang pagtangging iyon ay ang espesipikasyong gumagana, hindi bug sa configuration na dapat lampasan. Itala ang URL na iyon sa configuration ng client sa halip na kunin ito sa runtime.

Saan nagtatapos ang TLS at ano ang natitira

Kung nagtatapos ang TLS sa isang awtorisadong frontend, pangalanan ang frontend na iyon at suriin ang landas mula rito patungo sa application. Nagiging responsable ang frontend sa pagpapasa, pagtitiwala at pagiging kompidensyal sa natitirang bahagi, at dapat ilarawan ng sinusuportahang arkitektura ng serbisyo ang kaayusang iyon.

Ang VPN sa ibang bahagi ng landas ay hindi nagtatakda ng mga responsibilidad na iyon. Hindi rin nito sinasabi kung ang URL ng application na nakikita ng browser ay tumutugma sa certificate na inihaharap ng frontend.

Para sa panloob na deployment, itala ang punto ng pagtatapos at ang pagkakakilanlang inihaharap nito. Ang frontend na nagtatapos ng TLS gamit ang certificate para sa ibang pangalan ay lumilikha ng babala sa browser na kadalasang pinipigilan ng mga operator sa halip na ayusin.

Makitid ang eksepsyon sa native loopback

Ang eksepsyon sa loopback redirect ay tungkol sa callback sa sariling device ng gumagamit, kung saan ibinabahagi ng client at browser ang device na iyon. Ang kaayusang iyon ay para sa callback sa isang device, at hindi ito nagbibigay-lisensya na maghatid ng normal na authorization server o API na may token sa pamamagitan ng HTTP papunta sa subnet ng opisina.

Panatilihing saklaw ng eksepsyon ang uri ng client at ang callback na inilalarawan nito. Ang paglalapat nito sa web application, sa pinagsasaluhang panloob na serbisyo o sa redirect URI sa ibang host ay nagbabago ng deployment, hindi ng eksepsyon.

Subukan ang aktwal na flow sa bawat hangganan at ihambing ito sa uri ng client. Ang gumaganang redirect ay walang sinasabi kung ang bawat bahaging nagdala ng token ay gumamit ng kinakailangang proteksyon, at ang berdeng icon ng VPN ay walang sinasabi tungkol sa scheme ng susunod na kahilingan.