Безопасность JWT: как проверить токены и отзыв доступа в своём API

Декодирование подпись и авторизация

Декодирование читает данные, криптографическая проверка подтверждает подпись в заданной модели доверия, авторизация решает, что эта личность может делать. В обычном подписанном JWT payload не шифруется подписью. Поле role: admin, увиденное в декодере, ещё не является правом. В учебном тесте подпись корректна, но токен предназначен другому API: именно проверка audience должна остановить запрос.

Что задаётся на стороне сервера

На сервере заранее задайте допустимые алгоритмы, доверенный источник ключей, issuer, audience, тип токена и правила времени. Не берите доверенный URL ключей из непроверенного заголовка без собственной политики. Ожидания зависят от протокола приложения, поэтому не все claims обязательны одинаковым образом. Скачиваемая таблица помогает записать принятую политику, прежде чем запускать отрицательные сценарии.

claims = jwt.decode(token, key, algorithms=["HS256"],
    audience="api-a", issuer="https://issuer.example",
    options={"require": ["exp", "iss", "aud", "sub"]})
# Отдельно проверить право claims["sub"] на конкретный объект.

Первичные источники: RFC 8725: JWT Best Current Practices · OWASP: Session Management

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

Тестовые отрицательные сценарии

Проверьте отсутствие токена, повреждение подписи, истёкшее время, другой issuer, другой audience и неизвестный kid. Каждый случай должен использовать контролируемый тестовый issuer и известное ожидание. Не перебирайте секреты подписи. Добавьте успешный запрос с корректным токеном: если не работает ни один вариант, проблема может быть в стенде, а не в улучшившейся безопасности.

Как учитывать ротацию и ошибки

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

Первичные источники: RFC 8725: JWT Best Current Practices · OWASP: Session Management

Продолжить: IDOR и BOLA: как проверить доступ к чужим данным в своём API

Выход отзыв доступа и смена роли

Удалите тестового участника организации и проверьте старый access token, refresh и другие устройства. Заранее определите допустимое окно сохранения старых прав. Самодостаточный токен может оставаться криптографически корректным после выхода, если сервер не реализует отдельный отзыв. Обновление роли в интерфейсе не доказывает обновление серверных разрешений. Для чувствительных действий политика может требовать дополнительной проверки текущего членства.

Где хранить токен

Место хранения зависит от архитектуры. Доступный JavaScript токен связан с рисками XSS; автоматически отправляемая cookie требует анализа CSRF и параметров cookie. Нет одного универсального ответа для браузера, мобильного клиента и серверной интеграции. Используйте проверенные библиотеки и штатные механизмы сессий; это руководство не предлагает писать свою криптографию или передавать токен стороннему декодеру.

Первичные источники: RFC 8725: JWT Best Current Practices · OWASP: Session Management

Продолжить: Утечка .env .git или API-ключа: как закрыть доступ и проверить исправление

Почему корректный JWT не закрывает IDOR

После успешной проверки JWT запрос A к doc-b всё равно требует решения по объекту. Подпись не сообщает, принадлежит ли документ A и существует ли разрешённое приглашение. Проверки токена и IDOR должны иметь разные ожидания и доказательства. Если токен администратора используется вместо обычного тестового пользователя, межпользовательский сценарий может потерять смысл.

Как повторить проверку после исправления

После изменения проверяйте исходный отрицательный случай и контрольный положительный. Для Scantelio подготовьте поддерживаемый JWT-сценарий и ожидаемые claims там, где они нужны модулю. Неизвестные настройки нельзя объявлять проверенными. Зафиксируйте версию библиотеки и сборку; повторяйте сценарии при изменении issuer, ротации, refresh или модели членства.

Продолжить: Как добавить проверки безопасности в CI/CD и GitHub Actions

Воспроизводимые примеры и материалы

Проверено: guides-1 · Python 3.13.0 · PyJWT 2.15.1

Учебные данные — синтетические. Файлы не содержат действующих ключей или клиентской базы. Запускайте примеры только в собственной изолированной тестовой среде.

• jwt-matrix.csv — редактируемый шаблон
• Выполняемый JWT-стенд: PyJWT, случайный локальный ключ, восемь проверок

Протокол проверки примера: версии, действия и наблюдения

Вопросы и ответы

Автор и источники

Редакция Scantelio: методика и границы проверки. Проверка примера: 2026-11-02.

• RFC 8725: JWT Best Current Practices
• OWASP: Session Management