OAuth inde i en VPN: hvilke ben kræver stadig TLS

Privat routing afgør, hvem der når serveren; OAuth's transportregler afgør, hvordan hver besked rejser. En browser, en autorisationsserver, et token-endepunkt og en ressourceserver kan alle ligge bag samme VPN og stadig udveksle beskeder over forskellige ben. Hvert ben har sit eget transportkrav, og VPN'en lemper ikke på noget af dem. VPN-grænsen og protokolgrænsen er to forskellige linjer.

Beslutningen er lettere, hvis du holder op med at spørge, om netværket er betroet, og begynder at spørge, hvilken udveksling der krydser hvilken grænse.

Afgør efter ben, ikke efter netværk

Skriv endepunkterne ned hver for sig: autorisationsendepunkt, token-endepunkt, omdirigerings-URI, ressourceserverens URL, TLS-afslutningspunkt og VPN-gateway. Markér derefter, hvilken part der starter hver anmodning, og hvor svaret går hen.

En VPN, der afsluttes ved en gateway, krypterer strækningen til den gateway. Anmodningen kan fortsætte som almindelig HTTP bag den, og det resterende ben er ikke blevet HTTPS, fordi en tidligere strækning blev krypteret. Netop den fortsættelse er det ben, protokollen bekymrer sig om. Kryptering af første hop gør ikke andet hop sikkert.

Transporten bærer også en kontrol af tjenestens identitet. Browseren validerer certifikatet for applikationens URL; en VPN udfører ikke den validering på browserens vegne og gør ikke et uvalideret endepunkt acceptabelt. Certifikatet navngiver det endepunkt, som klienten tror, den kalder. En tunnel til en gateway omdøber ikke det endepunkt og validerer det ikke.

Autorisationssvaret og omdirigerings-URI'en

OAuth's nuværende bedste sikkerhedspraksis forbyder at sende autorisationssvar over ukrypterede forbindelser. Det dækker omdirigeringen, der bærer autorisationskoden eller tokens tilbage til klienten, ikke kun den første anmodning.

Samme vejledning tillader ikke HTTP-omdirigerings-URI'er bortset fra det angivne loopback-tilfælde for native klienter. Et internt værtsnavn skaber ikke en ny undtagelse, og et DNS-navn, der kun opløses inde i VPN'en, er stadig en HTTP-URL, hvis skemaet siger det. Kontrollér skemaet i den registrerede URI, ikke kun værtsnavnet.

Registrér den nøjagtige HTTPS-omdirigerings-URI hos autorisationsserveren, og hold certifikatvalidering slået til på klienten. En udviklingsgenvej, der undertrykker HTTPS-kravet, giver et forløb, der opfører sig anderledes end den produktionskonfiguration, den skal modellere.

Token-endepunktet og anmodninger med bearer-token

Tokenanmodningen bærer legitimationsoplysninger eller en kode, der kan byttes til adgang. At sende den over et ubeskyttet ben blotlægger materiale, som ressourceserveren senere vil stole på, selv om netværket omkring er privat. En proxy, der kan læse anmodningen, kan også læse den legitimationsoplysning, den bærer.

For ressourceanmodninger med bearer-token behandler RFC 6750 TLS som obligatorisk at implementere og bruge for den specifikation. At kalde kontorets undernet betroet er ikke den generelle protokolundtagelse, som en bearer-udrulning med klartekst har brug for.

Brug de dokumenterede sikre endepunkt-URL'er for begge ben. Hvis et bibliotek nægter at kalde et HTTP-token-endepunkt, er den nægtelse specifikationen, der virker, ikke en konfigurationsfejl, der skal omgås. Skriv den URL i klientkonfigurationen i stedet for at udlede den ved kørsel.

Hvor TLS afsluttes, og hvad det efterlader

Hvis TLS slutter ved en autoriseret frontend, navngiv den frontend, og gennemgå stien fra den til applikationen. Frontenden bliver ansvarlig for videresendelse, tillid og fortrolighed på den resterende strækning, og tjenestens understøttede arkitektur bør beskrive den ordning.

En VPN et andet sted på stien afgør ikke de ansvarsområder. Den fortæller dig heller ikke, om den applikations-URL, browseren ser, svarer til det certifikat, frontenden præsenterer.

For en intern udrulning skal du registrere afslutningspunktet og den identitet, det præsenterer. En frontend, der afslutter TLS med et certifikat for et andet navn, skaber en browseradvarsel, som operatører ofte undertrykker i stedet for at rette.

Undtagelsen for native loopback er snæver

Undtagelsen for loopback-omdirigering handler om et callback på brugerens egen enhed, hvor klienten og browseren deler den enhed. Den ordning hører til et callback på én enhed og giver ikke ret til at betjene en normal autorisationsserver eller et API med tokens over HTTP til et kontorundernet.

Hold undtagelsen begrænset til klienttypen og det callback, den beskriver. At anvende den på en webapplikation, en delt intern tjeneste eller en omdirigerings-URI på en anden vært ændrer udrulningen, ikke undtagelsen.

Test det faktiske forløb ved hver grænse, og sammenlign det med klienttypen. En fungerende omdirigering siger intet om, hvorvidt hvert ben, der bar et token, brugte den krævede beskyttelse, og et grønt VPN-ikon siger intet om skemaet for den næste anmodning.