Как работает JSON Web Token (JWT)?

Question

IT Interview Practice · Accepted Answer

**JSON Web Token (JWT)** — это компактный, безопасный для URL, самодостаточный токен, несущий утверждения (claims) о пользователе. Сервер подписывает его один раз; после этого он может **проверять** токен на каждом запросе без обращения к базе данных — именно это делает аутентификацию на основе JWT *безсостоятельной* (stateless).

## Структура: три части base64url

JWT — это `header.payload.signature`, три сегмента в кодировке base64url, соединённые точками:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header
.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDB9      ← payload (claims)
.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1    ← signature
```

- **Header** — алгоритм подписи, например `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — **утверждения** (claims): стандартные, такие как `sub` (субъект/id пользователя), `exp` (истечение), `iat` (время выпуска), `iss` (издатель), плюс любые пользовательские поля (`role`, `email`).
- **Signature** — вычисляется над заголовком и payload с помощью секрета или закрытого ключа.

> Payload **закодирован, а не зашифрован**. Любой может декодировать его из base64 и прочитать, поэтому никогда не помещайте пароли или секреты в JWT.

## Как работают подпись и проверка

```
signature = HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)
```

- **HS256** (симметричный): один и тот же секрет подписывает и проверяет. Просто, но каждый проверяющий должен хранить секрет.
- **RS256** (асимметричный): **закрытый ключ** подписывает, **открытый ключ** проверяет. Сервер аутентификации хранит закрытый ключ; другие сервисы проверяют открытым ключом и никогда не могут выпускать токены.

На каждом запросе сервер пересчитывает подпись над полученными header+payload и сравнивает её. Если они совпадают и `exp` в будущем, токену доверяют — хранилище сессий не нужно.

```js
const jwt = require("jsonwebtoken");

const token = jwt.sign({ sub: "123", role: "admin" }, SECRET, {
  expiresIn: "15m",
});

try {
  const claims = jwt.verify(token, SECRET); // бросает исключение, если подделан или истёк
  // claims.sub === "123"
} catch (e) {
  // отклонить: недействителен или истёк
}
```

## Трудная часть: отзыв (revocation)

Поскольку проверка безсостоятельна, вы **не можете** аннулировать токен до его истечения, просто «удалив» его на стороне сервера. Распространённые меры смягчения:

- Держите токены доступа **короткоживущими** (5–15 мин) и сочетайте их с более долгоживущим **токеном обновления** (refresh token).
- Ведите небольшой **список запрета** (denylist) отозванных id токенов (`jti`) для выхода/компрометации — это снова вводит немного состояния.
- Ротируйте ключи подписи.

## Компромиссы хранения

| Хранилище | Плюс | Минус |
|---|---|---|
| Cookie `httpOnly` | Не читается из JS (безопаснее к XSS) | Требует защиты от CSRF |
| `localStorage` | Просто, без CSRF | Уязвим к XSS |

## Почему это важно

JWT обеспечивают безсостоятельную аутентификацию в API, микросервисах и SPA — сервис может довериться запросу, проверив лишь подпись, без общего хранилища сессий. Но та же безсостоятельность — классическая ловушка на собеседовании: токены нелегко отозвать, payload читается, а путаница `alg` или отсутствие проверки истечения — реальные уязвимости. Точное понимание того, что защищает подпись, а что нет, необходимо для безопасного использования JWT.

Хранилище	Плюс	Минус
Cookie `httpOnly`	Не читается из JS (безопаснее к XSS)	Требует защиты от CSRF
`localStorage`	Просто, без CSRF	Уязвим к XSS

Структура: три части base64url

Как работают подпись и проверка

Трудная часть: отзыв (revocation)

Компромиссы хранения

Почему это важно

Похожие вопросы