OAuth în interiorul unui VPN: ce segmente încă necesită TLS

Rutarea privată decide cine ajunge la server; regulile de transport ale OAuth decid cum călătorește fiecare mesaj. Un browser, un server de autorizare, un punct final de token și un server de resurse pot sta toate în spatele aceluiași VPN și totuși pot schimba mesaje pe segmente diferite. Fiecare segment are propria cerință de transport, iar VPN-ul nu relaxează niciuna dintre ele. Granița VPN-ului și granița protocolului sunt două linii diferite.

Decizia este mai ușoară dacă încetați să întrebați dacă rețeaua este de încredere și începeți să întrebați care schimb traversează care graniță.

Decideți pe segment, nu pe rețea

Notați punctele finale separat: punct final de autorizare, punct final de token, URI de redirecționare, URL-ul serverului de resurse, punctul de terminare TLS și gateway-ul VPN. Apoi marcați care parte inițiază fiecare cerere și unde merge răspunsul.

Un VPN care se termină la un gateway criptează segmentul până la acel gateway. Cererea poate continua ca HTTP simplu în spatele lui, iar acel segment rămas nu a devenit HTTPS pentru că un segment anterior a fost criptat. Exact acea continuare este segmentul de care îi pasă protocolului. Criptarea primului salt nu face al doilea salt sigur.

Transportul poartă și o verificare a identității serviciului. Browserul validează certificatul pentru URL-ul aplicației; un VPN nu efectuează acea validare în numele browserului și nu face acceptabil un punct final nevalidat. Certificatul numește punctul final pe care clientul crede că îl apelează. Un tunel către un gateway nu redenumește acel punct final și nu îl validează.

Răspunsul de autorizare și URI-ul de redirecționare

Cea mai bună practică actuală de securitate a OAuth interzice transmiterea răspunsurilor de autorizare pe conexiuni necriptate. Aceasta acoperă redirecționarea care duce codul de autorizare sau tokenurile înapoi la client, nu doar cererea inițială.

Aceeași îndrumare nu permite URI-uri de redirecționare HTTP, cu excepția cazului loopback specificat pentru clienții nativi. Un nume de gazdă intern nu creează o excepție nouă, iar un nume DNS care se rezolvă doar în interiorul VPN-ului este în continuare un URL HTTP dacă schema spune asta. Verificați schema din URI-ul înregistrat, nu doar numele de gazdă.

Înregistrați URI-ul de redirecționare HTTPS exact la serverul de autorizare și mențineți validarea certificatelor activă pe client. O scurtătură de dezvoltare care suprimă cerința HTTPS produce un flux care se comportă diferit de configurația de producție pe care ar trebui să o modeleze.

Punctul final de token și cererile cu token purtător

Cererea de token poartă acreditări sau un cod care poate fi schimbat pe acces. Trimiterea ei pe un segment neprotejat expune material în care serverul de resurse va avea încredere mai târziu, chiar dacă rețeaua din jur este privată. Un proxy care poate citi cererea poate citi și acreditarea pe care o poartă.

Pentru cererile de resurse cu token purtător, RFC 6750 consideră TLS obligatoriu de implementat și de utilizat pentru acea specificație. A numi subrețeaua biroului de încredere nu este excepția generală de protocol de care are nevoie o implementare purtătoare în text simplu.

Folosiți URL-urile securizate documentate ale punctelor finale pentru ambele segmente. Dacă o bibliotecă refuză să apeleze un punct final de token HTTP, acel refuz este specificația care funcționează, nu un defect de configurare de ocolit. Înregistrați acel URL în configurația clientului în loc să îl derivați la execuție.

Unde se termină TLS și ce lasă asta

Dacă TLS se termină la un frontend autorizat, numiți acel frontend și revizuiți calea de la el la aplicație. Frontendul devine responsabil pentru redirecționare, încredere și confidențialitate pe segmentul rămas, iar arhitectura suportată a serviciului ar trebui să descrie acea aranjare.

Un VPN în altă parte a căii nu rezolvă acele responsabilități. De asemenea, nu vă spune dacă URL-ul aplicației pe care îl vede browserul corespunde certificatului pe care îl prezintă frontendul.

Pentru o implementare internă, notați punctul de terminare și identitatea pe care o prezintă. Un frontend care termină TLS cu un certificat pentru alt nume creează o avertizare de browser pe care operatorii o suprimă adesea în loc să o corecteze.

Excepția pentru loopback nativ este îngustă

Excepția de redirecționare loopback privește un apel invers pe dispozitivul utilizatorului însuși, unde clientul și browserul partajează acel dispozitiv. Acea aranjare aparține unui apel invers pe un singur dispozitiv și nu autorizează servirea unui server de autorizare normal sau a unui API care poartă tokenuri prin HTTP către o subrețea de birou.

Păstrați excepția limitată la tipul de client și la apelul invers pe care îl descrie. Aplicarea ei unei aplicații web, unui serviciu intern partajat sau unui URI de redirecționare pe altă gazdă schimbă implementarea, nu excepția.

Testați fluxul real la fiecare graniță și comparați-l cu tipul de client. O redirecționare funcțională nu spune nimic despre dacă fiecare segment care a purtat un token a folosit protecția cerută, iar o pictogramă VPN verde nu spune nimic despre schema următoarei cereri.