Небезопасные JWT редко встречаются на практике? Должны ли они быть?

Question

Я планирую использовать JSON Web Tokens для нового веб-приложения, которое я разрабатываю в Angular 2. Так как я не использовал его, прежде чем я прочитал несколько руководств, чтобы понять, как это работает. В онлайн-ресурсе я читал, что незащищенные JWT редко встречаются на практике. мне было интересно, если подписание и шифрование добавляют какие-либо дополнительные преимущества в плане безопасности в следующем (общем) использовать случай:

Я разрабатываю приложение, которое производит ценовые карты/плакаты для компании, владеющой пару магазинов с бытовой электроникой , В основном, все пользователи отправляют формат карты цены и некоторые детали форматирования на бэкэнд. В результате PDF создается и возвращается backend для моего приложения.

Это простое приложение, которое имеет одну задачу (я бы заподозрил, что большинство веб-приложений похожи на это?). Зачем мне выполнять проверку (подпись) и безопасность (шифрование), если это приложение обслуживается через безопасное соединение TLS? Не было бы лишним и только сделать приложение медленнее? Или подписание и шифрование - это просто лучшая практика, которая должна быть реализована по возможности?

Answer 1

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

Классический метод присваивает случайный идентификатор токенам и ведет список выпущенных токенов, так как работают системы на основе сеанса.

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

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

Шифрование потребуется, только если вы хотите скрыть содержимое JWT на стороне клиента (канал защищен TLS), например, если содержит конфиденциальные данные. Претензии, подобные субъекту sub, срок годности exp или эмитент iss, как правило, не чувствительны