Подход JWT основан на передаче самодостаточного токена, содержащего
полезную нагрузку (payload), подписанную или зашифрованную. Основная
идея — минимизация серверного состояния за счёт хранения всей информации
внутри токена.
Iron (чаще всего реализуемый через механизм @hapi/iron)
строится иначе: это формат «запечатывания» данных (seal/unseal), где
объект сериализуется, шифруется и дополнительно защищается от подмены. В
отличие от JWT, формат не предназначен для стандартной
интероперабельности между множеством систем, а ориентирован на
безопасное хранение и передачу данных внутри контролируемой
экосистемы.
Эти различия напрямую влияют на скорость обработки и размер итоговых
структур.
Размер токена и накладные
расходы
JWT: компактность за
счёт структуры Base64
JWT состоит из трёх частей:
Каждая часть кодируется в Base64URL, что увеличивает размер
относительно исходных данных примерно на 30–35%. Даже при минимальном
payload присутствует обязательный оверхед структуры:
- служебные поля алгоритма
- разделители
.
- подпись фиксированного размера (в зависимости от алгоритма)
Примерные характеристики:
- пустой payload уже даёт токен длиной ~100–150 символов
- при добавлении данных рост почти линейный, но с постоянным
оверхедом
- HMAC-SHA256 подпись добавляет фиксированный блок (~43 байта в
Base64)
Iron: упаковка + шифрование
+ метаданные
Iron-структура включает:
- сериализованный JSON
- симметричное шифрование (обычно AES)
- HMAC для целостности
- служебные данные для версии и параметров
Итоговый результат:
- минимальный размер выше, чем у JWT с тем же payload
- значительный криптографический оверхед (IV, salt, HMAC)
- Base64-представление увеличивает итог ещё на ~30%
На практике Iron-токен может быть на 20–80% больше JWT при одинаковом
содержимом, особенно на малых payload (до 1–2 KB), где криптографический
оверхед доминирует.
Влияние размера на
транспорт и кэширование
HTTP-заголовки
JWT часто передаётся в Authorization: Bearer, где размер
критичен. Рост даже на 200–300 байт может иметь значение при
высокочастотных запросах.
Iron-токены, будучи более тяжёлыми, увеличивают:
- нагрузку на сеть при каждом запросе
- размер логов и прокси-буферов
- вероятность упора в ограничения заголовков (например, в некоторых
балансировщиках)
Cookie-режим
Iron часто используется в cookie-сценариях. Здесь увеличение размера
особенно важно:
- браузеры ограничивают размер cookie (≈4KB на одну запись)
- несколько Iron-cookie могут быстро достичь лимита
- JWT обычно легче укладывается в лимиты при аналогичной нагрузке
Скорость генерации токена
JWT: дешёвая подпись
JWT с HMAC-SHA256 характеризуется высокой скоростью:
- одна хеш-функция на подпись
- отсутствие шифрования (в типичном сценарии)
- минимальная сериализация JSON
Производительность:
- создание токена: микросекунды до долей миллисекунды
- основная нагрузка — Base64 encoding
При RSA/ECDSA подписи скорость падает, но это уже специфика
алгоритма, а не формата.
Iron: криптографический
pipeline
Iron выполняет несколько последовательных операций:
- сериализация объекта
- генерация случайных значений (salt, IV)
- симметричное шифрование (AES-CBC / AES-GCM)
- вычисление HMAC
- финальная упаковка
Каждый шаг добавляет стоимость:
- AES операции существенно тяжелее HMAC
- генерация случайных чисел может быть узким местом в high-load
системах
- двойная криптография (шифрование + MAC) увеличивает
CPU-нагрузку
Итог:
- создание Iron-токена обычно медленнее JWT в 3–10 раз
- разница особенно заметна при массовой генерации (например,
batch-auth или SSR)
Скорость проверки и
декодирования
JWT: быстрый verify
Проверка JWT включает:
- Base64 decode
- пересчёт подписи
- сравнение HMAC
Операции линейны по размеру payload и крайне оптимизированы в
большинстве библиотек.
Характеристики:
- низкая задержка
- предсказуемая нагрузка
- возможность кеширования публичных ключей (для RSA/ECDSA)
Iron: дешифрование как
основная стоимость
Проверка Iron включает:
- Base64 decode
- извлечение параметров шифрования
- AES decrypt
- проверка HMAC
- парсинг JSON
Ключевая разница — необходимость дешифрования, которое:
- CPU-интенсивно
- зависит от размера payload
- не может быть «упрощено» как подпись JWT
Итог:
- проверка Iron медленнее JWT примерно в 2–8 раз
- при больших payload разрыв увеличивается
Масштабирование нагрузки
JWT
Сильные стороны:
- дешёвые операции verify
- отсутствие состояния на сервере
- горизонтальное масштабирование без синхронизации
Узкие места:
- большие payload увеличивают сеть и CPU на JSON parse
- RSA подписи могут стать bottleneck
Iron
Сильные стороны:
- высокая безопасность данных (шифрование по умолчанию)
- отсутствие необходимости в дополнительной логике защиты payload
Ограничения:
- CPU-bound операции
- рост затрат при увеличении RPS
- менее эффективен в stateless high-throughput системах
Сравнение влияния размера
payload
При малых данных (например, userId, role):
- JWT: минимальный рост
- Iron: криптографический оверхед доминирует
При средних payload (1–5 KB):
- JWT: линейный рост, относительно стабильная скорость
- Iron: рост времени дешифрования становится заметным
При больших payload (10 KB+):
- JWT: становится заметно тяжелым из-за Base64 + подпись
- Iron: резко увеличивается время decrypt + serialization cost
Криптографическая
стоимость операций
JWT (HMAC-SHA256)
- O(n), где n — размер payload
- отсутствие блочных операций
- высокая оптимизация CPU инструкциями
Iron (AES + HMAC)
- AES: блочное шифрование (128-bit blocks)
- HMAC поверх ciphertext
- дополнительные буферы памяти
Фактически:
- больше CPU cache misses
- больше memory allocations
- более сложный pipeline
Практическое
поведение в реальных системах
В типичных backend-системах наблюдаются следующие закономерности:
- JWT лучше масштабируется при большом количестве запросов
- Iron стабильнее с точки зрения безопасности данных payload
- JWT выигрывает в latency-critical API
- Iron выигрывает в сценариях хранения чувствительных данных в
клиентском слое
Нагрузочные сценарии
Высокочастотная авторизация
API
- JWT: низкая задержка, минимальная CPU нагрузка
- Iron: заметное увеличение CPU utilization
SSR / server-side rendering
- JWT: быстро декодируется на каждом запросе
- Iron: может стать узким местом при параллельной дешифровке
Edge-сценарии
- JWT: предпочтителен
- Iron: ограничен из-за CPU стоимости
Итоговые различия в метриках
- Размер токена: Iron > JWT
- Скорость генерации: JWT быстрее
- Скорость проверки: JWT быстрее
- Криптографическая сложность: Iron выше
- CPU нагрузка: Iron выше
- Масштабируемость: JWT эффективнее при высоком RPS