Преимущества веб-токена JSON (JWT) по сравнению с токеном сеанса базы данных

С системой токенов сеанса базы данных я мог бы иметь логин пользователя с именем пользователя / паролем, сервер мог бы сгенерировать токен (например, uuid), сохранить его в базе данных и вернуть этот токен клиенту. Каждый запрос оттуда будет включать токен, и сервер будет искать, действителен ли токен и какому пользователю он принадлежит.

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

Это хорошо, но, помимо сохранения проверки базы данных для каждого запроса (что в любом случае будет быстрым, поскольку это просто проверка хеш-таблицы), мне не ясно, в чем преимущества использования JWT. Кто-нибудь, знакомый с этим, может объяснить? Давайте проигнорируем файлы cookie, это, в частности, пользовательский токен базы данных, как описано выше, и JWT, которые я пытаюсь сравнить и понять преимущества.


jwt access-token express-jwt json-web-token
person Skill M2    schedule 06.10.2014    source источник

Ответы (2)


arrow_upward
35
arrow_downward

Основное отличие заключается в размере хранилища сеансов и необходимости поиска на сервере:

  • На стороне сервера JWT хранит единственный ключ в памяти (или в файле конфигурации), который называется секретным ключом. Этот ключ имеет две цели: он позволяет создавать новые зашифрованные токены, а также работает как главный ключ, который «открывает все блокировки» - или в реальной жизни проверяет все токены. В результате сервер намного быстрее отвечает на запросы аутентификации, потому что не имеет значения, два или два миллиона пользователей вошли в систему - такое же количество записей (одна, этот ключ сервера) будет использоваться для аутентификации всех клиентских запросов.

  • Традиционная аутентификация, при которой сеансы пользователей хранятся в базе данных, создает запись в базе данных для каждого отдельного пользователя, что приводит к нескольким ключам. Таким образом, если у вас есть два миллиона пользователей, вошедших в систему, сервер создаст два миллиона записей, и с каждым клиентским запросом серверу необходимо найти соответствующую запись сеанса в базе данных *.

JWT предоставляет клиентской стороне возможность хранить и обрабатывать весь объект сеанса / пользователя. На самом деле это имеет гораздо больше смысла, потому что каждый клиент обрабатывает только свои собственные данные, поэтому это также не вызывает тяжелой работы со стороны клиента.

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

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

* Метод хранимых сеансов db можно оптимизировать с помощью эффективного кэширования и сохранения только идентификатора сеанса (в отличие от всего объекта пользователя) на быстром сервере ключ / значение, таком как Redis. Тем не менее, в большинстве случаев я бы все равно предпочел метод JWT db.

person EranG    schedule 23.06.2015
comment
Первые два пункта были тем, что я затронул в вопросе, но поскольку дополнительное хранилище и извлечение были для меня дешевыми, я не считал это огромным преимуществом, но я вижу, что это действительно может быть для некоторых случаев использования, что на самом деле Интересно то, что вы говорите о масштабируемости запросов аутентификации, это преимущество, а возможность перехвата сеанса - недостаток. Я в конечном итоге использовал jwt, кстати, но мне все еще нужно выяснить, как лучше всего справиться с потенциальным захватом сеанса, кроме запроса повторного ввода пароля для конфиденциального API. - person Skill M2; 29.06.2015
comment
На самом деле, захват - это то, что может происходить и с сеансами, просто с помощью сеансов вы можете очистить сеансы отдельных пользователей, тогда как, как и с jwt, вы не можете, изменение секретного ключа приведет к выходу всех из системы, но не может сделать это для отдельного пользователя. Масштабируемость и отсутствие управления, связанные с поддержанием сеансов, вероятно, дают JWT преимущество. - person Skill M2; 29.06.2015
comment
Посмотрите эту ветку и ответы, касающиеся проблем безопасности токенов jwt stackoverflow.com/questions/26739167/ идея состоит в том, чтобы сократить жизненный цикл токена и часто обновлять токены, или искать в Google токен обновления auth0 (без кавычек) для другого решение - person EranG; 29.06.2015
comment
Мне нужно было знать только первые два пункта. Очень хорошо объяснено, спасибо! Раньше я не знал, как обращаться с секретом. - person Tadej; 12.01.2017
comment
Я нашел это интересным cryto.net/~joepie91/blog/2016/06/19/ - person Alex; 06.03.2017

arrow_upward
1
arrow_downward

Токен на основе Json (JWT) решает следующие проблемы:

  1. Проблемы с мобильными устройствами: похоже, что у собственных мобильных приложений есть проблемы с файлами cookie, поэтому, если нам нужно запросить удаленный API, возможно, аутентификация сеанса - не лучшее решение.
  2. Проблемы с CSRF: если вы используете файлы cookie, вам необходимо иметь CSRF, чтобы избежать межсайтовых запросов.

Но JWT не использует сеансы, у него нет проблем с мобильными устройствами, ему не нужен CSRF, и он очень хорошо работает с CORS. Если у вас нет действующего токена, вы ничего не сможете сделать.

Еще один, поскольку этот токен хранится в клиентском локальном хранилище / хранилище сеанса, поэтому вы можете передавать эти токены и другим клиентам, но вы должны использовать те же учетные данные, которые вы использовали для создания этого JWT.

person Priyanshu Shekhar    schedule 06.10.2014
comment
Это преимущества, которые JWT предоставляет перед использованием файлов cookie, я понимаю это, но я спрашиваю о токенах сеанса, хранящихся в базе данных и сгенерированных сервером. - person Skill M2; 06.10.2014
comment
Кроме того, это преимущества токенов (как JWT, так и непрозрачных) по сравнению с файлами cookie. - person Waiting for Dev...; 07.11.2016