OAuth усередині VPN: які ланки досі потребують TLS

Приватна маршрутизація визначає, хто досягає сервера; правила транспорту OAuth визначають, як подорожує кожне повідомлення. Браузер, сервер авторизації, кінцева точка токена й сервер ресурсів можуть усі бути за одним VPN і все одно обмінюватися повідомленнями різними ланками. Кожна ланка має власну вимогу до транспорту, і VPN не послаблює жодної з них. Межа VPN і межа протоколу — це різні лінії.

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

Вирішуйте за ланкою, а не за мережею

Випишіть кінцеві точки окремо: кінцева точка авторизації, кінцева точка токена, URI перенаправлення, URL сервера ресурсів, точка завершення TLS і VPN-шлюз. Потім позначте, яка сторона ініціює кожен запит і куди прямує відповідь.

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

Транспорт також несе перевірку ідентичності сервісу. Браузер перевіряє сертифікат для URL застосунку; VPN не виконує цієї перевірки від імені браузера і не робить неперевірену кінцеву точку прийнятною. Сертифікат називає кінцеву точку, до якої клієнт вважає, що звертається. Тунель до шлюзу не перейменовує цю кінцеву точку і не перевіряє її.

Відповідь авторизації та URI перенаправлення

Чинна найкраща практика безпеки OAuth забороняє передавати відповіді авторизації через незашифровані з'єднання. Це охоплює перенаправлення, яке несе код авторизації або токени назад до клієнта, а не лише початковий запит.

Ті самі настанови забороняють HTTP-URI перенаправлення, за винятком указаного випадку зворотного циклу для нативного клієнта. Внутрішнє ім'я хоста не створює нового винятку, а DNS-ім'я, що розв'язується лише всередині VPN, усе одно є HTTP-URL, якщо схема це вказує. Перевіряйте схему в зареєстрованому URI, а не лише ім'я хоста.

Зареєструйте точний HTTPS-URI перенаправлення на сервері авторизації та тримайте перевірку сертифікатів увімкненою на клієнті. Скорочення для розробки, що пригнічує вимогу HTTPS, створює потік, який поводиться інакше, ніж виробнича конфігурація, яку він має моделювати.

Кінцева точка токена та запити з bearer-токеном

Запит токена несе облікові дані або код, які можна обміняти на доступ. Надсилання його незахищеною ланкою відкриває матеріал, якому сервер ресурсів згодом довірятиме, навіть якщо довколишня мережа приватна. Проксі, що може прочитати запит, може прочитати й облікові дані, які він несе.

Для запитів до ресурсів із bearer-токеном RFC 6750 вважає TLS обов'язковим для реалізації та використання в цій специфікації. Оголошення офісної підмережі довіреною не є тим загальним винятком протоколу, якого потребує розгортання bearer у відкритому тексті.

Використовуйте задокументовані безпечні URL кінцевих точок для обох ланок. Якщо бібліотека відмовляється викликати HTTP-кінцеву точку токена, ця відмова є роботою специфікації, а не помилкою конфігурації, яку слід обходити. Запишіть цей URL у конфігурації клієнта, а не обчислюйте під час виконання.

Де завершується TLS і що це залишає

Якщо TLS завершується на авторизованому фронтенді, назвіть цей фронтенд і перегляньте шлях від нього до застосунку. Фронтенд стає відповідальним за пересилання, довіру й конфіденційність на залишковому відрізку, і підтримувана архітектура сервісу має описувати цю схему.

VPN деінде на шляху не вирішує ці обов'язки. Він також не каже, чи URL застосунку, який бачить браузер, збігається із сертифікатом, який подає фронтенд.

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

Виняток для нативного зворотного циклу вузький

Виняток для перенаправлення через зворотний цикл стосується зворотного виклику на власному пристрої користувача, де клієнт і браузер поділяють цей пристрій. Така схема належить зворотному виклику на одному пристрої і не дає права обслуговувати звичайний сервер авторизації або API з токеном через HTTP для офісної підмережі.

Тримайте виняток у межах типу клієнта та зворотного виклику, який він описує. Застосування його до вебзастосунку, спільного внутрішнього сервісу або URI перенаправлення на іншому хості змінює розгортання, а не виняток.

Перевіряйте фактичний потік на кожній межі та порівнюйте його з типом клієнта. Робоче перенаправлення нічого не каже про те, чи кожна ланка, що несла токен, використовувала потрібний захист, а зелена іконка VPN нічого не каже про схему наступного запиту.