Токен JWT, сокращение от JSON Web Token, представляет собой компактный формат для передачи утверждений между двумя сторонами. Приложения часто используют JWT после входа в систему: сервер выдает токен, клиент отправляет его с последующими запросами, а API проверяет токен перед предоставлением доступа. JWT не является криптовалютным токеном, и его содержимое не является автоматически секретным.
Системы учетных записей в сфере финансов, бирж и сервисов Web3 могут использовать аутентификацию на основе токенов «за кулисами». Читатели, изучающие платформы цифровых активов, могут создать учетную запись Tapbit, в то время как разработчики должны относиться к каждому токену аутентификации как к учетным данным, чувствительным к безопасности.
Что такое токен JWT?
Стандарт JWT, RFC 7519, определяет компактный формат утверждений, предназначенный для передачи в виде объекта JSON. Утверждение — это заявление, такое как идентификатор пользователя, эмитент токена, предполагаемая аудитория или срок действия. JWT часто используются в качестве токенов доступа, токенов идентификации или краткосрочных сообщений между сервисами.
Люди часто говорят «токен JWT», хотя последняя «T» уже означает «токен» (token). Повторение является распространенным и безвредным. Важно понимать, что JWT описывает формат, а не полную систему входа. Безопасная аутентификация также требует правильной политики выдачи, проверки, хранения, истечения срока действия и отзыва.
Как работает JSON Web Token?
Типичный процесс входа начинается, когда пользователь отправляет действительные учетные данные. Сервер аутентификации создает JWT, содержащий выбранные утверждения, и защищает его цифровой подписью или кодом аутентификации сообщения. Затем клиент представляет JWT API, часто в заголовке HTTP Authorization с использованием схемы Bearer.
API проверяет подпись и проверяет необходимые утверждения, прежде чем доверять запросу. Важные проверки могут включать эмитент, аудиторию, срок действия и алгоритм, ожидаемый приложением. Если проверка прошла успешно, API использует утверждения для принятия решения об авторизации. Если она не удалась, запрос должен быть отклонен.
Три части JWT
Обычно встречающийся подписанный JWT состоит из трех частей, закодированных в Base64url и разделенных точками:
header.payload.signature
- Заголовок (Header): определяет тип токена и алгоритм подписи.
- Полезная нагрузка (Payload): содержит утверждения, такие как
subдля субъекта,issдля эмитента,audдля аудитории иexpдля срока действия. - Подпись (Signature): позволяет получателю обнаружить несанкционированные изменения и проверить подписанта при использовании правильного ключа.
Кодирование Base64url не является шифрованием. Любой, кто получит обычный подписанный JWT, обычно сможет декодировать его заголовок и полезную нагрузку. Поэтому конфиденциальную информацию не следует помещать в полезную нагрузку, если система не использует соответствующий зашифрованный формат и не имеет явной необходимости в этом.
Пример JWT для начинающих
Рассмотрим API, который выдает токен после входа Алисы. Его полезная нагрузка может идентифицировать Алису как субъекта, указывать эмитент, определять API в качестве аудитории и истекать через 15 минут. Когда Алиса запрашивает свой профиль, API проверяет токен и использует утверждение субъекта для поиска нужной учетной записи.
Если кто-то изменит полезную нагрузку с идентификатора Алисы на идентификатор администратора, подпись больше не будет совпадать. Это основное преимущество подписанного JWT: подделка становится обнаружимой. Однако действительная подпись не подтверждает, что каждое утверждение является допустимым. API по-прежнему должен убедиться, что токен получен от ожидаемого эмитента и предназначался для этого API.
JWT против сессионных cookie против API-ключей
| Метод | Типичное назначение | Где хранится состояние | Основное соображение |
|---|---|---|---|
| JWT | Утверждения и авторизация API | Токен несет утверждения; серверы могут по-прежнему хранить состояние | Дизайн проверки и отзыва |
| Сессионный cookie | Сессия входа в браузер | Обычно серверное хранилище сессий | Защита cookie и CSRF |
| API-ключ | Идентификация приложения или проекта | Сервер сопоставляет ключ с разрешениями | Ключи являются долгоживущими секретами, если не обновляются |
JWT не обязательно лучше сессий. Сессии могут обеспечить немедленный отзыв, в то время как JWT могут уменьшить количество повторных запросов к базе данных и хорошо работать в распределенных системах. Многие системы сочетают оба подхода, например, краткоживущий JWT с записью токена обновления, управляемого сервером.
Зашифрованы ли JWT?
Обычно нет. Привычный трехкомпонентный JWT чаще всего является подписанным объектом JSON Web Signature. Подпись обеспечивает целостность и подлинность при правильной реализации, но не скрывает полезную нагрузку. JSON Web Encryption — это связанный стандарт, который может обеспечить конфиденциальность, хотя он использует другую структуру и добавляет сложность управления ключами.
Это различие важно, потому что разработчики иногда вставляют JWT в декодер и удивляются, видя читаемые данные. Декодирование — это не то же самое, что успешная проверка подписи. Приложения никогда не должны предоставлять доступ только на основе декодированных утверждений.
Распространенные риски безопасности JWT
Рекомендации по лучшим практикам JWT от IETF, RFC 8725, рассматривают ошибки реализации, которые встречались в реальных системах. Наибольшие проблемы обычно возникают из-за неправильной проверки, а не из-за самого базового формата.
- Путаница алгоритмов: принятие неожиданного или небезопасного алгоритма.
- Отсутствие проверок утверждений: игнорирование эмитент, аудитории, срока действия или других требований приложения.
- Кража токена: раскрытие токена-носителя через журналы, скрипты, небезопасное хранилище или незащищенную передачу.
- Слабые ключи: использование угадываемых секретов или отказ от ротации скомпрометированных ключей подписи.
- Длительный срок действия: оставление украденным токенам возможности быть полезными слишком долго.
- Плохой отзыв: предположение, что подписанный токен никогда не может нуждаться в досрочной инвалидации.
Лучшие практики JWT
Приложения должны явно разрешать только поддерживаемые ими алгоритмы, проверять каждое необходимое утверждение и использовать отдельные правила проверки для разных типов JWT. Токены должны быть краткосрочными, передаваться только через HTTPS и исключаться из URL-адресов и обычных журналов. Ключи подписи требуют безопасного хранения, ротации и четкого владения.
Хранение зависит от приложения. Браузерные системы могут использовать безопасные cookie HttpOnly и SameSite, в то время как мобильные или серверные клиенты используют защищенное хранилище, соответствующее платформе. Ни один выбор хранилища не устраняет всех угроз, поэтому разработчики должны одновременно учитывать межсайтовый скриптинг, межсайтовую подделку запросов, повторное использование токенов и компрометацию устройств.
Заключение
JWT — это компактный способ переноса проверяемых утверждений между системами. Его заголовок описывает, как он защищен, его полезная нагрузка содержит утверждения, а его подпись помогает получателям обнаруживать подделку. JWT могут упростить аутентификацию API, но только когда получатель проверяет правильный алгоритм, эмитент, аудиторию, временные утверждения и подпись. Для начинающих ключевое правило простое: JWT — это формат учетных данных, а не доказательство того, что вся схема аутентификации безопасна.
Часто задаваемые вопросы
Что означает JWT?
JWT означает JSON Web Token, стандартизированный компактный формат для передачи утверждений в виде JSON.
Может ли кто-нибудь декодировать JWT?
Любой, у кого есть типичный подписанный JWT, обычно может декодировать его заголовок и полезную нагрузку. Декодирование не проверяет подпись и не делает утверждения достоверными.
Является ли JWT тем же, что и токен доступа?
Нет. Токен доступа описывает назначение, в то время как JWT описывает формат. Некоторые токены доступа являются JWT, а другие — непрозрачными строками.
Как долго должен действовать JWT?
Универсальной продолжительности нет. Токены доступа обычно краткосрочные, точная продолжительность жизни зависит от требований системы к риску, отзыву и удобству использования.
Может ли JWT быть отозван?
Да, но отзыв требует дополнительного проектирования, такого как черный список, ротация ключей, версионирование токенов или система токенов обновления, управляемая сервером.
