Комментарии 5
Я думал его основная цель — сокращение числа запросов к хранилищу, которое требуется для серверной сессии.
В начале вы пишете, что с сокетами JWT не взлетел
так как в данном протоколе передача хедера Authorization с jwt токеном невозможнаи единственная альтернатива — параметры URL, а в итоге получается, что вы используете другую альтернативу
он отправляет событие auth_login по сокетам, с jwt токеном— передаёте JWT в теле сообщения через сокеты.
Наверное я что-то неправильно понял. Впрочем как и с той статьёй, что вы рекомендовали
Зачем нужен Refresh Token, если есть Access Token?.Когда я её в своё время прочитал вместе с комментариями, показалось, что никто на самом деле и не знает, зачем нужен Refresh токен, и вообще как и какие проблемы решает JWT, а какие создаёт. Чего стоят одни только вопросы реализации отзыва токена и безопасности его хранения на стороне пользователя.
Я считал, что основной смысл jwt — убрать проблему синхронизации сессий между бэкенд серверами. Если есть сессии зачем токен?
Если использовать WSS, и производить авторизацию через сообщения, то получить токен возможно лишь при доступе к серверу или к устройству (ну или при взломе SSL|TLS если вы имеете соответствующий квантовый ПК).
Если есть доступ к устройству, то без проблем можно получать актуальный токен для каждого запроса.
Если используется не шифрованный канал, то можно добавить лимит действия токена после которого необходимо обновить токен. Если Алиса обновит токен и следом, раньше положенного времени Боб попытается обновить, то токен инвалидируется и наоборот. К примеру обновление токена каждые 30 минут, и два и более клиентов не смогут сделать обновления токена в заданный интервал. Если у Алисы не было доступа к интернету, то она может обновить его когда подключится и продолжить интервальные обновления.
Если я что то упускаю Welcome!
Авторизация и аутентификация на NodeJs и Socket.io и проблемы вокруг