Зачем включать заголовок и полезную нагрузку в токен JWT?

Question

Я уверен, что мне здесь не хватает чего-то очень простого, но я только начал изучать токены JWT для аутентификации, и, насколько я понимаю, структура токена JWT следующая:

Base64UrlEncode(Header) + '.' +  Base64UrlEncode(Payload) + '.' + CreateSignature(Header, Payload, Secret_Key)

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

Я запутался в том, почему вам нужна первая часть Base64UrlEncode(Header) + '.' + Base64UrlEncode(Payload) + '.', которая легко конвертируется обратно в обычный текст?

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

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

Что мне не хватает?

Answer 1

Подпись не содержит полезной нагрузки. Подпись может быть такой же простой, как код аутентификации сообщения (HMA C) ha sh (SHA256) jwt. Итак, если вы отправили только подпись, это будет работать как простой старый идентификатор сеанса, и серверу все равно придется сохранять состояние, что сводит на нет любые преимущества jwt.

Вы правы, jwt по умолчанию не зашифрован. Несмотря на то, что он закодирован с помощью base64, с точки зрения безопасности это просто текст и не должен содержать конфиденциальную (секретную) информацию. Единственная защита, которую обеспечивает подпись, заключается в том, что когда сервер получает ее обратно, он может убедиться, проверив подпись, что информация в jwt не была изменена на клиенте.

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

Однако при особых обстоятельствах вы можете по-прежнему хотите включить конфиденциальную информацию (ie. секреты), которую вы хотите получить обратно на сервер, но не хотите раскрывать клиенту. Для этого вы можете использовать зашифрованный файл jwt (jwe). Недостатком является то, что этот токен будет непрозрачным для клиента, и вам, вероятно, придется реализовать конечные точки приложения для получения всей необходимой информации.