Json Web Token (JWT) - можно использовать для гарантии целостности тела HTTP?

Question

В Интернете много информации о JsonWebTokens, но не так много об ее использовании для подписи содержимого HTTP-сообщения.

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

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

Это единственный ресурс, который я пока нашел по этой теме: Целостность сообщений API с JSON Web Token (JWT). Заголовок многообещающий, но статья на самом деле не говорит, как это сделать, она просто показывает заинтересованность в этом.

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

Подробнее

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

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

Answer 1

Отказ от ответственности: я ни в коем случае не эксперт по безопасности.

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

• Открытый ключ, если асимметрично подписан
• Эмитент
• Аудитория
• Срок действия

и т. Д.

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

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