askord: Тогда это получается обычные токены, а не JWT. И все преимущества теряются. Делать долгоживущий токен нет смысла, ведь для этого у нас есть refresh_token который как раз и является долгоживущим. Но основная работа с API будет вестись через access_token с коротким сроком жизни.
Blacklist тоже по сути лишнее. Ведь по задумке я хотел избавиться от лишних запросов к БД. Быстрые KV-хранилища не в счет, интересна больше сама возможность избавиться от лишних запросов. Если токен скомпроментирован, то мы можем инвалидировать refresh_token. После чего уже будет невозможно получить новый access_token без повторного входа. Но вот для старого access_token придется ждать пока он сам не "умрет".
askord: Не вижу в чем проблема. Когда приходит запрос с токеном мы его в любом случае будем валидировать. А данные в токене хранятся в нешифрованной форме. Поэтому user_id мы можем получить очень легко и он больше нам нужен чтобы лишний раз не дергать БД. Токены нам нужно хранить для того, чтобы мы могли проверять refresh_token. Если мы ее потеряем, то юзерам просто придется перелогиниться, что не так уж и страшно.
> Не знаю кто все, кто так работает, но это жесть
Я немного не уверен, что вы до конца разобрались в JWT. Но в любом случае буду рад услышать ваши идеи и предложения.
Владимир Грабко: Возможно я чересчур идеалист) API Gateway в большинстве случаев всегда есть. Но архитектурно должен быть отдельный микросервис, отвечающий за авторизацию. API Gateway же должен содержать минимум логики и в идеале просто проксировать запросы. И в таком случае мы каждый раз будем ждать пока нам ответит микросервис авторизации. Я об этом оверхеде имел ввиду.
Сергей Воскресенский: Сессии подходят для обычных сайтов. Но для REST API их использовать нельзя, поскольку в нем нужно придерживаться stateless состояния.
Владимир Грабко: Тогда получается смысла от JWT нет. По сути это реализация обычных токенов если каждый запрос через БД проверять. Это во-первых. А во-вторых, как тогда реализовать данный подход в микросервисной архитектуре или же когда сервис авторизации отдельный, а несколько проектов работают через него? В таком случае мы получаем огромный оверхед к каждому запросу.
Спасибо за ответ. Собственно пока этот вариант я выбрал единственным реально работающим.
А что вы думаете насчет следующей схемы работы:
1. При авторизации выдаем access_token с маленькиим TTL (скажем 5-10 минут) и refresh_token. Хранить у себя в базе будем только refresh токены.
2. Раз в 5-10 минут от пользователя будет приходить запрос на обновление обоих токенов. Это не создаст особой нагрузки и избавит от необходимости проверять токен при каждом пользовательском запросе (JWT в действии).
3. Если пользователь делает логаут - то на клиенте забываем оба токена, а на сервере обнуляем refresh токен в базе.
Насколько безопасна такая схема работы и какие могут быть подводные камни в ней?
Алексей Тен: Получается никак нельзя свести работу с БД к минимуму? Я думал над вариантом "короткие" access_token + refresh_token. Но такой способ нельзя применить с тем же web-клиентом. Как же тогда на highload проектах решают эту задачу?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Blacklist тоже по сути лишнее. Ведь по задумке я хотел избавиться от лишних запросов к БД. Быстрые KV-хранилища не в счет, интересна больше сама возможность избавиться от лишних запросов. Если токен скомпроментирован, то мы можем инвалидировать refresh_token. После чего уже будет невозможно получить новый access_token без повторного входа. Но вот для старого access_token придется ждать пока он сам не "умрет".