В чем преимущество использования JWT перед сеансами в таких ситуациях, как аутентификация?
Используется ли он как отдельный подход или используется в сеансе?
123
JWT не имеет преимуществ перед использованием "сеансов" за одно слово. JWT предоставляют средства поддержания состояния сеанса на клиенте вместо того, чтобы делать это на сервере.
Когда люди спрашивают об этом, часто имеют в виду: «Каковы преимущества использования JWT по сравнению с сеансами на стороне сервера ».
С сеансами на стороне сервера вам нужно будет либо сохранить идентификатор сеанса в базе данных, либо сохранить его в памяти и убедиться, что клиент всегда обращается к одному и тому же серверу. У обоих есть недостатки. В случае с базой данных (или другим централизованным хранилищем) это становится узким местом и тем, что нужно поддерживать - по сути, дополнительный запрос, который нужно выполнять с каждым запросом.
С помощью решения в памяти вы ограничиваете горизонтальное масштабирование, и на сеансы будут влиять сетевые проблемы (клиенты, перемещающиеся между Wi-Fi и мобильными данными, перезагрузка серверов и т. Д.)
Перенос сеанса на клиент означает, что вы удаляете зависимость от сеанса на стороне сервера, но это накладывает свой собственный набор проблем.
Эти проблемы одинаково присущи JWT и другим механизмам сеансов на стороне клиента.
JWT, в частности, обращается к последнему из них. Это может помочь понять, что такое JWT:
Это немного информации. Для пользовательских сеансов вы можете указать имя пользователя и время истечения срока действия токена. Но это может быть что угодно, даже идентификатор сеанса или весь профиль пользователя. (Пожалуйста, не делайте этого) Он имеет безопасную подпись, которая не позволяет злоумышленникам генерировать поддельные токены (вам нужен доступ к закрытому ключу сервера, чтобы подписать их, и вы можете убедиться, что они не были изменены после того, как были подписаны). отправляйте их с каждым запросом, точно так же, как Authorizationотправляются куки или заголовок. На самом деле они обычно отправляются в HTTP- Authorizationзаголовке, но использование cookie тоже нормально.
Маркер подписан, и сервер может проверить его происхождение. Мы будем предполагать, что сервер доверяет своей способности безопасно подписывать (вы должны использовать стандартную библиотеку: не пытайтесь сделать это самостоятельно и должным образом защитите сервер)
Что касается безопасной транспортировки токена, то обычно ответ заключается в его отправке через зашифрованный канал, обычно httpS.
Что касается безопасного хранения токена в клиенте, вам необходимо убедиться, что злоумышленники не смогут добраться до него. Это (в основном) означает предотвращение того, чтобы JS с плохих веб-сайтов читал токен, чтобы отправить его им. Это смягчается с помощью тех же стратегий, которые используются для смягчения других видов XSS-атак.
Если вам нужно сделать JWT недействительными, определенно есть способы этого добиться. Сохранение эпохи для каждого пользователя только для пользователей, которые запросили, чтобы их «другие сеансы были завершены», - очень эффективный метод, который, вероятно, будет достаточно хорошим. Если приложению требуется признание недействительности сеанса, то идентификатор сеанса может поддерживаться таким же образом, и таблица «убитых токенов» может по-прежнему быть намного меньше, чем полная таблица пользователей (вам нужно только сохранить записи более новые, чем наибольшее допустимое время жизни токена.) Таким образом, возможность сделать токен недействительным частично сводит на нет преимущество сеансов на стороне клиента в том, что вам придется поддерживать это состояние уничтоженного сеанса. Скорее всего, это будет гораздо меньшая таблица, чем исходная таблица состояний сеанса, поэтому поиск по-прежнему более эффективен.
Еще одно преимущество использования токенов JWT заключается в том, что их достаточно легко реализовать с использованием библиотек, доступных, вероятно, на всех языках, которые вы можете ожидать от них. Он также полностью отделен от вашей первоначальной схемы аутентификации пользователя - если вы переходите на систему на основе отпечатков пальцев, вам не нужно вносить какие-либо изменения в схему управления сеансом.
Более тонкое преимущество: поскольку JWT может нести «информацию», и клиент может получить к ней доступ, теперь вы можете начать делать некоторые умные вещи. Например, напомните пользователю, что его сеанс истечет за несколько дней до выхода из системы, дав ему возможность повторно пройти аутентификацию на основе даты истечения срока действия в токене. Все, что вы можете себе представить.
Короче говоря: JWT отвечает на некоторые вопросы и недостатки других методов сеанса.
Хотя JWT не отвечает на другие вопросы, такие как безопасное хранение или транспортировка, он не представляет никаких новых проблем безопасности.
Вокруг JWT существует много негатива, но если вы реализуете ту же безопасность, что и для других типов аутентификации, все будет в порядке.
И последнее замечание: это также не файлы cookie против токенов. Файлы cookie - это механизм для хранения и передачи битов информации, а также их можно использовать для хранения и транспортировки токенов JWT.
Короткий ответ: нет.
Более длинная версия:
Я реализовал JWT для управления сеансом после прочтения этой рекомендации в документации GraphQL :
Реализация была действительно простой, так как лишь добавляла немного сложности. Однако через некоторое время я (как и вы) начал задаваться вопросом, в чем заключаются преимущества. Оказывается, что для JWT очень мало (или, возможно, вообще нет) в том, что касается управления сеансами, как подробно объясняется в этом сообщении в блоге:
Прекратите использовать JWT для сеансов
источник
Мои два цента, которые по пути добавляют некоторый контраст знаменитому сообщению в блоге joepie91.
Учитывая, что сегодняшние (и завтрашние) приложения являются (в основном) облачными.
Существует экономическая выгода от аутентификации JWT без сохранения состояния , которая масштабируется по мере масштабирования приложения:
облачные приложения несут расходы вместе с каждым вдохом .
Эта стоимость снижается, когда пользователям больше не нужно аутентифицироваться «в хранилище сеансов».
Обработка
Работа круглосуточного магазина сессий требует денег.
В мире K8S нельзя обойтись без решений на основе памяти, так как поды недолговечны.
Липкие сеансы не будут успешными по той же причине.
Хранение
Хранение данных стоит денег. хранение данных на SSD стоит еще дороже.
Операции, связанные с сеансом, должны выполняться быстро, поэтому оптический привод не подходит.
Ввод-вывод
Некоторые облачные провайдеры взимают деньги за ввод-вывод, связанный с дисками.
Пропускная способность
Некоторые облачные провайдеры взимают плату за сетевую активность между экземплярами серверов.
Это применимо, поскольку почти наверняка API и хранилище сеансов являются отдельными экземплярами.
Кластеризация хранилища сеансов
Стоимость еще больше увеличивает все вышеупомянутые затраты.
источник
У меня был аналогичный вопрос при выборе между JWT и токеном + кешем для аутентификации пользователя.
После прочтения этих статей мне стало ясно, что преимущества, которые обещает JWT, не опережают проблемы, которые он приносит. Таким образом, токен + кеш (Redis / Memcached) - это мой путь.
Заголовки аутентификации, JWT и сеансы - как выбрать правильный метод аутентификации для API
Методы аутентификации для API
Прекратите использовать jwt для сеансов
источник