Инструменты разработчика · Декодер JWT
Анатомия JWT: разделение по точкам и декодирование Base64url
· Как это работает
JWT кодирование безопасность
JWT — это три сегмента base64url, разделенные точками. В этом посте каждая часть декодируется вручную, объясняется, почему сегмент подписи не является текстом, и показано, что может и не может вам сказать декодер.
Длинная строка в заголовке авторизации — на что вы смотрите и почему именно две точки
Токен-носитель часто поступает в заголовок авторизации в виде компактной строки, разделенной точками. Типичный подписанный JWT в компактной форме JWS имеет три сегмента и, следовательно, две разделяющие точки. Активный токен — это учетные данные: не вставляйте производственные токены в демонстрационную версию.
Компактная сериализация — заголовок, полезные данные и подпись в виде трех сегментов base64url.
В компактной сериализации JWS первый сегмент — это защищенный заголовок, второй — полезная нагрузка, а третий — подпись или MAC. Подпись охватывает первые два закодированных сегмента, соединенные точкой. Разделение строки позволяет найти сегменты; он не может установить доверие.
Base64url без заполнения — алфавит, который использует JWS, и почему сегменты не имеют завершающих знаков равенства
Base64url использует - и _ вместо + и / в обычном Base64. В компактном JWS отсутствует завершающий = отступ; декодер может восстановить заполнение перед декодированием. Декодирование производит байты. Для заголовка и утверждений JSON декодируйте байты как UTF-8 перед анализом текста.
Заголовок — небольшой объект JSON, называющий алгоритм и, часто, ключ.
Заголовок обычно имеет вид JSON, содержащий alg, а иногда и идентификатор ключа, kid. Это утверждения, сделанные самим токеном. Верификатор должен применять свою собственную политику разрешенного алгоритма и безопасно получать соответствующий ключ; чтение только alg не является авторизацией.
Полезная нагрузка — объект утверждений JSON, доступный для чтения любому, у кого есть токен.
Полезная нагрузка содержит такие утверждения, как sub, exp и aud. Любой, у кого есть жетон, может их прочитать; кодирование не является шифрованием. Ex NumericDate отсчитывает секунды с эпохи Unix, но непроверенное утверждение не имеет авторитета. Не храните секреты в читаемой полезной нагрузке.
Подпись — необработанные байты в первых двух сегментах, бессмысленные как текст и бесполезные без ключа.
Последний сегмент — это байты подписи, закодированные в base64url, а не третий объект JSON. Для его проверки требуется криптографический алгоритм, ключ и политика приложения. ToolAcre намеренно не выполняет проверку: сообщает о наличии подписи и всегда помечает подписьVerified как ложную.
Рабочий пример — сегментное декодирование образца токена, включая появившийся JSON.
Возьмите неконфиденциальный демонстрационный заголовок {"alg":"HS256","typ":"JWT"} и полезную нагрузку {"sub":"demo"}. Их кодировки base64url: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 и eyJzdWIiOiJkZW1vIn0. Декодирование восстанавливает JSON. Добавление произвольного третьего сегмента не делает токен аутентичным.
Вывод: декодирование — это чтение, а не доверие — декодер ToolAcre JWT показывает заголовок и полезную нагрузку и никогда не проверяет подпись, поэтому ничто из того, что он показывает, не доказывает подлинность токена.
Декодирование – это чтение, а не доверие. Используйте декодер ToolAcre JWT для заголовка, утверждений и предупреждений одноразового токена; используйте доверенный верификатор вашего приложения, чтобы решить, действителен ли подписанный токен. Только отображаемые утверждения никогда не должны предоставлять доступ.