OAuth uvnitř VPN: které úseky stále vyžadují TLS

Soukromé směrování rozhoduje, kdo se dostane na server; pravidla přenosu OAuth rozhodují, jak cestuje každá zpráva. Prohlížeč, autorizační server, koncový bod tokenu a server zdrojů mohou všichni sedět za stejnou VPN a přesto si vyměňovat zprávy přes různé úseky. Každý úsek má svůj vlastní požadavek na přenos a VPN žádný z nich nezmírňuje. Hranice VPN a hranice protokolu jsou dvě různé linie.

Rozhodnutí je snazší, když přestanete ptát, zda je síť důvěryhodná, a začnete se ptát, která výměna přechází kterou hranici.

Rozhodujte podle úseku, ne podle sítě

Zapište koncové body odděleně: autorizační koncový bod, koncový bod tokenu, URI přesměrování, URL serveru zdrojů, bod ukončení TLS a bránu VPN. Potom označte, která strana zahajuje každý požadavek a kam jde odpověď.

VPN, která končí na bráně, šifruje segment k této bráně. Požadavek může za ní pokračovat jako obyčejný HTTP a tento zbývající úsek se nestal HTTPS jen proto, že byl dřívější segment zašifrován. Právě toto pokračování je úsek, na kterém protokolu záleží. Zašifrování prvního skoku nedělá druhý skok bezpečným.

Přenos nese také kontrolu identity služby. Prohlížeč ověřuje certifikát pro URL aplikace; VPN toto ověření neprovádí za prohlížeč a nečiní neověřený koncový bod přijatelným. Certifikát pojmenovává koncový bod, o kterém se klient domnívá, že ho volá. Tunel k bráně tento koncový bod nepřejmenovává ani neověřuje.

Odpověď autorizace a URI přesměrování

Nejlepší současná bezpečnostní praxe OAuth zakazuje přenášet odpovědi autorizace přes nešifrovaná spojení. To zahrnuje přesměrování, které nese autorizační kód nebo tokeny zpět klientovi, nejen počáteční požadavek.

Stejné doporučení zakazuje URI přesměrování HTTP s výjimkou uvedeného případu loopbacku pro nativního klienta. Interní název hostitele nevytváří novou výjimku a název DNS, který se překládá jen uvnitř VPN, je stále URL HTTP, pokud to schéma říká. Kontrolujte schéma v registrovaném URI, ne jen název hostitele.

Zaregistrujte přesné URI přesměrování HTTPS u autorizačního serveru a ponechte ověřování certifikátů v klientovi zapnuté. Vývojová zkratka, která potlačuje požadavek HTTPS, vytváří tok, který se chová jinak než produkční konfigurace, kterou má modelovat.

Koncový bod tokenu a požadavky s bearer tokenem

Požadavek na token nese přihlašovací údaje nebo kód, který lze vyměnit za přístup. Jeho odeslání přes nechráněný úsek vystavuje materiál, kterému bude server zdrojů později důvěřovat, i když je okolní síť soukromá. Proxy, která dokáže požadavek přečíst, dokáže přečíst i údaj, který nese.

U požadavků na zdroje s bearer tokenem považuje RFC 6750 TLS za povinné implementovat a používat podle této specifikace. Označit kancelářskou podsíť za důvěryhodnou není obecná výjimka protokolu, kterou nasazení s bearer tokeny v otevřeném textu potřebuje.

Použijte dokumentované bezpečné URL koncových bodů pro oba úseky. Pokud knihovna odmítá volat koncový bod tokenu přes HTTP, toto odmítnutí je specifikace, která funguje, ne konfigurační chyba k obejití. Zapište toto URL do konfigurace klienta, místo abyste ho odvozovali za běhu.

Kde TLS končí a co to zanechává

Pokud TLS končí na autorizovaném frontendu, pojmenujte tento frontend a projděte cestu od něj k aplikaci. Frontend se stává odpovědným za předávání, důvěru a důvěrnost na zbývajícím segmentu a podporovaná architektura služby by toto uspořádání měla popisovat.

VPN jinde na cestě tyto odpovědnosti neřeší. Také vám neříká, zda URL aplikace, které vidí prohlížeč, odpovídá certifikátu, který frontend předkládá.

Pro interní nasazení zaznamenejte bod ukončení a identitu, kterou předkládá. Frontend, který ukončuje TLS certifikátem pro jiné jméno, vytváří varování prohlížeče, které operátoři často potlačují, místo aby je opravili.

Výjimka pro nativní loopback je úzká

Výjimka přesměrování loopback se týká zpětného volání na vlastním zařízení uživatele, kde klient a prohlížeč toto zařízení sdílejí. Toto uspořádání patří zpětnému volání na jednom zařízení a neopravňuje obsluhovat běžný autorizační server nebo API s tokeny přes HTTP do kancelářské podsítě.

Držte výjimku omezenou na typ klienta a zpětné volání, které popisuje. Její použití na webovou aplikaci, sdílenou interní službu nebo URI přesměrování na jiném hostiteli mění nasazení, ne výjimku.

Otestujte skutečný tok na každé hranici a porovnejte ho s typem klienta. Fungující přesměrování neříká nic o tom, zda každý úsek, který nesl token, použil požadovanou ochranu, a zelená ikona VPN neříká nic o schématu dalšího požadavku.