OAuth внутри VPN: какие участки по-прежнему требуют TLS

Частная маршрутизация решает, кто достигает сервера; правила передачи OAuth решают, как путешествует каждое сообщение. Браузер, сервер авторизации, конечная точка токена и сервер ресурсов могут все находиться за одним VPN и всё же обмениваться сообщениями по разным участкам. У каждого участка своё требование к передаче, и VPN не ослабляет ни одно из них. Граница VPN и граница протокола — две разные линии.

Решение проще, если перестать спрашивать, доверенная ли сеть, и начать спрашивать, какой обмен пересекает какую границу.

Решайте по участку, а не по сети

Выпишите конечные точки отдельно: конечная точка авторизации, конечная точка токена, URI перенаправления, URL сервера ресурсов, точка завершения TLS и шлюз VPN. Затем отметьте, какая сторона начинает каждый запрос и куда идёт ответ.

VPN, завершающийся на шлюзе, шифрует сегмент до этого шлюза. Запрос может продолжаться как обычный HTTP за ним, и этот оставшийся участок не стал HTTPS из-за того, что более ранний сегмент был зашифрован. Именно это продолжение и есть участок, важный для протокола. Шифрование первого перехода не делает второй переход безопасным.

Передача несёт и проверку идентичности сервиса. Браузер проверяет сертификат для URL приложения; VPN не выполняет эту проверку от имени браузера и не делает непроверенную конечную точку приемлемой. Сертификат называет ту конечную точку, которую клиент считает вызываемой. Туннель к шлюзу не переименовывает эту конечную точку и не проверяет её.

Ответ авторизации и URI перенаправления

Текущая лучшая практика безопасности OAuth запрещает передавать ответы авторизации по незашифрованным соединениям. Это охватывает перенаправление, которое несёт код авторизации или токены обратно клиенту, а не только первоначальный запрос.

То же руководство не разрешает URI перенаправления HTTP, кроме указанного случая loopback для нативных клиентов. Внутреннее имя хоста не создаёт нового исключения, а имя DNS, которое разрешается только внутри VPN, остаётся URL-адресом HTTP, если схема это говорит. Проверяйте схему в зарегистрированном URI, а не только имя хоста.

Зарегистрируйте точный URI перенаправления HTTPS у сервера авторизации и держите проверку сертификатов включённой на клиенте. Разработческое сокращение, подавляющее требование HTTPS, даёт поток, который ведёт себя иначе, чем производственная конфигурация, которую он должен моделировать.

Конечная точка токена и запросы с носительным токеном

Запрос токена несёт учётные данные или код, который можно обменять на доступ. Отправка его по незащищённому участку раскрывает материал, которому сервер ресурсов позже доверится, даже если окружающая сеть частная. Прокси, который может прочитать запрос, может прочитать и учётные данные, которые он несёт.

Для запросов к ресурсам с носительным токеном RFC 6750 считает TLS обязательным для реализации и использования в этой спецификации. Называть офисную подсеть доверенной — не то общее исключение протокола, которое нужно развёртыванию с носительным токеном в открытом тексте.

Используйте документированные безопасные URL конечных точек для обоих участков. Если библиотека отказывается вызывать конечную точку токена по HTTP, этот отказ — работающая спецификация, а не ошибка конфигурации, которую следует обходить. Записывайте этот URL в конфигурацию клиента, а не выводите его во время выполнения.

Где завершается TLS и что это оставляет

Если TLS завершается на авторизованном фронтенде, назовите этот фронтенд и просмотрите путь от него к приложению. Фронтенд становится ответственным за пересылку, доверие и конфиденциальность на оставшемся сегменте, и поддерживаемая архитектура сервиса должна описывать это устройство.

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

Для внутреннего развёртывания зафиксируйте точку завершения и идентичность, которую она представляет. Фронтенд, завершающий TLS сертификатом для другого имени, создаёт предупреждение браузера, которое операторы часто подавляют вместо исправления.

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

Исключение перенаправления loopback касается обратного вызова на собственном устройстве пользователя, где клиент и браузер делят это устройство. Это устройство относится к обратному вызову на одном устройстве и не даёт права обслуживать обычный сервер авторизации или API с токенами по HTTP для офисной подсети.

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

Проверьте реальный поток на каждой границе и сравните его с типом клиента. Работающее перенаправление ничего не говорит о том, использовал ли каждый участок, несший токен, требуемую защиту, а зелёный значок VPN ничего не говорит о схеме следующего запроса.