Сейчас очень популярны веб-токены JSON (JWT). Особенно в сфере веб-разработки.
- Популярность
- Безопасность
- стабилизировать
- легко использовать
- поддержка JSON
Все эти факторы делают JWT известным.
Однако сегодня я расскажу о недостатках использования JWT. Вот почему так плохо использовать JWT для управления сеансом.
Зачем использовать JWT?
Не нервничайте, если вы не понимаете JWT, это не страшно.
JWT реализует стандарт на основе JSON только для передачи утверждений по сети.
Например, я слепой и плохо слышу. Вы купили мой обед на прошлой неделе, и теперь мне нужен номер вашего счета, чтобы вернуть вам деньги. Если я попрошу номер вашего счета, а другие люди повторяют свой, я могу случайно назвать чужие деньги, потому что я принял чужой счет за ваш.
JWT предназначен для предотвращения этого. JWT предоставляют простой способ проверить, кто первым создал данные при передаче данных друг другу.
Итак, как и в приведенном выше примере, даже если я получу более 1 миллиона JWT, возвращающих информацию об учетной записи, я могу легко определить, какой из них действительно от вас.
Как работает JWT?
JWT — это зашифрованная строка в формате JSON.
Ядром JWT является ключ, который представляет собой данные JSON. Это данные, которые вам небезразличны и которые вы хотите безопасно передать. То, как JWT это делает и заставляет вас доверять, криптографически подписано.
Например, если я пишу письмо, когда я подписываю письмо, это означает, что любой, кто читал письмо, знает, что я его написал. А моя подпись уникальна, так что в подлинности можно не сомневаться. Методы шифрования и подписи примерно одинаковы.Для JWT существует два метода шифрования: симметричное шифрование и асимметричное шифрование.Эти два метода имеют одинаковый эффект.
JWT-шифрование контента
На самом деле содержимое JWT (внутренние данные JSON) обычно не шифруется. Это означает, что данные внутри JWT можно просмотреть даже без ключа. JWT не шифрует ваши данные по умолчанию, он просто помогает вам убедиться, что их создала сторона, которой вы доверяете.
Если вам нужно зашифровать содержимое JWT, вы можете зашифровать его с помощью JWE, но это не является общепринятой практикой. Убедитесь, что используете правильный метод.
Как люди используют JWT сегодня?
Наиболее распространенное использование JWT — аутентификация. Существует множество библиотек веб-безопасности, которые используют JWT для создания элементов управления сеансом, токенов API и т. д.
Этот подход обычно заключается в том, что когда веб-сайт/API необходимо аутентифицировать, сервер генерирует JWT, содержащий идентификатор пользователя и некоторую другую ключевую информацию, которая затем отправляется браузеру/клиенту и т. д. и сохраняется как токен сеанса.
Например, когда пользователь посещает другую страницу веб-сайта, браузер автоматически отправляет этот JWT на сервер, сервер проверяет, совпадает ли JWT с изначально созданным токеном, а затем позволяет пользователю выполнять последующие действия.
Теоретически неплохо, потому что:
- Когда сервер получает JWT, он может проверить, является ли он законным и является маркером доверия пользователю.
- Аутентификация может выполняться локально на сервере без каких-либо других сетевых запросов, связи с базой данных и т. д. Это может сделать управление сессиями более эффективным, так как нет необходимости загружать информацию о пользователе из базы данных (кэша), нужно лишь локально запустить небольшой объем кода. Это, вероятно, главная причина, по которой людям нравится использовать JWT.
Кажется, это здорово как повысить производительность вашего веб-приложения, так и снизить нагрузку на сервер кеша и сервер базы данных для лучшего взаимодействия. Кроме того, вы можете хранить информацию о правах пользователя, личную информацию пользователя и другую дополнительную информацию в JWT, чтобы еще больше уменьшить нагрузку на базу данных.
Почему JWT не лучший токен сеанса?
Теперь, когда мы увидели, как JWT используются для аутентификации, давайте перейдем к центральной теме этой статьи: почему JWT не лучший токен сеанса и почему старые простые методы сеанса лучше, чем JWT почти во всех отношениях.
задний план
Сначала давайте немного предыстории. Большинство веб-сайтов, которые создают разработчики, относительно просты:
- Регистрация пользователя
- Логин пользователя
- Пользователь нажимает, чтобы выполнить действие
- Веб-сайт использует информацию о пользователе для создания, удаления, обновления и просмотра информации.
Для таких типов сайтов знайте, что каждая страница, с которой взаимодействует пользователь, будет содержать некоторые динамические данные. Например: вы посещаете веб-сайт, который требует от пользователя входа в систему для дальнейших операций, и вы часто будете выполнять эти операции с пользователем в базе данных:
- Запишите, что делает пользователь
- Добавить некоторую информацию о пользователе в базу данных
- Проверьте разрешения пользователя, чтобы узнать, могут ли они выполнять действие
- так далее
данные
Рассмотрим два варианта:
- Сохранить идентификатор пользователя в файле cookie (abc123)
- Сохранить идентификатор пользователя в JWT (abc123)
Если мы сохраняем идентификатор в файле cookie, он занимает 6 байт. Если вы храните идентификатор в JWT (устанавливаете основные поля заголовка запроса и некоторую другую информацию), это займет несколько сотен байтов или больше. Для простого управления сеансом запрос на каждую страницу увеличивается в десятки раз.
Если ваш сайт посещают 100 000 браузеров в месяц, это означает дополнительные десятки мегабайт трафика. Это не звучит как много, но это много денег с течением времени. На самом деле, многие люди будут хранить больше информации в JWT.
В любом случае вам нужно манипулировать базой данных
Как упоминалось выше, большинство веб-сайтов, которые требуют от пользователей входа в систему, в основном представляют собой операции CRUD (добавление, поиск, изменение и удаление) для создания динамического контента.
При использовании JWT на веб-сайте почти для всех страниц, загружаемых пользователем, информация о пользователе должна быть загружена из кеша/базы данных, могут возникнуть следующие ситуации:
- Требуется запрос информации о ключе пользователя (например: чтобы определить, достаточно ли средств на счете пользователя для завершения транзакции?)
- Нам нужна некоторая информация, сохраненная в базе данных (пример: уникальная информация, относящаяся к пользователю, которую пользователь должен получить на основе информации)
- Полная информация должна быть запрошена из кеша/базы данных, чтобы веб-сайт мог генерировать полный динамический контент страницы.
Подумайте, не столкнется ли ваш сайт с описанной выше ситуацией. Это означает, что большинство веб-сайтов не используют природу JWT без сохранения состояния. Чтобы решить эту проблему, JWT должен быть больше, а ЦП должен использоваться для вычисления подписи, что приводит к намного медленнее, чем традиционные сеансы.
Фактически, почти каждый веб-фреймворк поддерживает передачу информации о пользователе при каждом запросе, включая Django, Rails, Express.js и т. д. (если аутентификация полезна). Кроме того, если вы используете сервер кэширования, такой как Memcached/Redis, для кэширования информации о пользователях, извлечение станет очень быстрым.
избыточная подпись
Одним из преимуществ JWT являются криптографические подписи, благодаря которым получатель может убедиться, что JWT действителен и ему доверяют.
Однако на самом деле почти каждый фреймворк за последние 20 лет может получить хорошую обработку криптографической подписи для обычных сеансовых файлов cookie. Это означает, что вы можете получить точно такой же эффект, как JWT, и в большинстве приложений веб-аутентификации JWT хранится в файле cookie, что означает, что у вас есть два уровня подписи.
Звучит здорово, но преимущества нет, а для этого вам нужно вдвое больше ресурсов процессора для проверки подписи. Это не идеально для веб-приложений с жесткими требованиями к производительности, особенно для однопоточных сред.
Какое решение лучше?
Если вы создаете веб-сайт упомянутого выше типа, лучше использовать старый, простой и безопасный сеанс на стороне сервера. Вместо того, чтобы сохранять идентификатор пользователя в JWT, сохраните JWT в Cooike. Просто сохраните идентификатор пользователя непосредственно в файле cookie.
Если ваш сайт популярен и имеет большой трафик, вы можете кэшировать сеансы в Memcached/Redis, а также выгодно масштабировать свой сервис.
Когда использовать JWT?
Хотя JWT бесполезен для большинства веб-сайтов, есть несколько ситуаций, в которых он может быть полезен.
Если вы создаете службу API «сервер-сервер» или «клиент-сервер» (например, мобильное приложение или одностраничное приложение), то использование JWT очень разумно. Например:
- Ваш клиент должен пройти аутентификацию с помощью API и вернуть JWT.
- Затем клиент использует возвращенный JWT для аутентификации, чтобы запросить другие службы API.
- Эти другие службы API проверяют через JWT клиента, что клиент является доверенным и может выполнять определенные операции без повторной аутентификации.
Для таких API-сервисов очень подходит JWT, потому что клиенту нужно делать частые запросы, а разрешения контролируются, обычно данные аутентификации сохраняются без сохранения состояния, и нет необходимости слишком полагаться на информацию о пользователе.
JWT также отлично подходит, если вы создаете приложение, такое как единый вход или аутентификация OpenID Connect, которое должно реализовать способ аутентификации пользователей через третью сторону.
Суммировать
Когда вы будете готовы создать свой следующий веб-сайт, вам нужно только использовать функцию аутентификации по умолчанию веб-фреймворка, нет необходимости интегрировать метод JWT.
Подпишитесь на официальный аккаунт Zhanbaishuo, чтобы получать более ценную информацию.