Схема токена в Iron представляет собой слой структурного описания зашифрованного (sealed) объекта, который определяет, как именно интерпретируются поля внутри сериализованного представления. При работе с долговечными токенами это критически важно, поскольку изменение алгоритмов шифрования, параметров целостности или структуры полезной нагрузки неизбежно происходит по мере развития библиотеки.
В Iron sealed-объект не является «просто строкой шифротекста». Это составная структура, в которой одновременно присутствуют данные, параметры криптографических преобразований и служебные поля, необходимые для восстановления исходного объекта.
Типичная структура включает:
Любое изменение в этих компонентах потенциально ломает совместимость, поэтому вводится концепция версии схемы.
Версионирование позволяет отделить логическую модель токена от конкретной реализации криптографического стека. Это решает несколько задач:
Без версии система была бы вынуждена угадывать формат токена, анализируя структуру эвристически, что недопустимо в криптографическом контексте.
В Iron sealed payload концептуально делится на две зоны:
Данные приложения Сериализованный объект, который требуется защитить. Обычно JSON-подобная структура.
Криптографический контейнер Служебные поля, описывающие:
Версия схемы влияет на то, как именно интерпретируется этот контейнер.
При восстановлении (unseal) токена первым шагом выполняется разбор сериализованной строки. Формат Iron использует компактное кодирование, где служебные данные кодируются в фиксированной или полуструктурированной последовательности.
Версия схемы может определяться:
Далее происходит ветвление логики:
Это исключает риск некорректной интерпретации данных.
Поддержка нескольких версий схемы одновременно — ключевая характеристика Iron при использовании в долгоживущих системах.
Реализуется это через набор декодеров:
При этом процесс выбора версии всегда детерминирован и не зависит от внешних параметров, кроме самой строки токена.
Важно, что старая версия никогда не «догадывается» о структуре новой версии — несовместимые токены просто не проходят проверку.
При обновлении схемы токена в реальных системах используется несколько стратегий:
Система одновременно умеет:
Это обеспечивает плавную миграцию без принудительного сброса сессий.
После обновления схемы:
Это минимизирует влияние на пользователей.
Используется редко и только при критических изменениях безопасности:
Версия схемы может изменять не только формат, но и сам набор используемых алгоритмов:
Каждое такое изменение требует отдельной версии, поскольку влияет на результат криптографических операций.
Отсутствие версии или её некорректная реализация приводит к ряду проблем:
Особенно опасна ситуация, когда разные версии начинают частично пересекаться по формату, что может привести к ложному принятию невалидных токенов.
При обнаружении неподдерживаемой версии выполняется строгое завершение операции:
Это предотвращает атаки, основанные на подмене структуры токена или попытке эксплуатации несовместимости форматов.
Версия также влияет на способ сериализации:
Даже небольшие изменения в сериализации требуют отдельной версии, поскольку влияют на результат вычисления MAC.
В Iron версия схемы токена выступает не просто техническим маркером, а частью модели доверия:
Таким образом версия становится частью криптографического контракта между сторонами, а не просто метаданными.