Проверка exp и nbf

В стандарте JSON Web Token (JWT) временные ограничения являются ключевым механизмом защиты токена от повторного использования и преждевременной активации. В библиотеке Jsrsasign проверка этих параметров реализуется через встроенные функции валидации, которые учитывают системное время и значения полей exp и nbf.

Поле exp (expiration time) определяет момент, после которого токен считается недействительным. Поле nbf (not before) задаёт момент, ранее которого токен не должен приниматься системой. Оба значения представлены в формате Unix timestamp (секунды с 1 января 1970 года UTC).

Логика проверки exp

При валидации JWT библиотека Jsrsasign сравнивает текущее время с полем exp.

Если текущее время больше или равно значению exp, токен считается истёкшим и отклоняется.

Пример структуры payload:

{
  "sub": "user123",
  "iat": 1710000000,
  "exp": 1710003600
}

В этом случае токен действителен только в течение одного часа после создания.

Ключевой момент заключается в том, что проверка exp всегда выполняется в сравнении с текущим временем системы, а не временем создания токена.

Логика проверки nbf

Поле nbf используется для ограничения преждевременного использования токена.

Если текущее время меньше значения nbf, токен считается ещё не активным.

Пример payload:

{
  "sub": "user123",
  "nbf": 1710000000,
  "exp": 1710003600
}

Такой токен не может быть использован до наступления времени nbf, даже если он корректно подписан и не истёк.

Совместная работа exp и nbf

В реальных сценариях оба поля используются одновременно, образуя временное окно валидности токена:

{
  "sub": "user123",
  "nbf": 1710000000,
  "exp": 1710007200
}

Токен считается валидным только в интервале:

nbf ≤ current_time < exp

Любое нарушение этого условия приводит к отклонению токена при проверке.

Проверка через Jsrsasign

В Jsrsasign чаще всего используется функция KJUR.jws.JWS.verifyJWT, которая автоматически учитывает exp и nbf, если включена соответствующая опция проверки времени.

Пример базовой проверки:

const isValid = KJUR.jws.JWS.verifyJWT(token, publicKey, {
  alg: ["RS256"]
});

Для более строгого контроля времени используется параметр verifyAt:

const result = KJUR.jws.JWS.verifyJWT(token, publicKey, {
  alg: ["RS256"],
  verifyAt: KJUR.jws.IntDate.get("now")
});

При этом библиотека самостоятельно извлекает exp и nbf из payload и сравнивает их с заданным временем проверки.

Поведение при отсутствии exp или nbf

Если поле exp отсутствует, токен считается бессрочным с точки зрения времени окончания, что на практике нежелательно в системах с безопасной архитектурой.

Если отсутствует nbf, токен становится действительным сразу после выдачи, без задержки активации.

Jsrsasign не требует обязательного наличия этих полей, но логика безопасности приложения обычно предполагает их использование.

Граничные случаи проверки времени

При работе с exp и nbf важно учитывать несколько особенностей:

  • Время всегда интерпретируется в UTC
  • Значения должны быть в секундах, а не миллисекундах
  • Возможна небольшая рассинхронизация системного времени клиента и сервера
  • При необходимости допускается введение временного сдвига (clock skew tolerance)

Пример учёта допуска времени:

KJUR.jws.JWS.verifyJWT(token, publicKey, {
  alg: ["RS256"],
  verifyAt: KJUR.jws.IntDate.get("now") + 30
});

Здесь добавляется 30 секунд допустимого смещения.

Типичные ошибки при работе с exp и nbf

На практике часто встречаются следующие проблемы:

Неверный формат времени Использование миллисекунд вместо секунд приводит к мгновенному истечению токена.

Несинхронизированные часы сервера Даже корректный токен может быть отклонён, если системное время отличается от времени, использованного при генерации.

Отсутствие nbf при отложенной активации Токен становится активным сразу, что нарушает ожидаемую бизнес-логику.

Слишком большой срок действия exp Долгоживущие токены увеличивают риск компрометации.

Взаимодействие с подписью JWT

Проверка exp и nbf выполняется только после успешной проверки подписи токена. Это означает, что даже если временные параметры корректны, но подпись невалидна, токен будет отклонён раньше этапа проверки времени.

Последовательность проверки в Jsrsasign:

  1. Проверка криптографической подписи
  2. Разбор payload
  3. Проверка nbf
  4. Проверка exp

Использование IntDate в Jsrsasign

Для работы с временными значениями библиотека предоставляет утилиту KJUR.jws.IntDate, которая позволяет преобразовывать и получать текущее время в формате JWT:

const now = KJUR.jws.IntDate.get("now");

Также можно задавать смещения:

const future = KJUR.jws.IntDate.get("now + 3600");

Эти значения часто используются при формировании exp и nbf.

Роль exp и nbf в безопасности JWT

Комбинация exp и nbf формирует временную модель доверия к токену. Она позволяет:

  • ограничивать срок жизни токена
  • предотвращать преждевременное использование
  • синхронизировать авторизацию с бизнес-логикой
  • снижать риск повторного использования перехваченных токенов

Эти параметры не являются формальной частью криптографической подписи, но критически влияют на реальную безопасность системы авторизации.

Оглавление