JWT

JWT, или JSON Web Token, — компактный формат передачи набора утверждений между системами. Он широко применяется в Web Applications, API, SSO, OAuth и OpenID Connect для передачи информации о пользователе, клиенте, правах доступа и сроке действия токена.

JWT представляет собой строку, состоящую из нескольких частей. В типичном подписанном JWT содержатся Header, Payload и Signature. Подпись позволяет получателю проверить, что данные не были незаметно изменены после выпуска токена.

Важно понимать: обычный подписанный JWT не шифрует Payload. Его содержимое может быть прочитано тем, кто получил сам Token. Поэтому внутрь JWT не следует помещать Password, банковские данные и другие Secrets только потому, что токен имеет необычный внешний вид.

JWT обычно обеспечивает целостность и подтверждение источника данных с помощью цифровой подписи, но не скрывает содержимое Payload.

Что такое JWT простыми словами

Представим, что пользователь вошел в Web Application.

После успешной Authentication сервер может создать Token с информацией:

user_id: 125
role: manager
expires: 17:30

Затем Server подписывает эти данные и передает JWT приложению.

При следующем обращении к API Client отправляет Token:

Client
↓ JWT
API
↓ verify signature
Access granted or denied

API может проверить подпись, срок действия и другие Claims, не обращаясь за каждой проверкой к исходному Authentication Server, если архитектура допускает локальную валидацию.

Расшифровка JWT

JWT расшифровывается как JSON Web Token.

JSON используется для представления Claims, а Token передается между участниками системы как компактная строка.

Как выглядит JWT

Типичный подписанный JWT состоит из трех частей, разделенных точками:

xxxxx.yyyyy.zzzzz

Логически:

Header.Payload.Signature

Каждая часть кодируется в текстовое представление, удобное для передачи через HTTP.

Структура JWT

Header

Header обычно содержит служебную информацию.

Пример логического содержимого:

{
 "typ": "JWT",
 "alg": "RS256"
}

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

Payload

Payload содержит Claims — утверждения о пользователе, клиенте или самом токене.

Например:

{
 "sub": "user-125",
 "role": "manager",
 "exp": 1786987800
}

Payload не следует считать зашифрованным.

Signature

Signature формируется на основе Header, Payload и криптографического ключа.

Получатель повторно проверяет подпись и убеждается, что данные не были изменены.

Зачем нужна подпись

Без подписи злоумышленник мог бы изменить:

role: user

на:

role: admin

и попытаться получить дополнительные Permissions.

Корректная проверка Signature должна обнаружить такое изменение.

Base64URL

Части JWT обычно представлены в Base64URL-кодировании.

Это кодирование, а не Encryption.

Любой, кто получил Token, может декодировать Header и Payload без знания Secret Key.

Почему Base64 не шифрование

Base64 предназначен для преобразования бинарных данных в текстовый формат.

Он не обеспечивает конфиденциальность.

Поэтому секретная информация не становится защищенной только после Base64URL Encoding.

Claims

Claims — данные, содержащиеся внутри JWT.

Они могут описывать:

• пользователя;
• Issuer;
• Audience;
• срок действия;
• Roles;
• Scopes;
• идентификатор Token.

Registered Claims

Для JWT существует набор стандартных имен Claims, которые имеют определенное назначение.

Issuer

Claim iss определяет, кто выпустил Token.

Resource Server должен принимать Tokens только от доверенного Issuer.

Например:

iss = https://auth.example.com

Subject

Claim sub идентифицирует субъект Token.

Это может быть User ID или идентификатор технического Client.

Audience

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

API не должно принимать JWT, выпущенный для другого Application, только потому что подпись корректна.

Expiration Time

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

Проверка Expiration является обязательной частью безопасной Token Validation.

Not Before

nbf указывает момент, раньше которого Token еще не должен приниматься.

Это полезно для Tokens, действие которых начинается не сразу.

Issued At

iat показывает время выпуска Token.

Оно может использоваться в Audit и дополнительных Security Rules.

JWT ID

jti — уникальный идентификатор конкретного Token.

Он может использоваться для Audit, защиты от повторного использования или реализации списка отозванных Tokens.

Custom Claims

Кроме стандартных Claims, система может добавлять собственные.

Например:

department: finance
role: accountant
subscription: premium

Имена и смысл таких Claims определяет конкретная Application Architecture.

JWT и Authentication

JWT часто используется после успешной Authentication.

Пользователь вводит Credentials, сервер проверяет их и затем создает Token.

Login + Password
↓
Authentication Server
↓
JWT
↓
Client

Но сам формат JWT не выполняет проверку Password пользователя.

JWT и Authorization

JWT может содержать Roles или Scopes, используемые для принятия решения о доступе.

Например:

scope: invoices.read

API проверяет Token и разрешает только соответствующую операцию.

JWT не заменяет Authorization

Наличие корректного Token не означает автоматически право на любой объект.

Если пользователь имеет invoices.read, приложение все равно должно проверить, имеет ли он право читать именно конкретный Invoice.

JWT и OAuth

OAuth определяет протокол делегирования доступа, а JWT является одним из возможных форматов Token.

OAuth не требует, чтобы каждый Access Token обязательно был JWT.

JWT Access Token

Authorization Server может выпустить Access Token в формате JWT.

Resource Server проверяет Signature, Issuer, Audience, Expiration и необходимые Scopes.

Opaque Token и JWT

JWT и OpenID Connect

OpenID Connect использует ID Token, который обычно имеет формат JWT.

Он содержит информацию о результате Authentication пользователя.

ID Token

ID Token предназначен для Client Application и сообщает ей, кто прошел Authentication.

Его не следует бездумно использовать как Access Token для API.

Access Token и ID Token

JWT и SSO

В современной SSO Architecture JWT может использоваться для передачи Identity или Access Information между Identity Provider и Applications.

Однако SSO не является самим JWT — это отдельная архитектурная функция.

JWT и API

Один из наиболее частых сценариев — защита REST API.

Client отправляет Token в HTTP Header:

Authorization: Bearer eyJ...

API проверяет Token до выполнения бизнес-операции.

Bearer JWT

Если JWT используется как Bearer Token, любой, кто получил его значение, потенциально может использовать Token в рамках его Lifetime и Permissions.

Поэтому его необходимо защищать как Credential.

JWT и HTTPS

JWT необходимо передавать через HTTPS.

Цифровая подпись защищает Token от незаметного изменения, но сама по себе не предотвращает его перехват по сети.

Почему подпись не защищает от кражи

Если злоумышленник перехватил действующий Bearer Token, ему необязательно менять Payload.

Он может попытаться повторно отправить Token API.

Поэтому TLS и безопасное хранение остаются обязательными.

JWT Signature и Encryption

Подписанный Token обеспечивает Integrity и Authenticity, но не Confidentiality.

Если необходимо скрыть Payload, используются отдельные механизмы шифрования, а не надежда на обычную подпись JWT.

JWS

Подписанная структура в экосистеме JOSE связана с концепцией JSON Web Signature.

Типичный трехчастный JWT часто является подписанным JWS Representation.

JWE

JSON Web Encryption используется для шифрования данных.

Зашифрованная структура отличается от обычного трехчастного подписанного Token и решает задачу Confidentiality.

JWT и JWE

JWT описывает набор Claims, а конкретное представление может быть подписанным или зашифрованным согласно используемой архитектуре.

Большинство JWT, встречающихся в API Authentication, являются подписанными, а не зашифрованными.

Симметричная подпись

При симметричной схеме одна сторона подписывает Token Secret Key, а проверяющая сторона использует тот же Secret.

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

HMAC

HMAC является примером механизма, использующего общий Secret для создания и проверки Authentication Code.

В JWT могут применяться алгоритмы семейства HS при соответствующей архитектуре.

Асимметричная подпись

При асимметричной схеме Authorization Server хранит Private Key, а Resource Servers получают Public Key.

Private key → sign
Public key → verify

API может проверять Tokens, но не получает ключ, позволяющий выпускать новые подписи.

Преимущество асимметричной подписи

Она удобна, когда множество независимых Services должны проверять Token одного централизованного Issuer.

Private Key остается только у доверенного Authorization Server.

Private Key

Закрытый ключ является критичным Secret.

Если он скомпрометирован, злоумышленник потенциально сможет создавать Tokens с корректной Signature.

Ключ необходимо хранить в защищенной Key Management Infrastructure.

Public Key

Public Key можно распространять между Resource Servers для проверки Signature.

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

JWKS

JSON Web Key Set позволяет публиковать набор Public Keys, которые Resource Server может использовать для проверки JWT.

Это удобно для централизованного Identity Provider и ротации ключей.

kid

Поле kid в Header может указывать идентификатор Key, которым был подписан Token.

Resource Server использует его, чтобы выбрать подходящий Public Key из доверенного набора.

Key Rotation

Криптографические ключи необходимо периодически менять.

При Rotation некоторое время могут одновременно существовать старый и новый Public Key, чтобы ранее выпущенные Tokens продолжали проверяться до истечения срока действия.

Почему нельзя доверять alg из Token без ограничений

Resource Server должен заранее знать, какие алгоритмы разрешены для конкретного Issuer.

Нельзя слепо принимать любой alg, который указал сам входящий Token.

Algorithm Confusion

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

Поэтому допустимые алгоритмы должны задаваться конфигурацией приложения.

alg none

Некоторые реализации могут поддерживать неподписанные структуры для специальных сценариев.

API, которое ожидает подписанный Token, не должно принимать неподписанный JWT только потому, что Header указывает отсутствие алгоритма.

JWT Validation

Безопасная проверка Token не ограничивается Signature.

Обычно необходимо проверить:

• Signature;
• Issuer;
• Audience;
• Expiration;
• Not Before;
• разрешенный Algorithm;
• необходимые Scopes или Claims.

Почему одной подписи недостаточно

Token может быть корректно подписан доверенным Server, но предназначаться совершенно другому API.

Если Audience не проверяется, такой Token может быть принят ошибочно.

Clock Skew

Server Clocks могут отличаться на несколько секунд.

При проверке exp и nbf иногда допускается небольшой контролируемый временной допуск.

Слишком большой Skew увеличивает окно действия Tokens.

Синхронизация времени

Authorization Server и Resource Servers должны иметь корректное время.

Ошибки NTP могут приводить к неожиданному отклонению действующих Tokens или принятию уже просроченных в плохо настроенной системе.

JWT Lifetime

Чем дольше Token действует, тем дольше злоумышленник может использовать его после кражи.

Но слишком короткий Lifetime создает дополнительные Refresh Operations.

Срок действия выбирают в зависимости от риска и архитектуры.

Access Token и Refresh Token

В OAuth Architecture часто используется короткоживущий Access Token и более долговечный Refresh Token.

Refresh Token
↓
Authorization Server
↓
New short-lived Access Token

Refresh Token не обязан иметь формат JWT.

JWT и Refresh Token

Некоторые системы используют JWT и для Refresh Token, но это не обязательное свойство протокола.

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

Отзыв JWT

Один из недостатков полностью автономных JWT — сложность немедленного Revocation.

Если Token проверяется локально и действует еще час, API может продолжать принимать его даже после блокировки User.

Как решают проблему Revocation

Возможны разные подходы:

• короткий Access Token Lifetime;
• Revocation List;
• контроль jti;
• централизованная Session State;
• Token Introspection;
• ротация ключей в аварийных случаях.

Blacklist

Application может хранить список jti отозванных Tokens.

Но это частично уменьшает преимущество полностью Stateless Validation, поскольку каждому API может потребоваться доступ к общему состоянию.

Stateless Authentication

JWT часто называют удобным для Stateless Authentication, потому что Server может хранить необходимые Claims внутри Token вместо Server-side Session.

Однако реальная система все равно может иметь State для Revocation, Device Management и Refresh Tokens.

JWT и Session Cookie

JWT и Cookie не являются альтернативами одного уровня.

JWT — формат Token, а Cookie — механизм Browser для хранения и передачи данных.

JWT технически можно хранить в Cookie, хотя конкретная архитектура должна учитывать Security Properties.

JWT в Cookie

Если JWT хранится в Secure HttpOnly Cookie, Browser автоматически отправляет его Server.

Это уменьшает прямой доступ JavaScript к Token, но необходимо учитывать CSRF Protection.

JWT в Local Storage

Хранение Token в Local Storage удобно для JavaScript, но при XSS вредоносный Script может попытаться его прочитать.

Поэтому выбор Storage нельзя делать без анализа Threat Model.

HttpOnly Cookie

HttpOnly запрещает обычному JavaScript читать Cookie.

Это уменьшает риск прямой кражи Token через XSS, но не устраняет все последствия XSS и не заменяет другие Web Security Controls.

Secure Cookie

Secure Cookie передается только через HTTPS.

Это важное свойство для Authentication Credentials.

SameSite

SameSite помогает управлять отправкой Cookies в Cross-site Requests и может участвовать в защите от CSRF.

Конкретная настройка зависит от архитектуры SSO и Web Application.

JWT и CSRF

Риск CSRF зависит не от самого формата JWT, а от способа его хранения и автоматической передачи Browser.

Если Token отправляется через Cookie, необходимо учитывать обычные CSRF-механизмы защиты.

JWT и XSS

XSS может быть особенно опасен, если JavaScript способен прочитать Access Token.

Поэтому JWT не освобождает разработчика от Content Security Policy, безопасного рендеринга данных и других мер Web Security.

JWT и CORS

CORS регулирует Browser Access между Origins.

Он не выполняет Token Authentication.

API должно проверять JWT независимо от CORS Configuration.

JWT в URL

Передавать Access Token в Query String обычно нежелательно.

URL может попасть в Browser History, Proxy Logs, Analytics и Referrer Data.

Для API обычно используется Authorization Header или другой предусмотренный механизм.

JWT в логах

Полный Token не следует без необходимости записывать в Application Logs.

Лог может попасть в SIEM, Backup или систему поддержки, существенно расширяя круг людей и систем с доступом к Credential.

Что логировать вместо JWT

Для диагностики достаточно сохранить:

• jti;
• Issuer;
• Subject;
• результат Validation;
• частично замаскированный идентификатор.

Полный Bearer Token обычно не нужен.

JWT и микросервисы

JWT удобен в Microservices Architecture, где множество Services должны знать Identity и Permissions пользователя.

Client
↓ JWT
API Gateway
↓
Service A
Service B
Service C

Но распространение одного Token по всей инфраструктуре требует строгой проверки Audience и минимальных Scopes.

JWT и API Gateway

API Gateway может выполнять первичную Token Validation.

Однако Backend Services также должны иметь четкую модель доверия и не полагаться на произвольные Headers от внешнего Client.

Передача Identity через внутренние Headers

После Validation Gateway может передавать Backend информацию о пользователе через внутренний доверенный механизм.

При этом Backend должен быть недоступен в обход Gateway или самостоятельно проверять Token.

JWT и Service-to-Service

JWT может представлять техническую Identity Service.

Например:

sub = billing-service
scope = payments.read

API использует эти Claims для Machine-to-Machine Authorization.

JWT и Kubernetes

JWT-подобные Tokens могут применяться в Authentication компонентов и Workloads в Kubernetes Environment.

Главный принцип остается тем же: Token является Credential и должен иметь ограниченные Permissions и Lifetime.

JWT и Cloud

Cloud Identity Systems могут использовать подписанные Tokens для временного доступа к APIs и Services.

Для Cloud Workloads желательно предпочитать короткоживущие Credentials постоянным Secrets.

JWT и мобильные приложения

Mobile App может получать Access Token после Authorization Code Flow.

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

JWT в SPA

Single Page Application выполняется в Browser, поэтому особенно важно учитывать XSS и Token Storage.

В некоторых архитектурах используют Backend for Frontend, чтобы не хранить OAuth Tokens непосредственно в JavaScript Environment.

JWT и Backend for Frontend

BFF получает OAuth Tokens на Server-side, а Browser работает с обычной защищенной Application Session.

Это уменьшает прямой доступ Frontend JavaScript к долгоживущим Credentials.

JWT и кеширование

Claims внутри Token позволяют принимать некоторые решения без запроса к Database.

Но данные могут устаревать.

Если Role пользователя изменилась, старый JWT может продолжать содержать предыдущую Role до Expiration.

Устаревшие Claims

Это один из основных архитектурных компромиссов JWT.

Чем дольше Lifetime, тем дольше потенциально сохраняются устаревшие Permissions.

Не помещать динамические данные в JWT

Если значение изменяется каждую секунду, хранить его в долгоживущем Token неудобно.

JWT лучше использовать для сравнительно стабильного Authentication Context, а динамические бизнес-данные получать из актуального Source.

Размер JWT

JWT передается с каждым Request, поэтому слишком большой Payload увеличивает Network Overhead.

Не стоит помещать внутрь полную карточку пользователя, десятки групп и большие JSON Documents без необходимости.

Большое количество Roles

Если пользователь состоит в сотнях Groups, Token может стать очень большим.

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

JWT и персональные данные

Поскольку Payload легко декодируется, стоит минимизировать количество Personal Data внутри Token.

Особенно если JWT проходит через Browser, Proxy и распределенную инфраструктуру.

Не хранить Password в JWT

Password, Private Key, API Secret и другие долговременные Credentials нельзя помещать в обычный подписанный JWT.

Signature не скрывает Payload.

JWT и конфиденциальная бизнес-информация

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

JWT и Replay Attack

Украденный Bearer JWT может быть повторно использован до Expiration.

Для критичных операций можно использовать короткий Lifetime, jti, дополнительную Reauthentication или Token Binding-подобные подходы.

JWT и MFA

Token может содержать информацию о том, каким способом пользователь прошел Authentication.

Приложение может потребовать более высокий уровень Authentication перед критичной операцией.

Step-up Authentication

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

JWT и SSO Session

JWT может иметь короткий Lifetime, тогда как центральная SSO Session у IdP живет дольше.

Когда Token истекает, Client может получить новый согласно правилам Authorization Flow без повторного ввода Password.

JWT и SIEM

Security Monitoring может анализировать:

• Validation Failures;
• неверный Issuer;
• неверный Audience;
• Expired Tokens;
• аномальное использование jti;
• необычные Token Requests.

JWT и SOC

SOC может расследовать Token Theft или использование Access Token с необычного IP.

Важно иметь возможность связать Token с User, Client и исходной Authentication Session.

JWT и XDR

XDR может связывать Identity Events, Endpoint Activity и API Access.

Phishing
↓
Session theft
↓
JWT used from new device
↓
Sensitive API access

Так появляется общий Incident Context.

JWT и Zero Trust

JWT может передавать Identity Context между компонентами Zero Trust Architecture.

Но наличие Token не означает вечного доверия: необходимо учитывать Expiration, Device Risk, User Risk и текущие Policies.

Типичные ошибки при использовании JWT

1. Считать Payload зашифрованным.
2. Не проверять Signature.
3. Не проверять Issuer.
4. Не проверять Audience.
5. Игнорировать Expiration.
6. Принимать алгоритм непосредственно из Token без Allowlist.
7. Хранить JWT в небезопасном Storage.
8. Записывать полный Access Token в Logs.
9. Делать Token слишком долгоживущим.
10. Помещать слишком много данных в Payload.

Проверка JWT только на Frontend

Frontend может декодировать Token для отображения интерфейса, но Security Decision должен выполняться на доверенном Backend.

Пользователь полностью контролирует Browser и может изменить JavaScript или локальные данные.

Доверие к role из декодированного Token

Backend может использовать Role только после полной криптографической Validation JWT.

Простого Base64 Decode недостаточно.

Использование устаревшей библиотеки

JWT является Security-sensitive компонентом, поэтому необходимо использовать поддерживаемые библиотеки и безопасные стандартные настройки.

Самостоятельно реализовывать Cryptographic Validation без необходимости рискованно.

Как безопасно использовать JWT

Шаг 1. Определить назначение Token

Не смешивайте ID Token, Access Token и Application Session без четкой модели.

Шаг 2. Подписывать Token

Resource Server должен иметь возможность проверить Integrity и Issuer.

Шаг 3. Проверять обязательные Claims

Минимум включают Issuer, Audience и Expiration согласно архитектуре.

Шаг 4. Ограничить Algorithms

Allowlist задается на Server-side.

Шаг 5. Использовать короткий Lifetime

Особенно для Bearer Access Tokens.

Шаг 6. Не хранить Secrets в Payload

Подписанный JWT не обеспечивает Confidentiality.

Шаг 7. Защищать Storage и Transport

Используйте HTTPS и подходящий механизм хранения.

Шаг 8. Продумать Revocation

Особенно при блокировке пользователя или краже Token.

Практический пример

Компания имеет центральный Authorization Server и несколько внутренних APIs.

Пользователь входит через корпоративный SSO и получает Access Token.

Payload логически содержит:

{
 "iss": "https://auth.example.com",
 "sub": "employee-125",
 "aud": "finance-api",
 "scope": "invoices.read",
 "exp": 1786987800
}

Authorization Server подписывает JWT закрытым ключом.

Client отправляет его Finance API через Authorization Header.

API получает Public Key из доверенного набора и проверяет Signature.

Затем проверяются Issuer, Audience, Expiration и Scope.

Если пользователь пытается отправить DELETE Request, API отклоняет его, потому что Token содержит только invoices.read.

Если злоумышленник вручную меняет Scope на invoices.delete, Signature перестает соответствовать Payload, и Token также отклоняется.

Через короткий период JWT истекает, после чего Client должен получить новый Access Token через Authorization Infrastructure.

Так JWT позволяет передавать подписанный Access Context между независимыми сервисами без передачи Password пользователя каждому API.

JWT для бизнеса

JWT особенно полезен в распределенных системах, где множество APIs должны проверять Identity и Permissions, выданные централизованным Authorization Server.

Асимметричная подпись позволяет Resource Servers проверять Tokens с помощью Public Key, не предоставляя им возможность самостоятельно выпускать корректно подписанные Tokens.

При этом JWT требует дисциплины: минимальный Payload, короткий Lifetime, строгая Validation, безопасное Key Management и продуманный механизм Revocation.

Преимущества JWT

• компактный формат;
• поддержка стандартных Claims;
• локальная проверка Signature;
• удобен для API и микросервисов;
• подходит для распределенной Identity Infrastructure;
• может использовать асимметричную Cryptography;
• хорошо интегрируется с OAuth и OpenID Connect.

Ограничения JWT

• Payload обычного JWT не зашифрован;
• Bearer Token можно украсть и повторно использовать;
• немедленный Revocation сложнее Stateful Session;
• Claims могут устаревать;
• большой Payload увеличивает размер Requests;
• ошибки Validation создают серьезные уязвимости;
• JWT не заменяет бизнес-Authorization.

Когда использовать JWT

JWT подходит, когда необходимо передать небольшой набор проверяемых Claims между доверяющими системами, особенно в API, OAuth, OpenID Connect, SSO и Microservices Architecture.

Если системе требуется мгновенный отзыв каждой Session, большой объем динамических данных или строгая Confidentiality Payload, следует оценить альтернативные или дополнительные механизмы.

Связанные термины

Краткий итог

JWT — JSON Web Token, компактный формат передачи Claims между системами. Типичный подписанный JWT состоит из Header, Payload и Signature и позволяет Resource Server проверить, что данные были выпущены доверенной стороной и не были незаметно изменены.

JWT не следует считать зашифрованным контейнером: Header и Payload обычного подписанного Token легко декодируются. Поэтому внутрь него нельзя помещать Secrets без отдельного механизма защиты Confidentiality.

Безопасное использование JWT требует проверки Signature, Issuer, Audience, Expiration и разрешенного Algorithm, короткого Lifetime, безопасного хранения ключей и продуманного Revocation. JWT особенно полезен в API, OAuth, OpenID Connect, SSO и Microservices, но не заменяет полноценную Authentication, Authorization и защиту пользовательских Sessions.