OAuth VPN:n sisällä: mitkä osuudet vaativat yhä TLS:n

Yksityinen reititys päättää, kuka saavuttaa palvelimen; OAuthin siirtosäännöt päättävät, miten kukin viesti kulkee. Selain, valtuutuspalvelin, tunnuksen päätepiste ja resurssipalvelin voivat kaikki olla saman VPN:n takana ja silti vaihtaa viestejä eri osuuksien kautta. Jokaisella osuudella on oma siirtovaatimuksensa, eikä VPN lievennä yhtäkään niistä. VPN:n raja ja protokollan raja ovat kaksi eri viivaa.

Päätös on helpompi, kun lakkaat kysymästä, onko verkko luotettu, ja alat kysyä, mikä vaihto ylittää minkä rajan.

Päätä osuuden mukaan, ei verkon

Kirjoita päätepisteet erikseen: valtuutuksen päätepiste, tunnuksen päätepiste, uudelleenohjauksen URI, resurssipalvelimen URL, TLS:n päätepiste ja VPN-yhdyskäytävä. Merkitse sitten, mikä osapuoli aloittaa kunkin pyynnön ja mihin vastaus menee.

Yhdyskäytävään päättyvä VPN salaa segmentin kyseiseen yhdyskäytävään asti. Pyyntö voi jatkua sen takana tavallisena HTTP:nä, eikä jäljellä oleva osuus ole muuttunut HTTPS:ksi siksi, että aikaisempi segmentti salattiin. Juuri tämä jatko on se osuus, josta protokolla välittää. Ensimmäisen hypyn salaaminen ei tee toisesta hypystä turvallista.

Siirto kantaa myös palvelun identiteetin tarkistuksen. Selain validoi sovelluksen URL:n varmenteen; VPN ei tee tätä validointia selaimen puolesta eikä tee validoimatonta päätepistettä hyväksyttäväksi. Varmenne nimeää päätepisteen, jota asiakas uskoo kutsuvansa. Yhdyskäytävään johtava tunneli ei nimeä tätä päätepistettä uudelleen eikä validoi sitä.

Valtuutusvastaus ja uudelleenohjauksen URI

OAuthin nykyinen paras suojaustapa kieltää valtuutusvastausten siirtämisen salaamattomien yhteyksien yli. Tämä kattaa uudelleenohjauksen, joka vie valtuutuskoodin tai tunnukset takaisin asiakkaalle, ei vain alkuperäistä pyyntöä.

Sama ohjeistus kieltää HTTP-uudelleenohjauksen URI:t lukuun ottamatta määritettyä natiivin asiakkaan loopback-tapausta. Sisäinen isäntänimi ei luo uutta poikkeusta, ja DNS-nimi, joka ratkeaa vain VPN:n sisällä, on edelleen HTTP URL, jos skeema niin sanoo. Tarkista skeema rekisteröidystä URI:sta, älä vain isäntänimeä.

Rekisteröi tarkka HTTPS-uudelleenohjauksen URI valtuutuspalvelimelle ja pidä varmenteen validointi päällä asiakkaassa. Kehityksen oikotie, joka vaimentaa HTTPS-vaatimuksen, tuottaa kulun, joka käyttäytyy eri tavoin kuin tuotantokokoonpano, jota sen pitäisi mallintaa.

Tunnuksen päätepiste ja bearer-tunnuspyynnöt

Tunnuspyyntö kantaa valtuustiedot tai koodin, joka voidaan vaihtaa käyttöoikeudeksi. Sen lähettäminen suojaamattomalla osuudella paljastaa materiaalia, johon resurssipalvelin myöhemmin luottaa, vaikka ympäröivä verkko olisi yksityinen. Välityspalvelin, joka voi lukea pyynnön, voi lukea myös sen kantaman valtuustiedon.

Bearer-tunnuksella tehtävissä resurssipyynnöissä RFC 6750 pitää TLS:ää pakollisena toteuttaa ja käyttää kyseisessä määrittelyssä. Toimiston aliverkon kutsuminen luotetuksi ei ole se yleinen protokollapoikkeus, jonka selkokielinen bearer-käyttöönotto tarvitsee.

Käytä dokumentoituja turvallisia päätepisteiden URL-osoitteita molemmilla osuuksilla. Jos kirjasto kieltäytyy kutsumasta HTTP-tunnuksen päätepistettä, tuo kieltäytyminen on määrittely, joka toimii, ei ohitettava kokoonpanovirhe. Kirjaa tämä URL asiakkaan kokoonpanoon sen sijaan, että johtaisit sen ajonaikaisesti.

Missä TLS päättyy ja mitä siitä jää

Jos TLS päättyy valtuutettuun etupäähän, nimeä tämä etupää ja käy läpi polku siitä sovellukseen. Etupäästä tulee vastuussa oleva edelleenlähetyksestä, luottamuksesta ja luottamuksellisuudesta jäljellä olevalla segmentillä, ja palvelun tuettu arkkitehtuuri kuvannee tämän järjestelyn.

VPN muualla polulla ei ratkaise näitä vastuita. Se ei myöskään kerro, vastaako selaimen näkemä sovelluksen URL etupään esittämää varmennetta.

Sisäisessä käyttöönotossa kirjaa päätepiste ja identiteetti, jonka se esittää. Etupää, joka päättää TLS:n toisen nimen varmenteella, luo selainvaroituksen, jonka operaattorit usein vaimentavat sen sijaan, että korjaisivat sen.

Natiivin loopbackin poikkeus on kapea

Loopback-uudelleenohjauksen poikkeus koskee käyttäjän omalla laitteella tapahtuvaa takaisinkutsua, jossa asiakas ja selain jakavat tuon laitteen. Tämä järjestely kuuluu yhden laitteen takaisinkutsuun, eikä se oikeuta tarjoamaan tavallista valtuutuspalvelinta tai tunnuksia kantavaa API:a HTTP:n yli toimiston aliverkolle.

Pidä poikkeus rajattuna asiakastyyppiin ja takaisinkutsuun, jota se kuvaa. Sen soveltaminen verkkosovellukseen, jaettuun sisäiseen palveluun tai toisen isännän uudelleenohjauksen URI:in muuttaa käyttöönottoa, ei poikkeusta.

Testaa todellinen kulku kullakin rajalla ja vertaa sitä asiakastyyppiin. Toimiva uudelleenohjaus ei kerro mitään siitä, käyttikö jokainen tunnuksen kantanut osuus vaadittua suojausta, eikä vihreä VPN-kuvake kerro mitään seuraavan pyynnön skeemasta.