В прошлом посте мы остановились на том, что Stateless-токен - это "пакет" с данными, который клиент носит с собой, а сервер только проверяет его подлинность. Сегодня разберем этот "пакет" по кирпичикам и подсветим места, где инженер должен бить тревогу, глядя на дизайн системы.
🟠 Из чего сделан JWT
JWT выглядит как три длинные строки в Base64, разделенные точками:
eyJhbGciOi... .eyJzdWIiOi... .SflKxwRJS...Это
Header . Payload . Signature〰️ Header — метаданные. «Я — JWT, подписан алгоритмом HS256». Тут же может лежать ссылка на ключ (
kid), если их несколько.〰️ Payload — смысловая часть. Здесь лежат claims (заявки/утверждения). Стандартные:
sub (идентификатор субъекта), exp (время истечения), iat (время создания). И кастомные: role, userId, permissions.〰️ Signature — криптографическая подпись. Сервер берет Header + Точка + Payload, прогоняет через алгоритм (HS256/RS256/ES256) с секретным ключом, и получает хеш. Это — "печать", доказывающая, что payload не меняли.
🔴 Разрушаем главный миф: JWT - это НЕ шифрование
Это самое важное, что мы должны понимать, глядя на JWT.
Base64Url — это кодирование, а не шифрование. Любой, кто перехватил токен, может раскодировать Header и Payload и прочитать их как обычный текст. Прямо в браузере, через
atob().Поэтому:
🔺 Никогда не кладите в payload чувствительные данные (пароли, номера паспортов, полные данные карты).
🔺 Даже внутренние идентификаторы, которые кажутся безобидными (например, internal_user_seq_id), могут раскрыть лишнее конкурентам или злоумышленникам.
🔺 Signature защищает только от подделки, но не от чтения. Это как открытка в прозрачном конверте: все видят текст, но никто не может изменить его, не разорвав печать.