Как сервер узнает после того, как вы вошли в систему, что каждый последующий запрос действительно исходит от вас? Одним из популярных ответов является JSON Web Token или JWT, обычно произносится как «jot». Это небольшой подписанный фрагмент данных, который клиент отправляет с каждым запросом, и сервер может проверить его, не затрагивая базу данных.

Самый быстрый способ понять JWT — создать его, а затем попытаться сломать. Мы сделали это, используя только стандартную библиотеку Python для Python 3.13, и приведенный ниже результат получен в результате этого запуска. Этот код предназначен для обучения. В реальном приложении используйте хорошо поддерживаемую библиотеку, поскольку в деталях проверки легко ошибиться.

Что такое JWT?

JWT — это открытый стандарт, определенный в RFC 7519, для передачи утверждений между двумя сторонами в виде компактной строки. Утверждение — это просто утверждение, например «Идентификатор этого пользователя — 42». Поскольку токен подписан, получатель может подтвердить, кто его выдал и что никто его не изменял.

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

Как работает вход в JWT

1. Пользователь отправляет имя пользователя и пароль на конечную точку входа.
2. Сервер проверяет их и создает подписанный токен.
3. Клиент сохраняет токен.
4. Каждый последующий запрос включает его, обычно в заголовке: Authorization: Bearer <token>.
5. Сервер проверяет подпись и срок действия, затем считывает утверждения.

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

Три части JWT

JWT выглядит как произвольный текст, но это три раздела в кодировке Base64URL, разделенные точками. Вот один из них, который мы создали:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiI0MiIsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzkzNTAwMDAwLCJleHAiOjE3OTM1MDA5MDB9
.7YfUDH_T-iDh8bMmUT8mmKYwOstzT8Ty--DTTAmQGWM

Мы добавили разрывы строк, чтобы было легче читать. Расшифровка первых двух частей дает простой JSON:

Header:  {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"42","role":"user","iat":1793500000,"exp":1793500900}

Стандартные претензии

Вы также можете добавить собственные утверждения, например role. Время — это временные метки Unix в секундах. Полезная нагрузка должна быть небольшой, поскольку токен передается при каждом запросе.

Построй сам

Создание токена включает в себя кодирование двух частей JSON, а затем их подписание секретом с использованием HMAC-SHA256:

import base64, hashlib, hmac, json

SECRET = b"demo-secret-do-not-use-in-production"

def b64url(data):
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode()

def sign(message):
    return b64url(hmac.new(SECRET, message.encode(), hashlib.sha256).digest())

def create_token(payload):
    header = {"alg": "HS256", "typ": "JWT"}
    parts = [
        b64url(json.dumps(header, separators=(",", ":")).encode()),
        b64url(json.dumps(payload, separators=(",", ":")).encode()),
    ]
    message = ".".join(parts)
    return message + "." + sign(message)

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

def verify_token(token, now):
    header, payload, signature = token.split(".")
    expected = sign(header + "." + payload)
    if not hmac.compare_digest(signature, expected):
        raise ValueError("bad signature")
    claims = json.loads(b64url_decode(payload))
    if claims["exp"] < now:
        raise ValueError("token expired")
    return claims

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

Попробуйте вмешаться в это

Предположим, злоумышленник декодирует полезную нагрузку, меняет "role":"user" на "role":"admin", снова кодирует ее и сохраняет старую подпись. Мы попробовали это вместе с двумя другими атаками:

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

Подписано, не зашифровано

Это наиболее неправильно понимаемый момент в JWT. Наш поддельный токен был отклонен, однако его содержимое по-прежнему было прекрасно читаемо:

{"sub":"42","role":"admin","iat":1793500000,"exp":1793500900}

Base64URL — это кодировка, а не шифрование, и любой может отменить его вообще без ключа. Подпись не позволяет людям изменять данные, но не читать их. Поэтому никогда не помещайте пароли, номера карт или личные данные в полезные данные JWT. Если содержимое необходимо скрыть, используйте зашифрованные токены (JWE) или просто храните данные на сервере.

HS256 против RS256

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

JWT против сессий

JWT часто представляют как современную замену сеансов. На самом деле у каждого есть компромиссы:

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

Где хранить токены в браузере

Многие руководства по безопасности отдают предпочтение файлам cookie HttpOnly, Secure, SameSite для веб-приложений. Какой бы вариант вы ни выбрали, всегда используйте HTTPS. Чтобы отправить токен из JavaScript, ознакомьтесь с нашим руководством по API JavaScript Fetch.

Обновить токены

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

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

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

Распространенные ошибки безопасности

• Декодирование без проверки. Чтение полезных данных не делает их заслуживающими доверия. Всегда проверяйте подпись.
• Принятие любого алгоритма. Установите явный список разрешенных алгоритмов.
• Использование слабого секрета. Короткие секреты можно взломать в автономном режиме. Используйте длинное случайное значение и держите его вне контроля версий.
• Пропуск срока действия. Токены без exp могут работать вечно, если их украдут.
• Не проверять iss и aud. В противном случае токен, выданный для одного сервиса, может быть принят другим.
• Доверие к устаревшим утверждениям. Роль внутри токена может быть устаревшей до истечения срока ее действия.
• Токены журналирования. Любой, кто читает ваши журналы, может использовать их повторно.
• Не проверяем пути сбоя. Добавьте тесты для просроченных и измененных токенов, а также действительных. Наше руководство по тестированию API с помощью Postman может помочь.

Итоги

JWT — это подписанные данные, которым сервер может доверять без поиска, а не секретный контейнер и не автоматическое обновление через сеансы. Используйте короткий срок действия, проверяйте все с помощью поддерживаемой библиотеки и не допускайте попадания личных данных в полезную нагрузку. Чтобы убедиться в этом сами, запустите небольшой скрипт, подобный нашему, измените один символ токена и увидите, что проверка не удалась.

Часто задаваемые вопросы

Продолжайте учиться