Комментарии 40
@
сразу отвечай
Отзыв токена?
в localStorage? session? cookie?
Одно дело по https отправляется. А другое дело хранится в браузере. Вредоносное расширение может получить ключи?
Если для вас вопрос утечки токена — это большая проблема, то стоит пересмотреть архитектуру, и в частности целесообразность использования JWT вообще.
2. проблема не в JWT — любой пароль меняется на условный токен, который может быть кукой, сессией и т.д.
я не говорю про физический доступ к компьютеру со стороны злоумышленника.
а вполне обычный кейс, человек поставил скомпрометированое расширение, или открыл вредоносный сайт в соседней вкладке.
получается токены могут быть успешно получены из соседней вкладки?
"admin":true
, это выглядит не слишком безопасно. А идея добавлять случайные строки вполне катит. Ах да, и ограничивать токен по времени, активно использовать revoke/refresh политики. А еще CORS и все такое. Тогда атаки типа man-in-the-middle почти не страшны.В самом токене хранить только самые базовые значения (например, только логин пользователя и fingerprint), а уже на сервере решать, что именно этот пользователь может делать.А чем это тогда отличается от обычной сессии?
А чем это тогда отличается от обычной сессии?
stateless и прочие плюшки токенов сохраняются.
Вот тоже не понимаю, почему логика должна зависеть от того что лежит в токене.
По идее там должны быть только «read-only» значения для клиента. На бэкенде мы все равно в большинстве случаев определяем юзера по этому токену и подтягиваем его данные из базы или какого-нибудь сервиса (с ролями/правами и т.д.)
а бэкенде мы все равно в большинстве случаев определяем юзера по этому токену и подтягиваем его данные из базы или какого-нибудь сервиса (с ролями/правами и т.д.)
Представьте, у вас микросервисная архитектура. Один из сервисов предоставляет премиальную услугу (некую информацию, которую могут получить только премиальные пользователи). Этот сервис ничего не знает о пользователях и не имеет связи с базой данных пользователей (зачем?). Вместо этого этот сервис может напрямую из токена взять права или роль пользователя и определить — может ли данный пользователь получать данную информацию. Причём данный сервис может делать запросы еще к каким-то сервисам (которые в свою очередь тоже могут определять, что можно показать, а что нельзя опять же по данным токена). Соответственно, в такой схеме мы избегаем избыточных запросов к базе пользователей. Конечно, вы скажете, запросы можно кэшировать и нагрузка не будет сильно высокой — но вот видите, уже добавляется очередная задача, которой можно было избежать.
ну какие-то клеймы же можно положить в токен, чтобы на фронте отображать/скрывать контент для админа или обычного пользователя и другие кейсы делать.
а на бэке все равно проверять права, читать из токена это не секьюрно. даже если они подписаны.
а на бэке все равно проверять права, читать из токена это не секьюрно. даже если они подписаны.
Если несекьюрно брать права из подписанного токена, то тогда оттуда несекьюрно брать вообще всё. Ибо, если представить, что некий злоумышленник может подписать токен, то этот кто-то может представиться и любым пользователем вообще. А следовательно токену нет доверия от слова совсем. Вы это хотели сказать?
а токен к примеру живет долго.
понятное дело что по хорошему — при изменении прав/доступов и т.д. надо перевыпускать токен, а старый отправлять в черный список.
Access Token не должен жить долго
для вредоносного скрипта даже 10 сек хватит сделать все.
Старый токен отправить в черный список нельзя
как раз практика говорит о том, что рефреш токен когда перевыпускается — старый прибивается. ибо он не нужен нигде, ни на фронте, ни на беке.
а Access Token добавляют в черный список когда делают блокировку токенов, например пользрователь руками в личном кабинете делает выход со всех устройств, кроме текущего, тогда система добавляет все Access Token'ы в черный список.
За эти 10 секунд никто не успеет выдать пользователю права, а потом забрать их.
для вредоносного скрипта даже 10 сек хватит сделать все.
Хватит. А хватит ли 10 секунд, чтобы обнаружить компрометацию учетной записи/токена, перенастроить права и заблеклистить токен?
Сама идея Access/Refresh токенов как раз и базируется на том, что мы доверяем содержимому подписанного Access-токена и потому он должен быть коротко живущим. А вот Refresh-токен мы используем только для получения нового Access-токена. И ему мы доверяем только в плане аутентификации пользователя (но не авторизации!). И так как для удобства Refresh-токен является долгоживущим, там и нужна возможность блокировки.
как раз практика говорит о том, что рефреш токен когда перевыпускается — старый прибивается. ибо он не нужен нигде, ни на фронте, ни на беке.
Я вел речь об access токене — это ведь из контекста нашей дискуссии ясно. Что касается refresh токенов, то черные списки могут и должны быть, но только и там никто не ведет учёт всех выданных токенов.
Не надо перевыпускать. Достаточно его отзывать. Тогда пользователь при обращении получит 401 ошибку и пойдет получать новый токен
Лучше не изобретать велосипеды и следовать рекомендациям owasp
Статье уже три года, а люди все еще продолжают решать одни и те же проблемы, самостоятельно придуманные на свою пятую точку.
Прочитал статьи эти. Один момент смутил — автор говорит, что из localStorage любой javascript может получить данные. Но вроде же можно только с того же домена читать localStorage? Наоборот, если пользователь зайдет на вредоносный сайт, то он сможет какой-нибудь запрос на https://sberbank.ru с правильными куками отправить, а вот ничего из localStorage относящегося к sberbank.ru он использовать не сможет, разве не так?
Вы понимаете все верно. Куки подвержены CSRF, а localStorage подвержен XSS.
Автор статьи подразумевает, что бороться с CSRF значительно проще, потому что он изучен на десяток лет больше, и в принципе закрывается csrf токеном. В то же время XSS значительно сложнее для защиты — к примеру каждый новый SPA Framework может иметь свою дыру.
Перехват токенов
Непонятный пункт.
Если предположить что клиент это браузер, то зачем вообще JWT, если можно кукисы использовать?
PS: Ни разу не слышал о таком механизме защиты от «перехвата токена» (есть OAuth2.0 Proof-of-Possession, но не похоже что его широко используют в данный момент).
И причем тут «перехват» (который как раз угроза доставки\хранения)?
Автор явно замахивался на что-то большее чем рассмотрения «метод кодирования». JWT например является частью эко-системы OpenID Connect, который подразумевает что клиент не всегда браузер, а значит надежный cookie management может быть недоступен.
PS: В session-кукисах JWT использовать безусловно можно (вот Play 2 это делает по умолчанию), вопрос целесообразности только.
А как передать этот токен с запросом и где хранить на клиенте — каждый решает сам, факторов много (вдруг общение по web-сокетам идёт, какие тогда тут куки).
Тогда мне не очень очевидно: чем это лучше хранения самого токена в cookie с HttpOnly Secure SameSite?
Шпаргалки по безопасности: JWT