OAuth inne i ein VPN: kva bein som framleis krev TLS

Privat ruting avgjer kven som når tenaren; transportreglane til OAuth avgjer korleis kvar melding reiser. Ein nettlesar, ein autorisasjonsserver, eit token-endepunkt og ein ressursmaskin kan alle liggje bak same VPN og likevel utveksle meldingar over ulike bein. Kvart bein har sitt eige transportkrav, og VPN-en lempar ikkje på noko av dei. VPN-grensa og protokollgrensa er to ulike linjer.

Avgjerda er lettare om du sluttar å spørje om nettverket er til å stole på og byrjar å spørje kva utveksling som kryssar kva grense.

Avgjer per bein, ikkje per nettverk

Skriv ned endepunkta kvar for seg: autorisasjonsendepunkt, token-endepunkt, omdirigerings-URI, URL-en til ressursmaskinen, TLS-avslutningspunkt og VPN-gateway. Merk deretter kva part som startar kvar førespurnad og kvar svaret går.

Ein VPN som blir avslutta ved ein gateway, krypterer strekninga til den gatewayen. Førespurnaden kan halde fram som vanleg HTTP bak han, og det gjenverande beinet har ikkje blitt HTTPS fordi ei tidlegare strekning vart kryptert. Nettopp den framhaldet er beinet protokollen bryr seg om. Å kryptere første hopp gjer ikkje andre hopp sikkert.

Transporten ber også ein kontroll av identiteten til tenesta. Nettlesaren validerer sertifikatet for URL-en til applikasjonen; ein VPN utfører ikkje den valideringa på vegner av nettlesaren og gjer ikkje eit uvalidert endepunkt akseptabelt. Sertifikatet namngjev endepunktet klienten trur han kallar. Ein tunnel til ein gateway gjev ikkje det endepunktet nytt namn og validerer det ikkje.

Autorisasjonssvaret og omdirigerings-URI-en

Den gjeldande beste tryggleikspraksisen til OAuth forbyr å sende autorisasjonssvar over ukrypterte samband. Det dekkjer omdirigeringa som ber autorisasjonskoden eller tokena tilbake til klienten, ikkje berre den første førespurnaden.

Den same rettleiinga tillèt ikkje HTTP-omdirigerings-URI-ar, bortsett frå det angjevne loopback-tilfellet for opphavlege klientar. Eit internt vertsnamn skaper ikkje eit nytt unntak, og eit DNS-namn som berre blir løyst inne i VPN-en er framleis ein HTTP-URL om skjemaet seier det. Kontroller skjemaet i den registrerte URI-en, ikkje berre vertsnamnet.

Registrer den nøyaktige HTTPS-omdirigerings-URI-en hos autorisasjonsserveren og hald sertifikatvalidering slått på i klienten. Ein utviklingssnarveg som undertrykkjer HTTPS-kravet gjev eit forløp som oppfører seg annleis enn produksjonskonfigurasjonen han skal modellere.

Token-endepunktet og førespurnader med berar-token

Tokenførespurnaden ber legitimasjon eller ein kode som kan bytast mot tilgang. Å sende han over eit ubeskytta bein blottlegg materiale som ressursmaskinen seinare vil stole på, sjølv om nettverket rundt er privat. Ein proxy som kan lese førespurnaden, kan også lese legitimasjonen han ber.

For ressursførespurnader med berar-token handsamar RFC 6750 TLS som obligatorisk å implementere og bruke for den spesifikasjonen. Å kalle kontorets subnett til å stole på er ikkje det generelle protokollunntaket ein berar-utrulling i klartekst treng.

Bruk dei dokumenterte trygge endepunkt-URL-ane for båe bein. Om eit bibliotek nektar å kalle eit HTTP-token-endepunkt, er den nektinga spesifikasjonen som verkar, ikkje ein konfigurasjonsfeil som skal omgåast. Skriv den URL-en i klientkonfigurasjonen i staden for å utleie han ved køyring.

Kvar TLS blir avslutta, og kva det lèt etter seg

Om TLS sluttar ved ein autorisert frontend, namngjev den frontenden og gå gjennom banen frå han til applikasjonen. Frontenden blir ansvarleg for videresending, tillit og konfidensialitet på den gjenverande strekninga, og den støtta arkitekturen til tenesta bør skildre den ordninga.

Ein VPN ein annan stad på banen avgjer ikkje dei ansvara. Han fortel deg heller ikkje om applikasjons-URL-en nettlesaren ser, svarar til sertifikatet frontenden presenterer.

For ein intern utrulling, registrer avslutningspunktet og identiteten det presenterer. Ein frontend som avsluttar TLS med eit sertifikat for eit anna namn, skaper ei nettlesaråtvaring som operatørar ofte undertrykkjer i staden for å rette.

Unntaket for opphavleg loopback er smalt

Loopback-omdirigeringsunntaket gjeld eit tilbakekall på brukaren sin eigen eining, der klienten og nettlesaren deler den eininga. Den ordninga høyrer til eit tilbakekall på éi eining og gjev ikkje løyve til å tena ein vanleg autorisasjonsserver eller eit API med token over HTTP til eit kontorsubnett.

Hald unntaket avgrensa til klienttypen og tilbakekallet det skildrar. Å bruke det på ein webapplikasjon, ei delt intern teneste eller ein omdirigerings-URI på ein annan vert endrar utrullinga, ikkje unntaket.

Test det faktiske forløpet ved kvar grense og samanlikn det med klienttypen. Ei fungerande omdirigering seier ingenting om kvidt kvart bein som bar eit token, brukte den påkravde vernet, og eit grønt VPN-ikon seier ingenting om skjemaet for den neste førespurnaden.