Почему JWT разделен на три части, разделенные точками?

Question

Веб-токен JSON (JWT) разделен на три части в кодировке Base-64, которые объединяются точками ("."). Первые две части кодируют объекты JSON, первая из которых является заголовком, детализирующим алгоритм подписи и хеширования, а вторая содержит утверждения. Третий - это двоичные данные, которые являются самой подписью.

Мой вопрос: Почему JSON Web Token разделен на три отдельные части? гораздо проще закодировать их как один объект JSON, например, так (пример ниже неполный для краткости):

{
    "header": {
        "alg": "rsa"
    },
    "assertions": {
        "iss": "2019-10-09T12:34:56Z"
    },
    "sig": "qoewrhgoqiethgio3n5h325ijh3=="
}

Заявлено иначе: почему разработчики JWT не простопоместить все части JWT в один объект JSON, как показано выше?

Answer 1

ИМХО, это приведет к большему количеству проблем. Да, вы могли бы разобрать это хорошо, но как насчет проверки подписи?

Структура JWT равна <B64 String>.<B64 String>.<B64 String>. Подпись в основном 2 первых подписанных части. Маловероятно, что структура будет каким-либо образом изменена различными структурами.

Теперь рассмотрим JSON: во время сериализации и десериализации порядок элементов может измениться. Объекты {"a":1,"b":2} и {"b":2,"a":1} могут быть равны в javascript, но если вы их зафиксируете, они будут генерировать разные подписи.

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

В результате простое использование JSON

дает больше хлопот, чем преимуществ.

Answer 2

Подпись не может быть частью подписанного, поэтому она должна быть отдельной.

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

Отдельные подтверждения, отдельные объекты.

Answer 3

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

Заголовки не позволяют переводить строки

Помните, что основной сценарий использования JWT - использовать его в качестве значения cookie. Файлы cookie попадают в заголовки. Значения заголовка не поддерживают символы новой строки: каждая пара ключ / значение заголовка должна помещаться на одной строке.

Поэтому произвольный JSON не будет работать для чего-то, что должно быть передано в качестве значения заголовка в HTTP-запросе. .

Следовательно, требуется некоторая кодировка - именно поэтому base64 используется в первую очередь. Причина, по которой base64 часто появляется, заключается в том, что она преобразует любой большой двоичный объект или строку во что-то, что может быть надежно перенесено как простой ascii практически при любых обстоятельствах. Т.е. три «полезных нагрузки» в кодировке base64, разделенные точками (что не является допустимым символом в кодировке base64), в значительной степени гарантированно безопасно транспортируют и не мешают между любыми системами.

JSON не может дать одинаковые гарантии,Конечно, вы могли бы удалить символы новой строки (JSON игнорирует пробелы в любом случае), но кавычки все еще являются проблемой: они должны быть закодированы в URL, и, возможно, не в других обстоятельствах, хотя они, вероятно, будут в порядке вЗаголовки HTTP. В результате это просто становится еще одной «ошибкой», когда разработчик пытается реализовать ее впервые.

Я уверен, что есть и другие причины: это не полный список.