Зарегистрированные claims: iss, sub, aud, exp, nbf, iat, jti

В спецификации JSON Web Token (JWT), на которой основана библиотека Jose, payload токена состоит из набора claims — утверждений о субъекте токена и его контексте. Часть этих claims относится к зарегистрированным (registered claims), определённым стандартом RFC 7519. Они имеют фиксированную семантику и используются для обеспечения совместимости, безопасности и корректной валидации токенов.

При работе с библиотекой Jose в JavaScript именно эти claims становятся основой проверки подлинности, срока действия и области применения токена.

iss (Issuer) — издатель токена

Claim iss определяет сущность, выпустившую токен. Это может быть сервер авторизации, микросервис или внешний провайдер идентификации.

Назначение

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

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

{
  "iss": "https://auth.example.com"
}

Проверка в Jose

В библиотеке Jose проверка issuer выполняется через указание ожидаемого значения:

import { jwtVerify } from 'jose';

const { payload } = await jwtVerify(token, key, {
  issuer: 'https://auth.example.com'
});

Если значение iss не совпадает, валидация завершится ошибкой.

sub (Subject) — субъект токена

Claim sub указывает на субъект, к которому относится токен. Чаще всего это идентификатор пользователя.

Назначение

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

Пример

{
  "sub": "user_12345"
}

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

В большинстве систем sub используется как primary key пользователя:

const userId = payload.sub;

aud (Audience) — аудитория токена

Claim aud определяет получателя токена — сервис или группу сервисов, для которых токен предназначен.

Назначение

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

Пример

{
  "aud": "payments-service"
}

Возможен также массив значений:

{
  "aud": ["service-a", "service-b"]
}

Проверка в Jose

await jwtVerify(token, key, {
  audience: 'payments-service'
});

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

exp (Expiration Time) — время истечения

Claim exp задаёт момент времени, после которого токен становится недействительным.

Формат

Unix timestamp (в секундах).

Назначение

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

Пример

{
  "exp": 1714740000
}

Проверка в Jose

await jwtVerify(token, key, {
  maxTokenAge: '1h'
});

Либо автоматическая проверка через jwtVerify, если exp присутствует.

nbf (Not Before) — не ранее чем

Claim nbf задаёт момент, до которого токен не считается действительным.

Назначение

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

Пример

{
  "nbf": 1714730000
}

Поведение

До указанного времени токен должен быть отклонён даже при корректной подписи.

iat (Issued At) — время выдачи

Claim iat фиксирует момент создания токена.

Назначение

  • аудит и логирование
  • проверка актуальности токена
  • вычисление срока жизни при отсутствии exp

Пример

{
  "iat": 1714720000
}

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

В связке с exp и nbf формирует временную модель токена.

jti (JWT ID) — уникальный идентификатор токена

Claim jti используется для уникальной идентификации каждого токена.

Назначение

  • предотвращение повторного использования (replay attacks)
  • возможность отзыва конкретного токена
  • трассировка в логах

Пример

{
  "jti": "7f9c2b1a-3d4e-4a0b-9f12-8a6d9c5e1f33"
}

Практическое применение

В системах с logout или blacklist:

const isRevoked = await redis.get(payload.jti);

if (isRevoked) {
  throw new Error('Token revoked');
}

Совместное использование зарегистрированных claims

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

{
  "iss": "https://auth.example.com",
  "sub": "user_123",
  "aud": "api-service",
  "exp": 1714740000,
  "nbf": 1714730000,
  "iat": 1714720000,
  "jti": "b6f1c2d0-8b9a-4c1d-9f2e-11c0d9a7e8b3"
}

Такой токен:

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

Особенности обработки claims в Jose

Библиотека Jose строго следует спецификации JWT и предоставляет встроенную валидацию:

  • iss, aud, sub проверяются через параметры jwtVerify
  • exp, nbf, iat проверяются автоматически при наличии
  • jti не валидируется библиотекой и требует пользовательской логики

Пример комплексной проверки:

await jwtVerify(token, key, {
  issuer: 'https://auth.example.com',
  audience: 'api-service'
});

Ошибки при работе с зарегистрированными claims

1. Несовпадение issuer

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

2. Неверная аудитория

Причина: попытка использовать токен в другом сервисе

3. Истёкший токен (exp)

Причина: истечение времени жизни

4. Токен ещё не активен (nbf)

Причина: преждевременное использование

5. Отсутствие iat

Причина: невозможность определить возраст токена

6. Повторное использование jti

Причина: replay attack или отсутствие blacklist-механизма

Роль registered claims в архитектуре безопасности

Registered claims формируют базовый слой доверия в JWT-системах:

  • iss — доверие к источнику
  • sub — идентификация субъекта
  • aud — ограничение области действия
  • exp — контроль времени жизни
  • nbf — управление активацией
  • iat — фиксация времени создания
  • jti — уникальность и отзыв

Их корректная комбинация обеспечивает предсказуемое поведение токенов в распределённых системах, где Jose выступает инструментом криптографической проверки и валидации.

Оглавление