В чем преимущество использования JWT над сеансами в таких ситуациях, как аутентификация?

Используется ли он как отдельный подход или используется в сеансе?

Pourya8366

Ответов: 5

Ответы (5)

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

Люди часто имеют в виду, когда спрашивают: «Каковы преимущества использования JWT по сравнению с сеансами на стороне сервера».

С сеансами на стороне сервера вам придется либо сохранить идентификатор сеанса в базе данных, либо сохранить его в памяти и убедиться, что клиент всегда обращается к одному и тому же серверу. У обоих есть недостатки. В случае базы данных (или другого централизованного хранилища) это становится узким местом и вещью, которую нужно поддерживать - по сути, дополнительный запрос, который нужно выполнять с каждым запросом.

Используя решение в памяти, вы ограничиваете горизонтальное масштабирование, и на сеансы будут влиять сетевые проблемы (роуминг клиентов между Wi-Fi и мобильными данными, перезагрузка серверов и т. Д.).

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

  • Надежное хранение токена.
  • Надежная транспортировка.
  • Иногда бывает трудно сделать недействительными сеансы JWT.
  • Доверие претензии клиента.

Эти проблемы характерны как для JWT, так и для других механизмов сеансов на стороне клиента.

JWT, в частности, обращается к последнему из них. Это может помочь понять, что такое JWT:

Это немного информации. Для пользовательских сеансов вы можете указать имя пользователя и время истечения срока действия токена. Но это может быть что угодно, даже идентификатор сеанса или весь профиль пользователя (пожалуйста, не делайте этого). Он имеет безопасную подпись, которая не позволяет злоумышленникам генерировать поддельные токены (вам нужен доступ к закрытому ключу сервера, чтобы подписать их, и вы можете убедиться, что они не были изменены после того, как были подписаны). Вы отправляете их с каждым запросом, как cookie или Авторизация Заголовок. Фактически, они обычно отправляются в заголовке HTTP Authorization, но использование файла cookie тоже нормально.

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

Что касается безопасной транспортировки токена, обычно ответ заключается в его отправке через зашифрованный канал, обычно httpS.

Что касается безопасного хранения токена в клиенте, вам необходимо убедиться, что злоумышленники не смогут добраться до него. Это (в основном) означает предотвращение того, чтобы JS с плохих веб-сайтов читал токен, чтобы отправить его им. Это смягчается с помощью тех же стратегий, которые используются для смягчения других видов XSS-атак.

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

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

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

Короче говоря: JWT отвечает на некоторые вопросы и недостатки других методов сеанса.

  1. «Более дешевая» аутентификация, потому что вы можете исключить двусторонний обход БД (или, по крайней мере, иметь гораздо меньшую таблицу для запроса!), Что, в свою очередь, обеспечивает горизонтальную масштабируемость.

  2. Заявления о защите от взлома на стороне клиента.

Хотя JWT не отвечает на другие вопросы, такие как безопасное хранение или транспортировка, он не создает никаких новых проблем безопасности.

Вокруг JWT существует много негатива, но если вы реализуете ту же безопасность, что и для других типов аутентификации, все будет в порядке.

И последнее замечание: это также не Cookies vs Tokens. Файлы cookie - это механизм для хранения и передачи битов информации, который также может использоваться для хранения и транспортировки токенов JWT.

Мои два цента, которые по пути добавляют некоторого контраста знаменитому сообщению в блоге joepie91.

Considering that today's (and tomorrow's) applications are (mostly) cloud native
There's an economic benefit to Stateless JWT Authentication, which scales as the application scales:
Cloud applications incur cost with every passing second.
This cost is reduced when users no longer have to authenticate "against" a session store.

Обработка
Работа магазина сессий 24/7 стоит денег.
В мире K8S не обойтись без решений на основе памяти, так как поды недолговечны. Прикрепленные сеансы не будут успешными по той же причине.

Хранилище
Хранение данных стоит денег. хранение данных на SSD стоит еще дороже.
Операции, связанные с сеансом, необходимо решать быстро, поэтому оптический привод не подходит.

Ввод / вывод
Некоторые облачные провайдеры взимают деньги за ввод-вывод, связанный с дисками.

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

Кластеризация хранилища сеансов
Стоимость увеличивает все вышеупомянутые затраты еще больше.

У меня был аналогичный вопрос при выборе между JWT и токеном + кешем для аутентификации пользователя.

После прочтения этих статей мне стало ясно, что преимущества, которые обещает JWT, не опережают проблемы, которые он приносит. Так что токен + кеш (Redis / Memcached) - это то, что мне нужно.

Заголовки аутентификации против JWT и сеансов - как выбрать правильный метод аутентификации для API

Методы аутентификации для API

Прекратить использование jwt для сессий

Короткий ответ: Нет.

Более длинная версия:

Я реализовал JWT для управления сеансом после прочтения этой рекомендации в документах GraphQL:

Если вы не знакомы ни с одним из этих механизмов аутентификации, мы рекомендую использовать express-jwt, потому что это просто, не жертвуя любая гибкость в будущем.

Реализация была действительно простой, так как только добавляла немного сложности. Однако через некоторое время я (как и вы) начал задаваться вопросом, в чем заключаются преимущества. Оказывается, что для JWT очень мало (или, возможно, совсем нет) в том, что касается управления сеансами, как подробно объясняется в этом сообщении в блоге:

Прекратить использование JWT для сеансов

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

Мы реализовали хранилище сеансов PHP5.x на AWS ElastiCache для централизации хранилища сеансов на нескольких серверах.

Он работал до совершенства, пока мы не перешли на PHP7. Было сложно настроить PHP7, и нас мучили периодические проблемы, когда казалось, что сеанс «не удался / не совпал / немного запутался» для конкретного пользователя, а затем они не могли войти в систему на этом устройстве до истечения срока действия старого сеанса.

Мы перешли на использование DynamoDb для хранения сеанса и больше никаких проблем. Это немного медленнее, но заметно только на этапе входа в систему (хранения сеанса).

Пока это продолжалось, мы внедрили AWSognito, чтобы заменить нашу аутентификацию, и начали использовать API-шлюз для доставки контента с помощью лямбда-функций Python.

Мы используем PHP SDK для аутентификации в Cognito, а затем сохраняем JWT в cookie, но при этом также используем сеанс PHP, чтобы наш устаревший код работал.

Теперь у нас есть два стека и лучшее из обоих миров: PHP7 немного справляется и передает основной контент пользователю (очень быстро). Затем JS берет на себя и предоставляет дополнительный контент с помощью JWT.

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

Теперь мы задаемся вопросом, стоит ли делать решительный шаг и полностью переходить на новую систему JWT?

В PHP мы по-прежнему используем наш унаследованный сеанс, но мы также передаем токен когнито для его аутентификации. Это немного дополнительная безопасность, которая, вероятно, не нужна, но дает ощущение теплого уюта. Опять же, есть расходы и обслуживание с помощью DynamoDb, которые можно было бы сэкономить.

2022 WebDevInsider