Как правильно реализовать авторизацию через JWT?

Question

[jenya7771]

Здравствуйте, понимаю что уже есть куча статей по этому поводу, но всё таки решил задать ещё вопрос, чтобы более прояснить.
Вопрос заключается в способе отзыва и осуществления контроля над токеном, без хранения заблокированы токенов в БД, и возможностью оперативно его блокировать?

Answer 1

[jacob1237]

Используя пару access_token и refresh_token, попробуйте уменьшить время жизни access_token, например до 10 или 20 минут.
Хранить access_token'ы в базе данных смысла нет, так как главная фишка JWT не столько в stateless сессии, сколько в децентрализации (вернее, одно проистекает из другого).

Таким образом серверы, принимающие access_token, могут проверить его правильность без необходимости использовать какие-то внешние сервисы.

И да, основной побочный эффект в этом случае как раз заключается в том, что даже после блокировки refresh_token, access_token будет действовать еще какое-то время.

Это всегда некий компромисс между удобством и безопасностью.

Answer 2

[Андрей Хохлов]

Расскажу как делал я.

Создаём пару refresh_token и access_token и сохраняем в БД.

{
  refresh_token: XXX,
  access_token: YYY,
  user_id: ZZZ,
  client_id: A,
}

Отправляем оба клиенту.
Для запросов используется access_token, он содержит нужную инфу о юзере и в БД лезть не заставляет.
Чтобы получить новую пару, используем refresh_token. Старую пару при этом можно удалить, чтобы не раздувать БД.

Остаётся проблема с тем, как заблокировать access_token.
Я использую Redis для хранения списка заблокированных токенов, при этом хранятся они не больше времени жизни токена.

Итого:
Авторизациям > запрос к БД > получили токены
Запрос с токеном > проверка на отсутствие в Redis > расшифровка токена
.... через 60 минут (или другое время жизни токена)
Запрос на обновление токена > запрос к БД > новые токены > запись в Redis

Такая схема позволяет авторизоваться на нескольких устройствах сразу, управлять своими авторизациями (выйти со всех устройств, выйти с устройств А и В).

Comments

[jenya7771]

Спасибо за идею, буду использовать вашу методику. Но возник вопрос, по истечению access токена, клиент отправляет refresh токен и мы выдаём новый assess токен, без изменения refresh? Для чего заменять тогда всю пару?

[Андрей Хохлов]

jenya7771, только access_token, просто строку. Ведь refresh_token у нас проверяется по БД при использовании.

[jenya7771]

Андрей Хохлов, refresh токен может быть просто хеш, или в него нужно инфо сохранять какую либо?

[Андрей Хохлов]

jenya7771, просто уникальная строка
Я вот так делал:

user.id.toString() + '.' + crypto.randomBytes(40).toString('hex');

[jenya7771]

И получается, если пользователь выходит на устройстве, то из базы удаляем пару токенов, и по истечению жизни access токена, пользователь не получает новый access токен, правильно мыслю? Не могу понять для чего access токен в redis записывать, у него же есть время жизни?

[RidgeA]

В общем получилась обычная сесстия с JWT в виде сессионного ключа.
ИМХО суть JWT в stateless сессии, и, если ограничения такого подхода не позволяют его использовать в рамках решаемой задачи, не надо тащить его везде где только можно.

[Андрей Хохлов]

jenya7771, при выходе с устройства access токен попадает в чёрный список. То есть становится невалидным до истечения своего срока действия.

RidgeA, да, почти так. Преимущество в том, что можно использовать этот подход не зависимо от типа устройства - обычный браузер с куками или умный утюг.
Ну а так нюансы - или сессия где-то хранится и мы её по ключу достаем, или токен уже содержит всё в себе, но мы проверяем не в черном списке ли он.

А вот такое "чистое" использование JWT, без возможности его сделать невалидным до истечениям, где вообще можно применить? Ну то есть если я не могу украденный токен заблочить и мне остается только сидеть и смотреть как злоумышленник его юзает - нафиг бы такую систему авторизации?

[RidgeA]

Андрей Хохлов,

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

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

Ну а так нюансы - или сессия где-то хранится и мы её по ключу достаем, или токен уже содержит всё в себе, но мы проверяем не в черном списке ли он.

Все-равно надо лезть в базу и проверять. А что доставать - всю сессию или только факт валидности - дело десятое. Если на то пошло, то "дешевле" взять сессию из базы на локальном сервере (на другой машине в локальной сети) чем у клиента, который отправляет запрос через 3G.

А вот такое "чистое" использование JWT, без возможности его сделать невалидным до истечениям, где вообще можно применить? Ну то есть если я не могу украденный токен заблочить и мне остается только сидеть и смотреть как злоумышленник его юзает - нафиг бы такую систему авторизации?

Честно говоря - не знаю. Как по мне - какой-то прототип или система, где авторизация не сильно важна. Гораздо более безопасной выглядит для меня схема с хранением сессии на сервере.

P.S. Я не критикую - просто написал что stateless JWT авторизация имеет достаточно узкий usecase.

[Андрей Хохлов]

RidgeA,

Все-равно надо лезть в базу и проверять.

Ну в моём варианте Redis, возможно максимально быстрое решение)

А в целом да, согласен с вами.

jacob1237 внизу правильную вещь пишет про компромис. Но чем чаще мы гоняем refresh-токен, тем менее ещё больше превращаем всё сессии)

[RidgeA]

Ну в моём варианте Redis, возможно максимально быстрое решение)

Под базой я имел ввиду в первую очередь redis/memcached :-)

[jacob1237]

У JWT есть один идеальный вариант применения: если в системе используется несколько/много серверов, которые не связаны между собой одним доменом (например в ситуации с микросервисной архитектурой) и которые максимально децентрализованы.

Вот в этом случае, когда нужно сделать Single Sign On (SSO), то есть единую точку аутентификации, применение JWT как раз весьма удобно.

Пишется дополнительный сервис аутентификации, который отдает клиентам refresh_token и access_token и периодически обменивает access_token на новый.

Все остальные сервисы должны лишь проверить access_token на правильность, т.е. сверить криптоподпись и текущее время. Если токен еще актуален, то авторизация пройдена и можно делать работу.

Во всех остальных случаях удобнее взять cookies и не забивать голову. Если у вас нет необходимости делать Single Sign On, то Вам, вероятно, и не нужен JWT.

В конечном счете JWT это просто стандарт токена авторизации (с использованием JSON). Саму схему авторизации он не регламентирует.

Answer 3

[Philipp]

Я использую достаточно своеобразный подход к выдаче JWT.
У каждого пользователя есть специальное поле, назовем его passId. Оно меняется при смене пароля. Просто генерируется из /dev/random. От этого поля считается хэш и добавляется внутрь JWT. При проверке токена сверяется passId. При необходимости можно усложнить схему и выдавать passId на каждое устройство индивидуально.
Также связку user:passId легко хранить в любом NoSQL-хранилище и упреждающе обновлять там при смене пароля/компроментации аккаунта.

Comments

[Андрей Хохлов]

jenya7771 вот и интересная альтернатива чёрному списку)