OAuth inne i en VPN: hvilke ben krever fortsatt TLS

Privat ruting avgjør hvem som når serveren; OAuths transportregler avgjør hvordan hver melding reiser. En nettleser, en autorisasjonsserver, et token-endepunkt og en ressursmaskin kan alle ligge bak samme VPN og likevel utveksle meldinger over forskjellige ben. Hvert ben har sitt eget transportkrav, og VPN-en lemper ikke på noen av dem. VPN-grensen og protokollgrensen er to forskjellige linjer.

Beslutningen er lettere hvis du slutter å spørre om nettverket er til å stole på og begynner å spørre hvilken utveksling som krysser hvilken grense.

Avgjør per ben, ikke per nettverk

Skriv ned endepunktene hver for seg: autorisasjonsendepunkt, token-endepunkt, omdirigerings-URI, URL-en til ressursmaskinen, TLS-avslutningspunkt og VPN-gateway. Merk deretter hvilken part som starter hver forespørsel og hvor svaret går.

En VPN som avsluttes ved en gateway, krypterer strekningen til den gatewayen. Forespørselen kan fortsette som vanlig HTTP bak den, og det gjenværende benet har ikke blitt HTTPS fordi en tidligere strekning ble kryptert. Nettopp den fortsettelsen er benet protokollen bryr seg om. Å kryptere første hopp gjør ikke andre hopp sikkert.

Transporten bærer også en kontroll av tjenestens identitet. Nettleseren validerer sertifikatet for applikasjonens URL; en VPN utfører ikke den valideringen på nettleserens vegne og gjør ikke et uvalidert endepunkt akseptabelt. Sertifikatet navngir endepunktet klienten tror den kaller. En tunnel til en gateway gir ikke det endepunktet nytt navn og validerer det ikke.

Autorisasjonssvaret og omdirigerings-URI-en

OAuths gjeldende beste sikkerhetspraksis forbyr å sende autorisasjonssvar over ukrypterte forbindelser. Det dekker omdirigeringen som bærer autorisasjonskoden eller tokenene tilbake til klienten, ikke bare den første forespørselen.

Den samme veiledningen tillater ikke HTTP-omdirigerings-URI-er, bortsett fra det angitte loopback-tilfellet for opprinnelige klienter. Et internt vertsnavn skaper ikke et nytt unntak, og et DNS-navn som bare løses inne i VPN-en er fortsatt en HTTP-URL hvis skjemaet sier det. Kontroller skjemaet i den registrerte URI-en, ikke bare vertsnavnet.

Registrer den nøyaktige HTTPS-omdirigerings-URI-en hos autorisasjonsserveren og hold sertifikatvalidering slått på i klienten. En utviklingssnarvei som undertrykker HTTPS-kravet gir et forløp som oppfører seg annerledes enn produksjonskonfigurasjonen den skal modellere.

Token-endepunktet og forespørsler med bærer-token

Tokenforespørselen bærer legitimasjon eller en kode som kan byttes mot tilgang. Å sende den over et ubeskyttet ben blottlegger materiale som ressursmaskinen senere vil stole på, selv om nettverket rundt er privat. En proxy som kan lese forespørselen, kan også lese legitimasjonen den bærer.

For ressursforespørsler med bærer-token behandler RFC 6750 TLS som obligatorisk å implementere og bruke for den spesifikasjonen. Å kalle kontorets subnett til å stole på er ikke det generelle protokollunntaket en bærer-utrulling i klartekst trenger.

Bruk de dokumenterte sikre endepunkt-URL-ene for begge ben. Hvis et bibliotek nekter å kalle et HTTP-token-endepunkt, er den nektelsen spesifikasjonen som virker, ikke en konfigurasjonsfeil som skal omgås. Skriv den URL-en i klientkonfigurasjonen i stedet for å utlede den ved kjøring.

Hvor TLS avsluttes, og hva det etterlater

Hvis TLS slutter ved en autorisert frontend, navngi den frontenden og gjennomgå banen fra den til applikasjonen. Frontenden blir ansvarlig for videresending, tillit og konfidensialitet på den gjenværende strekningen, og tjenestens støttede arkitektur bør beskrive den ordningen.

En VPN et annet sted på banen avgjør ikke de ansvarene. Den forteller deg heller ikke om applikasjons-URL-en nettleseren ser, samsvarer med sertifikatet frontenden presenterer.

For en intern utrulling, registrer avslutningspunktet og identiteten det presenterer. En frontend som avslutter TLS med et sertifikat for et annet navn, skaper en nettleseradvarsel som operatører ofte undertrykker i stedet for å rette.

Unntaket for opprinnelig loopback er smalt

Loopback-omdirigeringsunntaket gjelder et tilbakekall på brukerens egen enhet, der klienten og nettleseren deler den enheten. Den ordningen hører til et tilbakekall på én enhet og gir ikke lisens til å betjene en vanlig autorisasjonsserver eller et API med token over HTTP til et kontorsubnett.

Hold unntaket begrenset til klienttypen og tilbakekallet det beskriver. Å bruke det på en webapplikasjon, en delt intern tjeneste eller en omdirigerings-URI på en annen vert endrer utrullingen, ikke unntaket.

Test det faktiske forløpet ved hver grense og sammenlign det med klienttypen. En fungerende omdirigering sier ingenting om hvorvidt hvert ben som bar et token, brukte den påkrevde beskyttelsen, og et grønt VPN-ikon sier ingenting om skjemaet for den neste forespørselen.