JWT (JSON Web Token) — компактный формат для передачи подписанных данных, чаще всего информации об аутентифицированном пользователе. Токен состоит из трёх частей, разделённых точками: header.payload.signature. Для рунет-разработчика есть отдельный практический нюанс — что происходит, когда в payload попадает кириллица.
Кириллица в claims: имя, e-mail, роль
Payload вида {"name": "Иван Петров", "role": "администратор"} кодируется в Base64URL точно так же, как латиница, — JSON сам по себе хранит текст в Unicode, а Base64URL просто кодирует байты UTF-8. Разница в другом: закодированная строка с кириллицей заметно длиннее эквивалентной по смыслу строки на латинице, потому что каждый кириллический символ в UTF-8 занимает 2 байта против 1 байта для ASCII. Для токена, который передаётся в каждом HTTP-заголовке запроса, это ощутимая прибавка к объёму трафика при большом количестве запросов.
Три части токена
- Header — JSON с типом токена и алгоритмом подписи (например, HS256 или RS256), закодированный в Base64URL.
- Payload — JSON с «claims»: данными о пользователе, времени выдачи, сроке действия и т.д., тоже в Base64URL.
- Signature — подпись, вычисленная над header и payload с помощью секретного или приватного ключа, подтверждающая неизменность токена.
Экосистема PHP и 1С-интеграций
В рунете JWT чаще всего встречается в связке с Laravel/Symfony на бэкенде и в интеграциях с 1С или внутренними корпоративными API, где токен нередко несёт не только имя пользователя, но и внутренний код подразделения или роль из корпоративного справочника. Именно в таких сценариях легко забыть, что декодирование токена на фронтенде — это просто чтение JSON, а не проверка того, что роль администратора в payload действительно была выдана сервером, а не подделана.
Важное отличие: декодирование ≠ проверка
Header и payload — это просто Base64URL, то есть любой может декодировать их и прочитать содержимое без какого-либо ключа. Декодирование токена не доказывает, что данные не подделаны. Доверять содержимому токена можно только после проверки подписи (signature) с помощью соответствующего ключа — и именно эту проверку выполняет сервер.
Опасная атака: подмена алгоритма на «none»
Спецификация JWT допускает алгоритм none — токен без подписи. Если бекенд наивно доверяет полю alg из заголовка токена вместо того, чтобы проверять подпись фиксированным, заранее известным алгоритмом, злоумышленник может подменить alg на none, убрать подпись — и токен пройдёт проверку с произвольными данными. Надёжные библиотеки JWT требуют явно указать ожидаемый алгоритм при верификации именно для защиты от этой атаки.