Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Фундаментально! В следующий раз, когда мне будут в очередной раз говорить, какая классная и простая технология WS - я буду знать куда отправлять за весёлым чтением.
Не могли бы вы прояснить про SSE: если требуется установка соединения 1 раз, при условии что токен живёт долго, разве недостаточно передать токен при установке соединения через обычные куки?
Для аутентификации запроса — достаточно, это как раз один из доступных способов.
Однако остается вопрос контроля валидности соединения. Поскольку в данном случае природа передаваемых сообщений асинхронна и само HTTP-соединение остается открытым в течение некоторого времени, у нас все так же имеется риск передать некую важную информацию в сообщениях, даже если токен по любой причине будет инвалидирован. Инвалидация токена по истечении максимального времени жизни — это часто не единственная причина, есть, например, тот же логаут (выход по инициативе пользователя), отзыв токена в связи с различными событиями.
Естественно, степень критичности данного риска для каждого своя, допускаю, что в ряде приложений последствия могут быть не такими серьезными.
Спасибо за статью! Я бы ещё добавил момент с аутентификацией в механизм ping-pong помимо аутентификации при отправке сообщений на сервер
В браузере этот механизм фактически не работает.
Интересно, что даже лабораторная у PortSwigger по CSWSH сделана в тех же тепличных условиях — с сессионной cookie, у которой выставлен
SameSite=None. Причем явно об этом не пишут.
В защиту PortSwigger скажу, что эту лабораторную они выпустили в свет в 2019 году, когда SameSite еще не был по умолчанию Lax. Помню, потому что тогда сам решал эту лабу) Примерно в то же время эксплуатировал CSWSH на пентестах, и SameSite никак не мешал.
Очень занимательно!
Интересно, тут затронуто JWT и его access-токен. А как дела обстаят с refresh-токеном ? Как нам в процессе ожидаемой длительного WS-соединения, при истечении коротко живущего токена, его обновить? Не выкидывать же сразу на переавторизацию?
В плане, с http мы каждый раз с запросом несём токен и можем в моменте среагировать на его обновление. А как быть с "потоком" WS ?
Вряд ли websocket существует дольше, чем время жизни refresh-токена.
Так сессия может идти дольше, чем жизнь access-токена. Ну можно с человеком общаяться по чату к примеру, же больше часа. Или потоковая система мониторинга. Там 24/7 соединение может держаться. А access-токен как раза на час примено часто ставят
Acess-токен протухает за секунды, максимм минуты, после чего фронтенд делает запрос на обновление acess-токена с refresh-токеном, время жизни которого измеряется днями, а обновляться он может вместе с access-токеном. Вы реально держите websocket-соединение несколько дней без обновления токенов?
так в этом и вопрос :) Как менять токен без обрыва соединения? Мы же не можем, используя WebSocket API, как в HTTP, налету понять, что токен протух.
Вот WebSocket соединение держится пусть 15 минут при жизни access-токена 10 минут. Как в последние 5 минут у WS поменять/обновить access-токен через refresh? При этом соединение нужно держать открытым! Т.к. handshake"дорогая" операция. Да и как отследить, что 10 минут прошло у конкретного пользователя с access-токен в многопользовательской системе?
Мы можем понять в HTTP в момент прихода пакета, и из заголовка проверить токент. В WS нет заголовков в момент получения пакетов (только при handshake мы может получить заголовок авторизации из HTTP-handshake, но делать handshake каждые 10 минут или даже менее ради обновления токена - это странно и не рационально)
Если правильно понимаю, условия такие:
Время жизни access token = X
Время жизни refresh token = Y
Время жизни WS-соединения = Z
И мы говорим, что X < Z < Y, так? И при этом мы, как я описывал, хотим отслеживать инвалидацию токена, чтобы уметь разрывать соединения?
Тут можно, кмк, рассмотреть несколько подходов в зависимости от задачи, например
Делать время жизни WS-соединения всегда меньшим, чем время жизни access token (насколько помню, я делал так)
Если у вас "сессией приложения" выступает refresh token, а не access token, можно подумать над тем, чтобы как-то связывать соединения с ним
Принять, что токен может истечь, а соединение продолжить какое-то время быть активным
Тут смотря какая специфика и нагрузка, наверное. Я полагал, что во многих случаях лишний раз "перезагрузить" WS-соединение для проверки актуальности кредов - не такая большая проблема.
В моих проектах обычно исходили из допущения, что если токен был валиден на момент установки соединения, то соединение валидно на всё время его жизни. Если бы надо было принудительно разлогинивать, то я бы просто слал в соединение какой-нибудь признак того, что сервер клиента разлогинил, а потом рвал соединение. Ещё теоретически ничто не мешает обновлять токены сообщениями внутри websocket-соединения, но это ненужная морока, на мой взгляд.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Аутентификация для WebSocket и SSE: до сих пор нет стандарта?