OAuth binnen een VPN: welke benen vereisen nog steeds TLS

Private routering bepaalt wie de server bereikt; de transportregels van OAuth bepalen hoe elk bericht reist. Een browser, een autorisatieserver, een token-eindpunt en een bronserver kunnen allemaal achter dezelfde VPN zitten en toch berichten over verschillende benen uitwisselen. Elk been heeft zijn eigen transportvereiste, en de VPN versoepelt er geen enkele. De VPN-grens en de protocolgrens zijn twee verschillende lijnen.

De beslissing is eenvoudiger als u ophoudt te vragen of het netwerk vertrouwd is en begint te vragen welke uitwisseling welke grens oversteekt.

Beslis per been, niet per netwerk

Schrijf de eindpunten afzonderlijk op: autorisatie-eindpunt, token-eindpunt, omleidings-URI, URL van de bronserver, TLS-eindpunt en VPN-gateway. Markeer daarna welke partij elk verzoek start en waar het antwoord naartoe gaat.

Een VPN die bij een gateway eindigt, versleutelt het segment tot die gateway. Het verzoek kan erachter als gewoon HTTP doorgaan, en dat resterende been is niet HTTPS geworden omdat een eerder segment versleuteld was. Precies die voortzetting is het been waar het protocol om geeft. Het eerste hop versleutelen maakt het tweede hop niet veilig.

Het transport draagt ook een controle van de dienstidentiteit. De browser valideert het certificaat voor de URL van de toepassing; een VPN voert die validatie niet namens de browser uit en maakt een ongevalideerd eindpunt niet aanvaardbaar. Het certificaat noemt het eindpunt dat de client denkt aan te roepen. Een tunnel naar een gateway hernoemt dat eindpunt niet en valideert het niet.

De autorisatierespons en de omleidings-URI

De huidige beste beveiligingspraktijk van OAuth verbiedt het verzenden van autorisatieresponsen over onversleutelde verbindingen. Dat omvat de omleiding die de autorisatiecode of tokens terug naar de client brengt, niet alleen het eerste verzoek.

Dezelfde richtlijn staat HTTP-omleidings-URI's niet toe, behalve het genoemde loopback-geval voor native clients. Een interne hostnaam schept geen nieuwe uitzondering, en een DNS-naam die alleen binnen de VPN wordt opgelost is nog steeds een HTTP-URL als het schema dat zegt. Controleer het schema in de geregistreerde URI, niet alleen de hostnaam.

Registreer de exacte HTTPS-omleidings-URI bij de autorisatieserver en houd certificaatvalidatie aan op de client. Een ontwikkelingskortere weg die de HTTPS-eis onderdrukt, levert een stroom op die zich anders gedraagt dan de productieconfiguratie die hij hoort te modelleren.

Het token-eindpunt en verzoeken met bearer-token

Het tokenverzoek draagt inloggegevens of een code die tegen toegang kan worden ingewisseld. Het over een onbeschermd been sturen legt materiaal bloot dat de bronserver later vertrouwt, zelfs als het omringende netwerk privé is. Een proxy die het verzoek kan lezen, kan ook de inloggegevens lezen die het draagt.

Voor bronverzoeken met bearer-token behandelt RFC 6750 TLS als verplicht om te implementeren en te gebruiken voor die specificatie. Het kantoor-subnet vertrouwd noemen is niet de algemene protocoluitzondering die een bearer-implementatie in platte tekst nodig heeft.

Gebruik de gedocumenteerde veilige eindpunt-URL's voor beide benen. Als een bibliotheek weigert een HTTP-token-eindpunt aan te roepen, is die weigering de specificatie die werkt, geen configuratiefout om te omzeilen. Leg die URL vast in de clientconfiguratie in plaats van hem tijdens runtime af te leiden.

Waar TLS eindigt en wat dat achterlaat

Als TLS bij een geautoriseerde frontend eindigt, noem die frontend en beoordeel het pad van daar naar de toepassing. De frontend wordt verantwoordelijk voor doorsturen, vertrouwen en vertrouwelijkheid op het resterende segment, en de ondersteunde architectuur van de dienst hoort die regeling te beschrijven.

Een VPN elders op het pad beslecht die verantwoordelijkheden niet. Hij vertelt u ook niet of de toepassings-URL die de browser ziet overeenkomt met het certificaat dat de frontend presenteert.

Leg voor een interne implementatie het eindpunt en de identiteit die het presenteert vast. Een frontend die TLS met een certificaat voor een andere naam beëindigt, veroorzaakt een browserwaarschuwing die beheerders vaak onderdrukken in plaats van oplossen.

De uitzondering voor native loopback is smal

De loopback-omleidingsuitzondering betreft een callback op het eigen apparaat van de gebruiker, waar de client en de browser dat apparaat delen. Die regeling hoort bij een callback op één apparaat en geeft geen vergunning om een gewone autorisatieserver of een API met tokens via HTTP aan een kantoor-subnet te leveren.

Houd de uitzondering beperkt tot het clienttype en de callback die zij beschrijft. Haar toepassen op een webtoepassing, een gedeelde interne dienst of een omleidings-URI op een andere host verandert de implementatie, niet de uitzondering.

Test de werkelijke stroom bij elke grens en vergelijk die met het clienttype. Een werkende omleiding zegt niets over de vraag of elk been dat een token droeg de vereiste bescherming gebruikte, en een groen VPN-pictogram zegt niets over het schema van het volgende verzoek.