Должен ли веб-токен jwt быть зашифрован?

Question

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

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

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

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

Итак, я расшифрую этот новый текст, когда получу этот токен доступа на сервере и расшифрую его.

Рекомендуется ли делать это таким образом, если я не хочу показывать пользователю некоторые значения, указанные в претензии (например, идентификатор пользователя)? Если нет, каковы альтернативы?

Answer 1

JWT ( RFC7519) - это просто компактный способ безопасной передачи претензий от эмитента аудитории через HTTP.

JWT может быть:

• подписано ( JWS - RFC7515)
• зашифрованный (JWE - RFC7516)
• подписанный, затем зашифрованный ( этот порядок настоятельно рекомендуется). Весь JWS является полезной нагрузкой JWE
• зашифровано и подписано.

Имеет смысл шифровать JWS, если вы хотите сохранить конфиденциальную информацию скрытой от носителя (клиента) или третьих лиц.

Реальные вопросы: аудитория поддерживает JWE? Если да, то какие алгоритмы поддерживаются?

Answer 2

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

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

Для этого есть стандарт: JWE

Answer 3

Токен содержит пользовательские данные и действует как временное хранилище. Хранить конфиденциальные данные в токене не рекомендуется.

На первом уровне вы должны сохранить имя пользователя и, возможно, роль или что-то в этом роде. Вы не должны включать пароли, поэтому их не нужно шифровать. Тем не менее, вы можете зашифровать его, если хотите.

Answer 4

Да, лучше всего использовать JSON Web Encryption (JWE) RFC , утверждения в JWT после его декодирования представляют собой обычный текст, поэтому, если пользователь потерял токен, конфиденциальная информация, такая как электронная почта, имя пользователя, права доступа, может быть видна. и может использоваться в качестве исходной информации для любой атаки.

Answer 5

Лучшие текущие практики JSON Web Token , RFC 8725 описывает, как правильно спроектировать реализацию JWT с нуля, но нет рекомендаций от авторитетного органа, такого как IEEE, W3C или IETF, относительно того, следует ли шифровать полезную нагрузку JWT.

Примечание. Если вы следуете веб-рекомендациям Google и Bing , вы отвечаете через безопасный транспорт, например HTTPS.

С точки зрения закрепления информации с сохранением состояния, такой как токен доступа к протоколу HTTP без отслеживания состояния, см. файлы cookie: Ограничить доступ к файлам cookie .

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