Приватното насочување одлучува кој стигнува до серверот; транспортните правила на OAuth одлучуваат како патува секоја порака. Прелистувач, сервер за авторизација, крајна точка за токени и сервер за ресурси можат сите да стојат зад ист VPN и сепак да разменуваат пораки по различни сегменти. Секој сегмент има свој транспортен услов, и VPN не го олеснува ниту еден од нив. Границата на VPN и границата на протоколот се две различни линии.

Одлуката е полесна ако престанете да прашувате дали мрежата е доверлива и почнете да прашувате која размена ја преминува која граница.

Одлучете по сегмент, а не по мрежа

Запишете ги крајните точки одделно: крајна точка за авторизација, крајна точка за токени, URI за пренасочување, URL на серверот за ресурси, точка на завршување на TLS и VPN порта. Потоа означете која страна го започнува секое барање и каде оди одговорот.

VPN што завршува на порта го шифрира сегментот до таа порта. Барањето може да продолжи како обичен HTTP зад неа, и тој преостанат сегмент не станал HTTPS затоа што претходниот сегмент бил шифриран. Токму тоа продолжување е сегментот што го интересира протоколот. Шифрирањето на првиот скок не го прави вториот скок безбеден.

Транспортот носи и проверка на идентитетот на услугата. Прелистувачот го проверува сертификатот за URL-то на апликацијата; VPN не ја врши таа проверка во име на прелистувачот и не прави непроверена крајна точка прифатлива. Сертификатот ја именува крајната точка за која клиентот смета дека ја повикува. Тунелот до порта не ја преименува таа крајна точка и не ја проверува.

Одговорот за авторизација и URI за пренасочување

Тековната најдобра безбедносна практика на OAuth забранува пренесување на одговори за авторизација преку нешифрирани врски. Тоа го опфаќа пренасочувањето што го носи кодот за авторизација или токените назад до клиентот, а не само почетното барање.

Истите упатства не дозволуваат HTTP URI за пренасочување, освен наведениот случај на loopback за нативен клиент. Внатрешно име на домаќин не создава нов исклучок, а DNS име што се решава само внатре во VPN останува HTTP URL ако шемата така вели. Проверете ја шемата во регистрираниот URI, не само името на домаќинот.

Регистрирајте го точниот HTTPS URI за пренасочување кај серверот за авторизација и држете ја проверката на сертификатот вклучена на клиентот. Развојниот кратен пат што го потиснува барањето за HTTPS создава тек што се однесува поинаку од производната конфигурација што треба да ја моделира.

Крајната точка за токени и барањата со носечки токен

Барањето за токен носи акредитиви или код што може да се замени за пристап. Неговото испраќање по незаштитен сегмент изложува материјал на кој серверот за ресурси подоцна ќе се потпре, дури и ако околната мрежа е приватна. Прокси што може да го прочита барањето може да ги прочита и акредитивите што ги носи.

За барања за ресурси со носечки токен RFC 6750 го смета TLS за задолжителен за спроведување и употреба во таа спецификација. Нарекувањето на канцелариската подмрежа доверлива не е општиот протоколен исклучок што му е потребен на распоредување со носечки токени по отворен текст.

Користете ги документираните безбедни URL-а на крајните точки за двата сегмента. Ако библиотеката одбива да повика HTTP крајна точка за токени, тоа одбивање е спецификацијата што работи, а не конфигурациска грешка што треба да се заобиколи. Запишете го тој URL во конфигурацијата на клиентот наместо да го изведувате при извршување.

Каде завршува TLS и што остава тоа

Ако TLS завршува на овластен фронтенд, именувајте го тој фронтенд и прегледајте ја патеката од него до апликацијата. Фронтендот станува одговорен за проследувањето, довербата и доверливоста на преостанатиот сегмент, и поддржаната архитектура на услугата треба да го опише тој распоред.

VPN на друго место во патеката не ги решава тие одговорности. Тој исто така не ви кажува дали URL-то на апликацијата што го гледа прелистувачот одговара на сертификатот што го презентира фронтендот.

За внатрешно распоредување, запишете ја точката на завршување и идентитетот што го презентира. Фронтенд што завршува TLS со сертификат за друго име создава предупредување во прелистувачот што операторите често го потиснуваат наместо да го поправат.

Исклучокот за нативен loopback е тесен

Исклучокот за loopback пренасочување се однесува на повратен повик на сопствениот уред на корисникот, каде клиентот и прелистувачот го делат тој уред. Тој распоред припаѓа на повратен повик на еден уред и не дозволува служење на обичен сервер за авторизација или API што носи токени по HTTP до канцелариска подмрежа.

Држете го исклучокот ограничен на типот на клиент и повратниот повик што го опишува. Неговата примена на веб-апликација, заедничка внатрешна услуга или URI за пренасочување на друг домаќин го менува распоредувањето, а не исклучокот.

Тестирајте го вистинскиот тек на секоја граница и споредете го со типот на клиент. Пренасочувањето што работи не кажува ништо за тоа дали секој сегмент што носел токен ја користел потребната заштита, а зелената икона на VPN не кажува ништо за шемата на следното барање.

Поврзани статии