В библиотеке Iron модель «токена» реализуется через механизм шифрования и подписи произвольного объекта, который затем может быть безопасно передан клиенту и восстановлен на сервере. Такой объект называют «запечатанным» (sealed value). В отличие от классических JWT, здесь нет строгого формата токена — вместо этого используется сериализованный и зашифрованный payload с метаданными, включая время создания и срок действия.
Ключевым параметром, определяющим жизненный цикл защищённого
значения, является ttl (time to live), который задаётся при
создании токена.
При создании защищённого значения через Iron.seal()
можно указать параметр времени жизни:
ttlSec — время жизни в секундахВнутри зашифрованной структуры сохраняется момент создания токена.
При последующей расшифровке через Iron.unseal() библиотека
вычисляет разницу между текущим временем и временем создания.
Если текущее время превышает ttl, операция распаковки
завершится ошибкой, даже если криптографическая целостность данных не
нарушена.
t_{exp} = t_{created} + ttl
Где:
t_created — время создания токенаttl — допустимый срок жизниt_exp — момент истеченияПроверка срока жизни выполняется на этапе unseal, а не
при создании. Это означает:
Дополнительно учитывается возможное расхождение системного времени. Поэтому в реальных системах важно синхронизировать часы (NTP), иначе возможны ложные истечения или принятие просроченных токенов.
Внутри sealed-значения хранится служебный блок данных, содержащий:
Эти данные защищены криптографически и недоступны для прямого изменения без нарушения подписи.
С точки зрения логики срока жизни важны именно временные метки, поскольку именно они определяют валидность токена.
При вызове Iron.unseal() происходит последовательность
проверок:
ttlЕсли срок превышен, библиотека выбрасывает ошибку истечения.
Типичная ошибка:
Token expiredЭто поведение делает невозможным использование устаревших токенов даже при их перехвате.
В Iron нет встроенного механизма «refresh token» в классическом понимании OAuth. Обновление реализуется на уровне прикладной логики.
Существует несколько распространённых стратегий.
Наиболее прямой подход — создание нового sealed-значения при каждом обновлении сессии.
Процесс:
ttlЭтот подход обеспечивает простую модель безопасности, но требует дополнительной логики на сервере.
Часто применяется механизм «скользящего TTL», при котором срок жизни продлевается при каждом взаимодействии пользователя с системой.
Логика:
t_{new} = t_{now} + ttl
Такой подход позволяет поддерживать активные сессии без постоянного логина, но требует контроля частоты обновлений, чтобы избежать лишней генерации токенов.
Иногда вводится дополнительный слой логики:
Это позволяет обновлять токен не только по времени, но и по состоянию пользователя.
Важно понимать, что в Iron невозможно «изменить TTL» у уже созданного токена. Любая попытка обновления фактически означает:
Это принципиальное отличие от систем, где токен хранится в базе и может быть модифицирован.
При проектировании системы обновления срока жизни необходимо учитывать несколько факторов:
Если старый токен остаётся валидным после обновления, возникает риск replay-атаки. Поэтому часто применяется стратегия:
При обновлении токенов важно учитывать сетевые задержки:
Для этого вводится кратковременное пересечение валидности.
Так как TTL зависит от времени, система уязвима к:
Поэтому критически важно, чтобы проверка времени происходила только на серверной стороне.
Жизненный цикл sealed-данных в Iron можно представить как последовательность состояний:
Каждый цикл обновления полностью заменяет предыдущий экземпляр.
После истечения TTL токен становится недействительным независимо от:
Единственный способ восстановить доступ — создание нового sealed-значения с повторной авторизацией пользователя или использованием механизма refresh на уровне приложения.
Чрезмерное обновление токенов может привести к:
Поэтому часто вводятся пороги:
Такие ограничения позволяют балансировать между безопасностью и эффективностью.
Выбор срока жизни напрямую влияет на поведение системы:
В системах с Iron обычно применяются умеренные значения TTL с дополнительной логикой контроля активности.
Обновление токена в Iron всегда сводится к одному принципу:
Любые «изменения» токена являются фактически полной его пересборкой, а не модификацией.