Base64, URL-кодирование и JWT: что это и как работает

Кодирование — не шифрование

Кодирование меняет запись данных так, чтобы они прошли через канал, принимающий только определённые символы. Отменить его может кто угодно, потому что ключ не используется. Шифрование тоже преобразует данные, но вернуть их может только владелец ключа. Хеш — это ещё одно: односторонний отпечаток, который невозможно обратить, как рассказано в руководстве Что такое хеш-функции.

Base64 и URL-кодирование — это кодирования. JWT обычно подписан, что доказывает, кто его выпустил и что он не изменён, но его содержимое лишь закодировано. Если значение должно оставаться секретным, ему нужно шифрование, а не один из этих форматов.

Как работает Base64

Base64 читает данные по три байта (24 бита) и делит их на четыре группы по шесть бит. Каждая группа — число от 0 до 63, которое записывается одним символом алфавита из 64 знаков: A–Z для 0–25, a–z для 26–51, 0–9 для 52–61, затем + и /. Слово «Man» показывает шаги:

Если длина входных данных не кратна трём, последняя группа дополняется и помечается заполнителем: один оставшийся байт даёт два символа и ==, два оставшихся байта — три символа и =. «Ma» превращается в TWE=, а «M» — в TQ==.

Поскольку каждые три байта становятся четырьмя символами, Base64 увеличивает данные примерно на треть, плюс переносы строк, которые добавляют некоторые форматы. Фото на 3 МБ, отправленное вложением в письме, передаётся как примерно 4 МБ текста, а изображение, встроенное в таблицу стилей как data-URL, весит примерно на треть больше файла.

Где встречается Base64

• Вложения электронной почты (MIME) — это текст Base64, разбитый на строки по 76 символов.
• Data-URL вида data:image/png;base64,iVBORw0… встраивают небольшой файл прямо в HTML или CSS.
• Базовая HTTP-аутентификация отправляет user:password в Base64 в заголовке Authorization. Это скрывает пароль лишь от беглого взгляда, поэтому безопасно только по HTTPS.
• Сертификаты и ключи в файлах PEM — это Base64 между строками -----BEGIN …----- и -----END …-----, разбитый по 64 символа.
• JSON и XML передают двоичные значения, например подпись или миниатюру, строками Base64, потому что двоичного типа в них нет.

Base64URL и заполнитель

Символы + и / стандартного Base64 имеют особое значение в URL и путях к файлам, поэтому второй алфавит, Base64URL, использует вместо них - и _. Обычно он также опускает заполнитель =, ведь декодер может вычислить длину сам. Base64URL используют JWT, многие API-токены и некоторые имена файлов. Чтобы превратить стандартный Base64 в Base64URL, замените + на -, / на _ и удалите = в конце; для обратного преобразования отмените замены и добавляйте =, пока длина не станет кратной четырём.

Процентное кодирование в URL

URL может содержать лишь ограниченный набор символов, и некоторые из них задают структуру адреса: / и ? отделяют путь и запрос, & и = разделяют параметры, # начинает фрагмент. Если значение содержит такой символ или что-либо за пределами ASCII, его кодируют в процентном виде: каждый байт его UTF-8-представления записывается как % и две шестнадцатеричные цифры. «café» становится caf%C3%A9, потому что é — это два байта C3 A9.

Буквы, цифры и - . _ ~ кодировать никогда не нужно. Чаще всего проблемы вызывают такие символы:

Кодируйте каждое значение отдельно, а затем собирайте URL. В JavaScript encodeURIComponent делает это для одного значения и кодирует также / ? & = #, а encodeURI предназначен для адреса целиком и оставляет эти символы как есть. Применение encodeURI к отдельному значению — частая причина сломанных строк запроса.

Плюсы, пробелы и двойное кодирование

HTML-формы отправляют поля в формате application/x-www-form-urlencoded, где пробел превращается в +. В общем синтаксисе URL + — просто знак плюс. Поэтому поиск «C++», отправленный как q=C++, приходит на сервер, декодирующий данные форм, как «C» с двумя пробелами; отправлять его нужно как q=C%2B%2B. Когда вы декодируете строку запроса вручную, сначала выясните, по какому правилу она была создана.

Двойное кодирование возникает, когда уже закодированное значение кодируют ещё раз: %20 превращается в %2520, потому что сам знак % становится %25. Если в URL встречается %25 и за ним две шестнадцатеричные цифры, где-то в цепочке кодирование выполнено дважды; декодируйте один раз и найдите лишний шаг.

Что внутри JWT

JSON Web Token (JWT) переносит утверждения (claims) — например, кто пользователь и до какого момента токен действителен — от системы, которая его выпускает, к системам, которые его принимают. Распространённая подписанная форма состоит из трёх частей Base64URL, разделённых точками: заголовка, полезной нагрузки и подписи. После декодирования первые две — обычный JSON:

Header:  {"alg": "HS256", "typ": "JWT"}
Payload: {"sub": "user-42", "role": "editor", "iat": 1767225600, "exp": 1767229200}

Стандарт (RFC 7519) определяет несколько зарегистрированных утверждений; приложения добавляют свои, как role выше.

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

Подписан — не значит засекречен: как проверяют JWT

Подпись вычисляется по заголовку и полезной нагрузке. В HS256 издатель и получатель используют общий секрет и HMAC с SHA-256. В RS256 или ES256 издатель подписывает закрытым ключом, а получатели проверяют соответствующим открытым ключом, поэтому сами создавать токены не могут.

Сервер, получивший токен, должен проверить подпись ожидаемым алгоритмом и ключом, а также exp, nbf, iss и aud, прежде чем доверять какому-либо утверждению. Простое декодирование, как в инструменте LeedyBox, всё это пропускает: оно показывает, что написано в токене, но не говорит, подлинный ли он. Библиотеки также должны отклонять алгоритм «none», означающий неподписанный токен, если неподписанные токены не предусмотрены. Когда скрыть нужно само содержимое, токен шифруют (JWE); тогда он состоит из пяти частей, которые нельзя прочитать без ключа.

Типичные проблемы и решения

Частые вопросы