Аутентификация: использование JWT против сеанса

Ответ 1

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

То, что люди часто имеют в виду, спрашивая: "В чем преимущества использования JWT с использованием сеансов на стороне сервера"

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

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

Перемещение сеанса к клиенту означает, что вы удаляете зависимость на сеансе на стороне сервера, но накладывает свой собственный набор проблем.
- Безопасное хранение маркера
- безопасное транспортирование
- Сеансы JWT могут иногда быть недействительными.
- Доверяя претензии клиента.

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

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

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

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

В связи с проблемой безопасной передачи токена обычно отправляется ответ через зашифрованный канал, обычно httpS.

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

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

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

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

Итак, кратко: JWTs отвечает на некоторые вопросы и недостатки других методов сеанса.
1. "Более дешевая" аутентификация, потому что вы можете устранить поездку в оба конца DB (или, по крайней мере, иметь гораздо меньшую таблицу для запроса!), Которая, в свою очередь, обеспечивает горизонтальную масштабируемость.
2. Заявки на клиентскую сторону, защищенные от несанкционированного доступа.

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

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

Последнее замечание: это также не Cookies против Tokens. Cookies - это механизм для хранения и транспортировки бит информации и может использоваться для хранения и транспортировки токенов JWT.

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

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