Три части токена: header, payload, signature

Возьмите любой токен из вашего проекта — из лога, из DevTools, из теста — и присмотритесь. Между тремя кусками бессмысленной на вид латиницы стоят две точки. Это не украшение: точка — разделитель, а каждый кусок — base64url-закодированный JSON. Первое открытие, которое ждёт каждого новичка, звучит неприятно: второй кусок, payload, читается бесплатно, без ключей и без библиотек — любой декодер base64 справится за секунду. base64url — это не шифрование, а упаковка: способ перегнать произвольные байты в символы, безопасные для URL и заголовков. Шифрование превращает данные в мусор без ключа; кодирование — просто другая форма записи тех же данных. Весь токен целиком проходит перед глазами каждого, кто встретит его в пути: прокси, балансировщики, логи, системы аналитики. С этого факта начинается вся гигиена работы с JWT, и к концу урока вы соберёте токен руками, чтобы больше его не бояться.

Первый блок токена — заголовок, и устройство jwt начинается с него. Это маленький JSON вида {alg:HS256, typ:JWT}: поле alg объявляет алгоритм подписи, typ традиционно равен JWT. На первый взгляд — декорация, на деле — самый опасный байт токена: сервер читает alg до того, как проверит подпись, а библиотеки прошлых лет верили ему слепо. Отсюда историческая атака alg none: атакующий меняет алгоритм на none и выбрасывает подпись — некоторые реализации принимали такой токен как подписанный. Современный golang-jwt отвергает alg none на корню, но урок остался: алгоритм проверки нужно фиксировать явно, а не читать из токена. Второй гость заголовка — поле kid, идентификатор ключа: оно пригодится, когда ключей станет несколько и серверу придётся выбирать, каким именно проверять. Для HS256-токена, который собираем в этом курсе, header остаётся двухполевым, и это честно отражает его роль: паспорт, а не грузовой отсек.

Второй блок — payload, JSON с утверждениями о токене, по-английски claims. Часть имён закреплена стандартом RFC 7519: sub — о ком токен, exp — когда умирает, iat — когда выпущен, jti — уникальный номер. Поверх стандартных кладут свои: role, user_id, версия прав. Пока токен не проверен, это просто слова; после проверки подписи они становятся фактами, которым сервер верит без похода в базу — ведь факты написал и подписал он сам. Отсюда и граница доверия: claims описывают состояние на момент выпуска. Поменяли пользователю роль в базе — токен со старой ролью будет врать до истечения exp, и длинный срок жизни превращает payload в устаревающую копию профиля. Разбор каждого стандартного поля, типы в Go и правила выбора собственных полей — тема следующего урока, здесь достаточно каркаса: payload — это JSON, который читать может каждый, а верить ему можно только после подписи. Именно поэтому в нём живут идентификатор и роль, а не профиль целиком.

Третий блок — подпись, и это единственная часть, которую нельзя прочитать, только пересчитать. HMAC-SHA256 принимает два аргумента: сообщение и ключ. Сообщение — склейка header.payload ровно в том виде, в каком части едут в токене, байт в байт; ключ — секрет сервера. Подпись детерминирована: те же данные и тот же секрет дают тот же результат, поэтому проверка тривиальна — пересчитать и сравнить. А вот подделка упирается в стену: изменить один байт payload — и подпись разъедется, а пересчитать её без секрета невозможно, HMAC не позволяет восстановить ключ из известных пар «сообщение — подпись». Один нюанс, на котором ловят: сравнивать подписи обычным == опасно — сравнение байтов в Go останавливается на первом несовпадении, и по времени ответа можно выуживать правильные байты по одному. В стандартной библиотеке для этого есть hmac.Equal, сравнивающий за постоянное время; golang-jwt использует его внутри, но привычка запомнить стоит.

Проверим всё это экспериментом, который стоит прогнать руками хотя бы раз. Берём настоящий токен, декодируем payload, меняем роль с user на admin, кодируем обратно и оставляем подпись прежней. На вид токен неотличим от настоящего: три части, валидный base64url, осмысленные claims. Проверка развеивает иллюзию мгновенно: сервер пересчитывает HMAC от новых header и payload своим секретом, получает одну строку, сравнивает с приложенной — и видит несовпадение. golang-jwt вернёт ошибку ErrTokenSignatureInvalid, и это не исключение из правила, а правило в действии: подпись связывает конкретные байты конкретных частей с конкретным секретом. Заметьте, что декодирование при этом прошло успешно — прочитать подделанный payload смог бы кто угодно; провалилась именно проверка. Поэтому в боевых middleware решение принимают только по результату валидации, а не по внешнему виду токена.

Подделку мы отбили, но у атаки есть вторая дверь, и подпись её не закрывает: не править токен, а украсть целиком. Сценарии прозаичны — скрипт на взломанной странице вытаскивает токен из localStorage, токен оседает в логе прокси, ноутбук остался разблокированным. Атакующий не меняет ни байта: отправляет ваш токен как есть, и проверка сходится идеально, потому что целостность не нарушена. HMAC гарантирует, что содержимое не тронуто, но не доказывает, что предъявитель — владелец. Против кражи работают другие рычаги: TLS защищает путь, короткий exp сжимает окно жизни украденной копии, а место хранения определяет, достанет ли его чужой скрипт — этой теме посвящён урок про хранение токена на клиенте. Экстренный сценарий — отзыв по jti из урока про denylist: токен вычёркивается до истечения срока.

Закреплю и спорный тезис, который вы услышите на ревью: короткий exp — добродетель, а длинный — ошибка. Для access-токенов живого пользователя это правда: пятнадцать минут ограничивают ущерб и от кражи, и от устаревшей роли. Но граница проходит не по длине срока, а по цене ошибки: сервисный токен между двумя внутренними контейнерами живёт часами, потому что канал изолирован, владельца-человека нет, а перевыпуск каждые пять минут окупается только нервами. Правило, которым пользуюсь: срок пропорционален цене утечки минус стоимости отзыва. Отзыв в JWT не бесплатный — это отдельный механизм с хранилищем, и пока его в проекте нет, длинный exp остаётся заявкой на инцидент. К сервисным токенам и их компромиссам курс вернётся в отдельном уроке.

Остался вопрос, где именно токен путешествует. Стандартное место — заголовок Authorization со схемой Bearer: один заголовок, читается любым клиентом, не портит URL и не оседает в истории браузера, как query-параметр. Токен в URL — типовая ошибка: адрес с токеном попадает в логи серверов, прокси и закладки, и убрать его оттуда потом сложно. В cookie токен тоже встречается — для веб-интерфейсов это рабочий вариант со своими нюансами защиты от CSRF, до которых курс доберётся в уроке про HttpOnly cookie. Ещё одно практическое ограничение — размер: заголовки HTTP измеряются килобайтами, и раздутый payload с корзиной и настройками упрётся в предел раньше, чем вы заметите. Отсюда бытовая норма: токен — десятки-сотни байт, не больше. Если хочется носить больше данных, это сигнал, что часть их должна жить на сервере.