Инструменты разработчика · Декодер JWT
Base64 против Base64url: почему JWT не работает в стандартном декодере Base64
· Как это работает
JWT base64 кодирование
Вставьте сегмент JWT в обычный декодер base64, и он может жаловаться на символы или заполнение. В этом посте объясняются требования варианта base64url JWS и способы преобразования между ними.
Недопустимый символ, неправильное заполнение — ошибки, возникающие при совпадении base64 с base64url.
Сообщение «недопустимый символ» или «неправильное заполнение» часто означает, что сегмент JWT был передан декодеру, который ожидает обычный Base64. Токен может быть скопирован правильно. Его представление соответствует соглашениям base64url, в то время как принимающая утилита принимает родственный, но не идентичный алфавит или настаивает на явном заполнении.
ToolAcre позволяет избежать несоответствия заголовка и полезных данных. Его декодер байтов удаляет пробелы, преобразует безопасные для URL символы, восстанавливает пропущенные дополнения, когда это позволяет длина, а затем преобразует байты в строгие UTF-8. Сбой на любом этапе становится ошибкой INVALID_JWT, а не обычным исключением браузера.
Два алфавита — плюс и косая черта вместо дефиса и подчеркивания, и почему URL-адреса заставили это изменить
Стандартный Base64 использует плюс и косую черту для обозначения двух последних позиций алфавита. Base64url присваивает этим же позициям дефис и подчеркивание. Базовые шестибитные значения не изменяются, поэтому преобразование `-` в `+` и `_` в `/` сохраняет каждый декодированный байт; меняется только транспортно-безопасное написание.
Эти замены имеют значение в каналах, где плюс или косая черта уже имеют синтаксис. Безопасное написание URL снижает вероятность случайной интерпретации при обработке формы или пути. Это не добавляет секретности, целостности или аутентичности. Любой, кто получит сегмент, может отменить замены и восстановить те же байты без криптографического ключа.
Заполнение — почему JWS удаляет знаки равенства и как их восстановить для строгого декодера
ToolAcre допускает пропущенное дополнение. После нормализации алфавита он проверяет длину сегмента по модулю четыре. Для остатка двух нужны два знака равенства, а для остатка трех — один. Остаток единицы невозможен для полного значения Base64 и отклоняется как усеченная строка, а не угадывается в форме.
Восстановление заполнения — это механическое формирование, а не восстановление токена. Добавление знаков равенства не может восстановить символы, потерянные при копировании, а успешное декодирование байтов не показывает, что байты поступили от эмитента. Реализация просто восстанавливает каноническую длину, необходимую декодеру браузера перед вызовом `atob`.
Декодирование всего токена сразу — ошибка не разбить сначала на точки
Компактный подписанный токен должен быть разделен на точки перед декодированием любого сегмента. При передаче `header.payload.signature` в функцию Base64 вводятся точки, принадлежащие сериализации JWT, а не алфавиту Base64. ToolAcre требует ровно три сегмента для этого входного сигнала в форме JWS и сообщает наблюдаемое количество, когда эта структура отсутствует.
Случай из пяти частей получает отдельное сообщение JWE, поскольку зашифрованная компактная сериализация — это не один и тот же объект. Вместо этого две или четыре части предполагают усечение или неправильный ввод. Эта структурная проверка предшествует интерпретации JSON, что позволяет отличить ошибку копирования от неправильного закодированного текста или неправильного формата JSON.
Рабочий пример — преобразование одного сегмента из base64url в base64, заполнение его и декодирование в JSON.
Для сработавшего преобразования возьмите `eyJhbGciOiJIUzI1NiJ9`. Он не содержит символов алфавита, которые различаются в разных вариантах, но отсутствующие дополнения по-прежнему иллюстрируют конвейер. Его длина позволяет восстановить набивку; декодирование дает UTF-8 байт для `{"alg":"HS256"}`, а анализ JSON создает объект с одним свойством `alg`.
Сегмент, содержащий дефис или подчеркивание, следует той же последовательности, сначала с заменой двух символов. ToolAcre выполняет эти операции внутри `base64ToBytes`, затем `decodeSegment` анализирует полученный текст. Отображаемый алгоритм — это то, что объявлено в непроверенном заголовке; он не выбран в качестве политики проверки.
Юникод в заявках — почему декодированные байты нужно читать как UTF-8 для правильного отображения имен
Заявления могут содержать диакритические знаки, символы CJK или эмодзи. Base64 оперирует байтами, поэтому обработка каждого декодированного байта как независимого символа приводит к повреждению многобайтового текста. Правильный путь — это кодирование символов в байты, а затем декодер UTF-8. ToolAcre конструирует `TextDecoder` с фатальным режимом, поэтому недопустимый UTF-8 громко завершается сбоем.
Тесты охватывают полезную нагрузку, содержащую `Zoë 世界 🙂`, и ожидают точную строку после декодирования. Этот результат доказывает, что конвейер преобразования байтов в текст сохранил это тестовое значение. В нем по-прежнему ничего не говорится о том, существует ли человек, указанный в полезной нагрузке, утвердил ли эмитент заявку или был ли токен изменен.
Чего это не касается — сегмент подписи, который декодируется в байты, а не в текст, и ему нужен ключ, чтобы что-то означать.
Сегмент подписи находится за пределами пути JSON. ToolAcre сохраняет свою исходную закодированную форму и пытается измерить только длину декодированного байта. Неверная подпись Base64 выдает предупреждение, но не предотвращает проверку заголовка и полезной нагрузки; пустой третий сегмент выдает другое предупреждение о том, что байты подписи отсутствуют.
Ни один из результатов не является результатом проверки. Для значимой проверки подписи необходим надежный ключевой материал, разрешенный алгоритм, выбранный независимо от ввода, контролируемого злоумышленником, и проверки приложений. Подсчет байтов полезен при диагностике формы, но ноль или тридцать два измеренных байта не могут авторизовать запрос или установить отправителя.
Вывод: используйте декодер, который поддерживает base64url — декодер ToolAcre JWT обрабатывает алфавит и поля для заголовка и полезной нагрузки.
Используйте декодер, который понимает base64url, когда непосредственное задание проверяет JSON. ToolAcre обрабатывает алфавит, опущенное дополнение, строгий UTF-8 и только объектный JSON для первых двух сегментов. Он также отклоняет невозможные длины и оборачивает ошибки анализа в сообщения, которые определяют, произошел ли сбой заголовка или полезной нагрузки.
Остановитесь на этой границе. Чистое декодирование означает, что строка содержит восстанавливаемые байты и подходящие объекты JSON. Это не означает, что его заявления заслуживают доверия, аутентифицированы, авторизованы или неизменены. Только отдельно настроенный верификатор может ответить на эти вопросы, и этот инструмент браузера намеренно не выполняет операцию проверки.