OAuth wewnątrz VPN: które odcinki nadal wymagają TLS

Prywatny routing decyduje, kto dociera do serwera; reguły transportu OAuth decydują, jak podróżuje każdy komunikat. Przeglądarka, serwer autoryzacji, punkt końcowy tokenu i serwer zasobów mogą wszystkie stać za tym samym VPN, a mimo to wymieniać komunikaty różnymi odcinkami. Każdy odcinek ma własne wymaganie transportowe, a VPN nie łagodzi żadnego z nich. Granica VPN i granica protokołu to dwie różne linie.

Decyzja jest łatwiejsza, gdy przestaniesz pytać, czy sieć jest zaufana, i zaczniesz pytać, która wymiana przekracza którą granicę.

Decyduj według odcinka, nie według sieci

Zapisz punkty końcowe osobno: punkt końcowy autoryzacji, punkt końcowy tokenu, URI przekierowania, URL serwera zasobów, punkt zakończenia TLS i brama VPN. Następnie zaznacz, która strona rozpoczyna każde żądanie i dokąd trafia odpowiedź.

VPN kończący się na bramie szyfruje segment do tej bramy. Żądanie może dalej biec jako zwykły HTTP za nią, a ten pozostały odcinek nie stał się HTTPS dlatego, że wcześniejszy segment został zaszyfrowany. Właśnie ta kontynuacja jest odcinkiem, na którym zależy protokołowi. Szyfrowanie pierwszego skoku nie czyni drugiego skoku bezpiecznym.

Transport niesie też sprawdzenie tożsamości usługi. Przeglądarka weryfikuje certyfikat dla URL aplikacji; VPN nie wykonuje tej weryfikacji w imieniu przeglądarki i nie czyni niezweryfikowanego punktu końcowego akceptowalnym. Certyfikat nazywa punkt końcowy, który klient sądzi, że wywołuje. Tunel do bramy nie zmienia nazwy tego punktu i go nie weryfikuje.

Odpowiedź autoryzacji i URI przekierowania

Obecna najlepsza praktyka bezpieczeństwa OAuth zabrania przesyłania odpowiedzi autoryzacji przez nieszyfrowane połączenia. Obejmuje to przekierowanie, które przenosi kod autoryzacji lub tokeny z powrotem do klienta, nie tylko początkowe żądanie.

Te same wytyczne nie pozwalają na URI przekierowania HTTP, poza wskazanym przypadkiem loopback dla klientów natywnych. Wewnętrzna nazwa hosta nie tworzy nowego wyjątku, a nazwa DNS, która rozwiązuje się tylko wewnątrz VPN, nadal jest adresem URL HTTP, jeśli schemat tak mówi. Sprawdź schemat w zarejestrowanym URI, nie tylko nazwę hosta.

Zarejestruj dokładny URI przekierowania HTTPS u serwera autoryzacji i utrzymuj włączoną weryfikację certyfikatów w kliencie. Skrót rozwojowy, który tłumi wymóg HTTPS, daje przepływ zachowujący się inaczej niż konfiguracja produkcyjna, którą ma modelować.

Punkt końcowy tokenu i żądania z tokenem okaziciela

Żądanie tokenu niesie poświadczenia lub kod, który można wymienić na dostęp. Wysłanie go niechronionym odcinkiem eksponuje materiał, któremu serwer zasobów później zaufa, nawet jeśli otaczająca sieć jest prywatna. Proxy, które potrafi odczytać żądanie, potrafi też odczytać niesione przez nie poświadczenie.

W przypadku żądań zasobów z tokenem okaziciela RFC 6750 traktuje TLS jako obowiązkowy do zaimplementowania i używania w tej specyfikacji. Nazwanie podsieci biurowej zaufaną nie jest ogólnym wyjątkiem protokołu, którego potrzebuje wdrożenie okaziciela w czystym tekście.

Używaj udokumentowanych bezpiecznych adresów URL punktów końcowych dla obu odcinków. Jeśli biblioteka odmawia wywołania punktu końcowego tokenu przez HTTP, ta odmowa jest działającą specyfikacją, a nie błędem konfiguracji do obejścia. Zapisz ten URL w konfiguracji klienta, zamiast wyprowadzać go w czasie wykonania.

Gdzie kończy się TLS i co to zostawia

Jeśli TLS kończy się na autoryzowanym froncie, nazwij ten front i przejrzyj ścieżkę od niego do aplikacji. Front staje się odpowiedzialny za przekazywanie, zaufanie i poufność na pozostałym segmencie, a obsługiwana architektura usługi powinna opisywać ten układ.

VPN w innym miejscu ścieżki nie rozstrzyga tych odpowiedzialności. Nie mówi też, czy URL aplikacji widziany przez przeglądarkę odpowiada certyfikatowi przedstawianemu przez front.

Przy wdrożeniu wewnętrznym zapisz punkt zakończenia i tożsamość, którą przedstawia. Front kończący TLS certyfikatem dla innej nazwy tworzy ostrzeżenie przeglądarki, które operatorzy często tłumią zamiast naprawić.

Wyjątek dla natywnego loopback jest wąski

Wyjątek przekierowania loopback dotyczy wywołania zwrotnego na własnym urządzeniu użytkownika, gdzie klient i przeglądarka dzielą to urządzenie. Ten układ należy do wywołania zwrotnego na jednym urządzeniu i nie daje prawa do obsługiwania zwykłego serwera autoryzacji lub API niosącego tokeny przez HTTP dla podsieci biurowej.

Trzymaj wyjątek ograniczony do typu klienta i wywołania zwrotnego, które opisuje. Zastosowanie go do aplikacji webowej, współdzielonej usługi wewnętrznej lub URI przekierowania na innym hoście zmienia wdrożenie, nie wyjątek.

Przetestuj rzeczywisty przepływ na każdej granicy i porównaj go z typem klienta. Działające przekierowanie nic nie mówi o tym, czy każdy odcinek niosący token użył wymaganej ochrony, a zielona ikona VPN nic nie mówi o schemacie następnego żądania.