Как правильно инвалидировать JWT токены?

Question

[Max Voronov]

Столкнулся с, на первый взгляд, не сложной задачей. А именно - как правильно инвалидировать токен? Например, если пользователь делает logout или изменяет свой пароль.

Коротко о задаче: есть обычное REST API, в котором часть функционала требует чтобы пользователь был авторизован. Это реализуем через JWT.

Поискав ответ в сети нашел несколько идей на этот счет:

• На клиенте "забывать" токен
  Это самое простое решение, но реально токен ведь продолжает работать до тех пор, пока не истечет его срок жизни. А значит это решение не очень безопасно.
  
  
• Хранить в БД blacklist с токенами
  Если пользователь инвалидирует токен, то мы записываем его в БД. И при каждом запросе проверяем нет ли переданного токена в черном списке. И, конечно, чистим базу по expire.
  Вполне жизнеспособный вариант, но тогда отчасти теряется смысл JWT.
  
  
• Изменять secret
  Удобный вариант когда нужно инвалидировать токены у всех пользователей. Но если делать индивидуальный secret для каждого пользователя, то его нужно где-то хранить (снова БД?) и нельзя использовать более надежный алгоритм RS256. Кстати, дополнительный вопрос - есть ли смысл его использовать для web токенов?
  
  

Честно говоря, ни один из найденных мною вариантов мне не кажется полноценным решением. Есть чувство что я что-то упустил. Буду рад услышать любые мысли и советы на этот счет.

Comments

[Lynn «Кофеман»]

Всё так. Как только появилась такая задача у вас сразу появляется какая-то база.

[Max Voronov]

Алексей Тен: Получается никак нельзя свести работу с БД к минимуму? Я думал над вариантом "короткие" access_token + refresh_token. Но такой способ нельзя применить с тем же web-клиентом. Как же тогда на highload проектах решают эту задачу?

[Max Voronov]

Сергей Воскресенский: Сессии подходят для обычных сайтов. Но для REST API их использовать нельзя, поскольку в нем нужно придерживаться stateless состояния.

Answer 1

[Владимир Грабко]

Для этого юзайте быстрое хранилище, а не бд (аля редис). В редисе храним секретный ключ для токенов (у каждого токена свой). При выходе обновляете ключ. Ну и конечно забываем на клиенте.

UPD.
В редисе записи вида
user_id : secret

По такой схеме и работают все.

Comments

[Max Voronov]

Спасибо за ответ. Собственно пока этот вариант я выбрал единственным реально работающим.

А что вы думаете насчет следующей схемы работы:
1. При авторизации выдаем access_token с маленькиим TTL (скажем 5-10 минут) и refresh_token. Хранить у себя в базе будем только refresh токены.
2. Раз в 5-10 минут от пользователя будет приходить запрос на обновление обоих токенов. Это не создаст особой нагрузки и избавит от необходимости проверять токен при каждом пользовательском запросе (JWT в действии).
3. Если пользователь делает логаут - то на клиенте забываем оба токена, а на сервере обнуляем refresh токен в базе.

Насколько безопасна такая схема работы и какие могут быть подводные камни в ней?

[Владимир Грабко]

Max Voronov: это всё костыли. А так при выходе в 1 месте мы выходим со всех устройств (кража токена не страшна). А теперь придумаю защиту от кражи в своей версии. Надо делать максимально просто.

[Max Voronov]

Владимир Грабко: Тогда получается смысла от JWT нет. По сути это реализация обычных токенов если каждый запрос через БД проверять. Это во-первых. А во-вторых, как тогда реализовать данный подход в микросервисной архитектуре или же когда сервис авторизации отдельный, а несколько проектов работают через него? В таком случае мы получаем огромный оверхед к каждому запросу.

[Владимир Грабко]

Max Voronov: я когда то был как ты. Мучал jwt и понял что лучше сделать обычный токен. Ну обычно между мордой и микросервисами стоит шлюз который и проверяет авторизацию и так дальше. Прочти от корки до корки https://habrahabr.ru/company/piter/blog/275891/

[Max Voronov]

Владимир Грабко: Возможно я чересчур идеалист) API Gateway в большинстве случаев всегда есть. Но архитектурно должен быть отдельный микросервис, отвечающий за авторизацию. API Gateway же должен содержать минимум логики и в идеале просто проксировать запросы. И в таком случае мы каждый раз будем ждать пока нам ответит микросервис авторизации. Я об этом оверхеде имел ввиду.

[askord]

Это шутка такая что ли? Ужас. Во-первых мы не знаем к какому юзеру привязан токен, пока мы его не расшифровали. А значит хранить user_id:secret это бессмыслица. Встает вопрос что хранить? Сам токен? Иметь отдельную БД которая хранит всю секьюрную информацию? А если мы ее потеряем? Не знаю кто все, кто так работает, но это жесть

[Max Voronov]

askord: Не вижу в чем проблема. Когда приходит запрос с токеном мы его в любом случае будем валидировать. А данные в токене хранятся в нешифрованной форме. Поэтому user_id мы можем получить очень легко и он больше нам нужен чтобы лишний раз не дергать БД. Токены нам нужно хранить для того, чтобы мы могли проверять refresh_token. Если мы ее потеряем, то юзерам просто придется перелогиниться, что не так уж и страшно.

> Не знаю кто все, кто так работает, но это жесть
Я немного не уверен, что вы до конца разобрались в JWT. Но в любом случае буду рад услышать ваши идеи и предложения.

[askord]

Я немного не уверен, что вы до конца разобрались в JWT. Но в любом случае буду рад услышать ваши идеи и предложения.

Если овер секьюрность не требуется или если это только апи для мобилок, да еще запросы передаются через ssl, то не заморачиваться, а сделать долгоживущий токен (например полгода-год), который при sign out удаляется с клиента. Ну и еще добавить blacklist для фичи аля "завершить все сеансы" если клиент считает что токен скомпрометирован. Этого будет достаточно.

[Max Voronov]

askord: Тогда это получается обычные токены, а не JWT. И все преимущества теряются. Делать долгоживущий токен нет смысла, ведь для этого у нас есть refresh_token который как раз и является долгоживущим. Но основная работа с API будет вестись через access_token с коротким сроком жизни.

Blacklist тоже по сути лишнее. Ведь по задумке я хотел избавиться от лишних запросов к БД. Быстрые KV-хранилища не в счет, интересна больше сама возможность избавиться от лишних запросов. Если токен скомпроментирован, то мы можем инвалидировать refresh_token. После чего уже будет невозможно получить новый access_token без повторного входа. Но вот для старого access_token придется ждать пока он сам не "умрет".

[askord]

Max Voronov: почему теряются? основной плюс jwt что он self-contained и что нам не надо запрашивать БД при каждом запросе. refresh token это как одна из технологий, это не стандарт, это всегда на твое усмотрение. Лично мне бадяга с refresh токенами не нравится, она во многих случаях бессмысленна, сильно усложняет клиентский и серверный код и добавляет ни к чему ненужную овер псведосекьюрность.

Вообще без блеклиста ты никак не обойдешься. Как ты будешь инвилидировать refresh token? Делать точно такой же запрос в БД.

Мое предложение в том, что в большинстве приложений будет достаточно стирать токен с клиента и все. И как доп. секьюрность блеклист в редисе для исключительных случаев (типа завершить все сеансы), который будет работать практически мгновенно.

[bro-dev]

askord, если у вас база секретных ключей то вы каждый запрос обращаетесь к этой базе, смысл jwt теряется это те же сессии.