OAuth във VPN: кои отсечки все още изискват TLS

Частното маршрутизиране решава кой достига до сървъра; правилата за пренос на 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, създава поток, който се държи различно от продукционната конфигурация, която трябва да моделира.

Крайната точка за токени и заявките с bearer токен

Заявката за токен носи удостоверения или код, който може да се обмени за достъп. Изпращането ѝ по незащитена отсечка излага материал, на който сървърът за ресурси по-късно ще се довери, дори околната мрежа да е частна. Прокси, което може да прочете заявката, може да прочете и удостоверението, което тя носи.

За заявки към ресурси с bearer токен RFC 6750 приема TLS за задължителен за реализация и употреба по тази спецификация. Назоваването на офис подмрежата за доверена не е общото протоколно изключение, което изисква разгръщане с bearer токени по открит текст.

Използвайте документираните сигурни URL на крайни точки за двете отсечки. Ако библиотека откаже да вика HTTP крайна точка за токени, този отказ е спецификацията, която работи, а не конфигурационна грешка за заобикаляне. Записвайте този URL в конфигурацията на клиента, вместо да го извеждате по време на изпълнение.

Къде завършва TLS и какво остава след това

Ако TLS завършва на оторизиран фронтенд, назовете този фронтенд и прегледайте пътя от него до приложението. Фронтендът става отговорен за препращането, доверието и поверителността на останалия сегмент и поддържаната архитектура на услугата трябва да описва тази подредба.

VPN на друго място по пътя не решава тези отговорности. То също не ви казва дали URL на приложението, който браузърът вижда, съвпада със сертификата, който фронтендът представя.

За вътрешно разгръщане запишете точката на прекратяване и идентичността, която тя представя. Фронтенд, който завършва TLS със сертификат за друго име, създава предупреждение в браузъра, което операторите често потискат, вместо да го поправят.

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

Изключението за loopback пренасочване се отнася до обратно извикване на собственото устройство на потребителя, където клиентът и браузърът споделят това устройство. Тази подредба принадлежи на обратно извикване на едно устройство и не дава право да се обслужва обикновен сървър за оторизация или API с токени по HTTP към офис подмрежа.

Дръжте изключението ограничено до типа клиент и обратното извикване, което описва. Прилагането му към уеб приложение, споделена вътрешна услуга или URI за пренасочване на друг хост променя разгръщането, а не изключението.

Тествайте действителния поток на всяка граница и го сравнете с типа клиент. Работещото пренасочване не казва нищо дали всяка отсечка, носила токен, е използвала изискваната защита, а зелена икона на VPN не казва нищо за схемата на следващата заявка.