OAuth egy VPN-en belül: mely szakaszok igényelnek még TLS-t

A privát útválasztás eldönti, ki éri el a kiszolgálót; az OAuth átviteli szabályai eldöntik, hogyan utazik minden üzenet. Egy böngésző, egy engedélyezési kiszolgáló, egy token-végpont és egy erőforrás-kiszolgáló mind ugyanazon VPN mögött lehet, és mégis különböző szakaszokon keresztül cserélhet üzeneteket. Minden szakasznak megvan a saját átviteli követelménye, és a VPN egyiket sem enyhíti. A VPN határa és a protokoll határa két különböző vonal.

A döntés könnyebb, ha abbahagyja annak kérdezését, hogy megbízható-e a hálózat, és elkezdi kérdezni, hogy melyik csere melyik határt lépi át.

Szakasz szerint döntsön, ne hálózat szerint

Írja fel a végpontokat külön: engedélyezési végpont, token-végpont, átirányítási URI, az erőforrás-kiszolgáló URL-je, TLS-végpont és VPN-átjáró. Ezután jelölje meg, melyik fél indítja az egyes kéréseket, és hová megy a válasz.

Az átjárónál végződő VPN titkosítja az átjáróig tartó szakaszt. A kérés mögötte továbbhaladhat sima HTTP-ként, és az a fennmaradó szakasz nem vált HTTPS-sé attól, hogy egy korábbi szakasz titkosítva volt. Pontosan ez a folytatás az a szakasz, amely a protokollt érdekli. Az első ugrás titkosítása nem teszi biztonságossá a második ugrást.

Az átvitel a szolgáltatás identitásának ellenőrzését is hordozza. A böngésző érvényesíti az alkalmazás URL-jéhez tartozó tanúsítványt; a VPN nem végzi el ezt az ellenőrzést a böngésző helyett, és nem tesz elfogadhatóvá egy nem ellenőrzött végpontot. A tanúsítvány megnevezi azt a végpontot, amelyet az ügyfél hívni vél. Az átjáróhoz vezető alagút nem nevezi át ezt a végpontot, és nem ellenőrzi azt.

Az engedélyezési válasz és az átirányítási URI

Az OAuth jelenlegi legjobb biztonsági gyakorlata tiltja az engedélyezési válaszok továbbítását titkosítatlan kapcsolatokon. Ez kiterjed arra az átirányításra, amely az engedélyezési kódot vagy a tokeneket visszaviszi az ügyfélhez, nem csak a kezdeti kérésre.

Ugyanez az útmutatás tiltja a HTTP átirányítási URI-kat, kivéve a megadott natív ügyfél loopback-esetét. Egy belső gazdagépnév nem teremt új kivételt, és a csak a VPN-en belül feloldható DNS-név továbbra is HTTP URL, ha a séma ezt mondja. A regisztrált URI-ban ellenőrizze a sémát, ne csak a gazdagépnevet.

Regisztrálja a pontos HTTPS átirányítási URI-t az engedélyezési kiszolgálónál, és tartsa bekapcsolva a tanúsítvány-ellenőrzést az ügyfélen. Az a fejlesztői rövidítés, amely elnyomja a HTTPS-követelményt, olyan folyamatot hoz létre, amely másként viselkedik, mint az az éles konfiguráció, amelyet modelleznie kellene.

A token-végpont és a bearer tokenes kérések

A token-kérés hitelesítő adatokat vagy hozzáférésre beváltható kódot hordoz. Titkosítatlan szakaszon elküldve olyan anyagot tesz ki, amelyben az erőforrás-kiszolgáló később megbízik, még akkor is, ha a környező hálózat privát. Az a proxy, amely olvasni tudja a kérést, a benne hordozott hitelesítő adatot is el tudja olvasni.

A bearer tokenes erőforrás-kéréseknél az RFC 6750 a TLS-t abban a specifikációban kötelezően megvalósítandónak és használandónak tekinti. Az irodai alhálózat megbízhatónak nevezése nem az az általános protokollkivétel, amelyre egy nyílt szövegű bearer-telepítésnek szüksége van.

Mindkét szakaszon használja a dokumentált biztonságos végpont-URL-eket. Ha egy könyvtár megtagadja egy HTTP token-végpont hívását, ez a megtagadás a specifikáció működése, nem megkerülendő konfigurációs hiba. Jegyezze fel ezt az URL-t az ügyfél konfigurációjába, ahelyett hogy futásidőben vezetné le.

Hol végződik a TLS, és mit hagy maga után

Ha a TLS egy engedélyezett frontenden végződik, nevezze meg azt a frontendet, és vizsgálja át az onnan az alkalmazásig vezető útvonalat. A frontend felelőssé válik a továbbításért, a bizalomért és a bizalmasságért a fennmaradó szakaszon, és a szolgáltatás támogatott architektúrájának le kellene írnia ezt az elrendezést.

Az útvonal más pontján lévő VPN nem rendezi ezeket a felelősségeket. Azt sem mondja meg, hogy a böngésző által látott alkalmazás-URL megfelel-e a frontend által bemutatott tanúsítványnak.

Belső telepítésnél jegyezze fel a végződési pontot és az általa bemutatott identitást. Az a frontend, amely más névre szóló tanúsítvánnyal végzi a TLS-t, olyan böngészőfigyelmeztetést hoz létre, amelyet az üzemeltetők gyakran elnyomnak a javítás helyett.

A natív loopback kivétele szűk

A loopback átirányítási kivétel a felhasználó saját eszközén történő visszahívásra vonatkozik, ahol az ügyfél és a böngésző megosztja azt az eszközt. Ez az elrendezés egy eszközön történő visszahíváshoz tartozik, és nem jogosít fel arra, hogy egy normál engedélyezési kiszolgálót vagy tokent hordozó API-t HTTP-n szolgáljunk ki egy irodai alhálózatnak.

Tartsa a kivételt az ügyféltípusra és az általa leírt visszahívásra korlátozva. Ha webes alkalmazásra, megosztott belső szolgáltatásra vagy egy másik gazdagépen lévő átirányítási URI-ra alkalmazza, az a telepítést változtatja meg, nem a kivételt.

Tesztelje a tényleges folyamatot minden határon, és hasonlítsa össze az ügyféltípussal. Egy működő átirányítás semmit sem mond arról, hogy minden tokent hordozó szakasz használta-e az előírt védelmet, és egy zöld VPN-ikon semmit sem mond a következő kérés sémájáról.