JSON Web Token - почему полезная нагрузка общедоступна?

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

Зачем?

Кажется, было бы гораздо полезнее зашифровать его с помощью секрета.

Может кто-нибудь объяснить, почему или в какой ситуации полезно хранить эти данные?

— мне нужна помощь
источник

когда вы пишете JWT, вы, вероятно, имеете в виду JWS. Потому что JWE (который также является «подклассом» JWT) фактически шифрует его содержимое.

— Алексей

Ответы:

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

Что вам больше всего нужно защищать, так это то, что люди вмешиваются в данные, чтобы обновлять неправильную запись, или чей-то текущий счет получает деньги, которых у нее не должно быть. Подпись JSON Web Token обеспечивает это, поскольку изменение любой части комбинации заголовок / полезная нагрузка / подпись делает пакет недействительным.

Обратите внимание, что вы все еще можете защитить пакеты на транспортном уровне с помощью SSL.

— Роберт Харви
источник

Ах, я вижу, по сути, JWT - это новый токен CSRF. Спасибо за ваше объяснение, это очистило путаницу.

— ineedhelp

Нет, JWT не является новым токеном CSRF. Это две разные вещи.

— Пепел

@ash, если подробности операции хранятся в JWT и проверяются на сервере, разве JWT по сути не играет роль предотвращения CSRF в этом сценарии? Я понимаю, что основной целью ванильного JWT является аутентификация, что очень ясно из этого ответа. Я думаю, что представлял себе, как добавить больше данных и выполнить две вещи одновременно.

— Inedhelp

@RobertHarvey, вы используете JWT неправильно. JST является «зонтичным» термином для JWS и JWE. JWS для аутентификации, JWE для шифрования. Таким образом, «целью JSON Web Token является аутентификация» на самом деле должно быть «JWS - аутентификация».

— Алексей

@ Алексей: я внес небольшое изменение в свой ответ, чтобы приспособиться.

— Роберт Харви,

Использование термина подпись в RFC аналогично цифровой подписи в асимметричной криптографии. В асимметричной криптографии, если отправитель шифрует сообщение своим закрытым ключом, любой, у кого есть сообщение, может расшифровать его с помощью открытого ключа отправителя. Таким образом, цель термина « подпись» состоит не в том, чтобы сохранить секретность сообщения, а в том, чтобы проверить целостность / отправителя сообщения, то есть это не было изменено.

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

И, как упомянул @Robert, JWT могут / должны быть зашифрованы с помощью TLS.

Вот хорошее объяснение JWT и подписей, из которых получено изображение ниже. 5 простых шагов для понимания веб-токенов JSON (JWT)

— Мика Б.
источник

Чтобы добавить к ответу Роберта Харвиса, есть существенный недостаток шифрования полезной нагрузки - это означает, что получатель службы должен поделиться секретом с сервером аутентификации (ключом шифрования), чтобы понять, авторизован ли носитель токена. или не. Напротив, любой может проверить JWT, используя только открытый ключ, опубликованный сервером аутентификации.

Это ключевая часть спецификации openid connect, поскольку она позволяет клиентским приложениям проверять токены идентификации, выданные сервером аутентификации, а также упрощает развертывание серверов ресурсов (поскольку их не нужно развертывать с доступом к секретному шифрованию). ключ), а также помогает при попытке диагностировать любые проблемы с выданным JWT.

— Джастин
источник

Вы пытаетесь сравнить асимметричные и симметричные механизмы шифрования, jwt - это реализация шифрования RSA.

— TheAnimatrix