Почему срок действия вашего JWT истекает немедленно: опыт измеряется в секундах, а не в миллисекундах.

Выпущен в 10:00, срок действия истек в 10:00 — токен отклонен при первом использовании, и проблема не в часах сервера.

Токен, отклоненный при первом запросе, вызывает подозрение в перекосе на сервере, но прежде чем менять часы, проверьте необработанные утверждения. Если один компонент генерирует `exp` на основе миллисекундных часов, а другой сравнивает секунды NumericDate, значения различаются на три порядка. Никакая обычная регулировка синхронизации не объясняет этот разрыв.

Используйте одноразовый или отредактированный токен, поскольку токен на предъявителя является учетными данными. Декодер JWT ToolAcre считывает полезные данные, но намеренно не проверяет подписи. Скопируйте числовое утверждение времени в преобразователь меток времени только после сохранения исходного тестового приспособления и его предполагаемого срока службы.

Что говорит RFC 7519 — NumericDate как секунды с 1970-01-01T00:00:00Z, и почему это число, а не строка

В соседней опубликованной статье JWT уже указан важный контракт: `exp` NumericDate отсчитывает секунды от эпохи Unix. Повторение объяснений стандартов не принесет здесь никакой пользы. Практический вопрос заключается в том, соблюдает ли каждый производитель, сериализатор, верификатор и испытательное оборудование одну и ту же шкалу.

Ищите явный граничный код: миллисекундные часы, разделенные на секунды при выдаче, и сравнение секунд при проверке. Заявление должно оставаться числом, а не форматированной датой, используемой для арифметических вычислений. Читаемый человеком UTC — это диагностическая проекция, а не авторитетное представление токена.

Закрепите этот контракт в тестах эмитента и проверяющего с ненулевым значением. Тест с использованием нулевой эпохи не может определить, была ли какая-либо сторона разделена или умножена на тысячу.

Существующая статья JWT устанавливает секунды NumericDate; в этой статье этот факт применяется к отладке по истечении срока действия

Если проверяющий интерпретирует утверждение о действительных секундах как миллисекунды, дата приближается к 1970 и выглядит истекшей. Если издатель записывает текущее значение миллисекунды в поле, которое позже интерпретируется как секунды, срок действия выходит далеко за пределы предполагаемого срока службы или за пределы поддерживаемого библиотекой диапазона. Появление признака определяет, на какой стороне возникла ошибка весов.

Избегайте «исправления», которое принимает обе формы на основе количества цифр. Это превращает искаженные токены в постоянный альтернативный протокол и может скрыть регресс эмитента. Отклоняйте значения, которые нарушают контракт NumericDate приложения, исправляйте генерацию и добавляйте приспособления, которые отличают секунды от миллисекунд.

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

Декодируйте полезные данные, чтобы предоставить `exp`, `iat` и `nbf` как необработанные значения, прежде чем платформа преобразует их. Сравните `exp − iat` с предполагаемым временем жизни токена в секундах. Проверьте `nbf` отдельно; срок действия токена может быть еще не истек, но его нельзя использовать. Не делайте вывод о подлинности, исходя из разумно выглядящих времен.

Декодер ToolAcre сообщает, что проверка подписи является ложной, поэтому его выходные данные относятся к отладке, а не к авторизации. Измененная полезная нагрузка может содержать любой срок действия, выбранный злоумышленником. Верификатор доверенного приложения по-прежнему должен обеспечивать соблюдение политики алгоритма, ключа, эмитента, аудитории и времени для исходного компактного токена.

Рабочий пример: выражение 1700003600 — преобразование его в UTC и местное время, сверка его с iat и подтверждение того, что время жизни соответствует вашему замыслу.

Для `iat = 1,700,000,000` и `exp = 1,700,003,600` вычитание дает 3,600 секунд или один час. Преобразователь явно считывает срок действия в секундах и возвращает `2023-11-14T23:13:20.000Z`; время выпуска `2023-11-14T22:13:20.000Z`.

Эти цифры уникальны для диагностического примера в этой статье. Если выбор миллисекунд приводит к январскому показанию 1970, это ожидаемое свидетельство неправильного масштаба. Прежде чем прийти к выводу, что политика одного часа реализована правильно, убедитесь, что текущее время верификатора также выражается в секундах.

Разница в один час вычисляется перед форматированием, поэтому в каждой зоне она остается по одному часу. Локальные дисплеи могут отличаться, но `exp − iat` — нет.

Рабочий пример: сравнить exp 1,700,003,600 с ближайшим iat, используя явные секунды.

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

Толерантность должна оставаться незначительной по сравнению с тысячекратным коэффициентом. Расширение его до тех пор, пока не будет принято неправильное утверждение, ослабляет соблюдение срока действия и оставляет ошибку эмитента в силе. Сначала нормализуйте тактовые единицы и синхронизацию; затем решите, соответствует ли ограниченное разрешение модели угроз приложения.

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

Допуск не может исправить несоответствие с коэффициентом 1,000.

Преобразование метки времени не может проверить подпись токена, разрешенный алгоритм, ключ, эмитента или аудиторию. Даже идеально отформатированное будущее утверждение `exp` может находиться внутри поддельного токена. Декодер JWT намеренно прозрачен в отношении этой границы и должен быть связан с доверенным верификатором.

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

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

Вывод: exp — это десять цифр, а не тринадцать, и как декодер JWT и конвертер временных меток Unix находятся на одной вкладке, поэтому вы можете проверить заявку за считанные секунды.

Рассматривайте заявки на время JWT как секунды на каждой границе и проверяйте их различия как длительности. Преобразователь временных меток преобразует отдельное утверждение в UTC и локальный контекст; декодер JWT предоставляет необработанное число. Вместе они объясняют время, не претендуя на доверие.

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

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