Что такое Access token в JWT?

Что такое Access Token в JWT?

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

Основная идея и назначение

В отличие от традиционных сессий на сервере (stateful), где состояние хранится в памяти или БД сервера, JWT Access Token является stateless (без состояния). Его основная задача — позволить клиенту (например, мобильному приложению или фронтенду) предоставлять доказательство своей аутентификации и авторизации при каждом запросе к защищенному ресурсу без необходимости постоянных обращений к серверу аутентификации для проверки.

Структура JWT Access Token

JWT состоит из трех частей, разделенных точками: Header.Payload.Signature. Access Token чаще всего реализуется именно в этом формате.

// Пример Header
{
  "alg": "HS256",  // Алгоритм шифрования (например, HMAC SHA-256)
  "typ": "JWT"     // Тип токена
}

// Пример Payload (самые важные данные для Access Token)
{
  "sub": "1234567890",        // Subject — идентификатор пользователя
  "name": "John Doe",         // Дополнительная информация
  "iat": 1516239022,          // Issued At — время создания токена
  "exp": 1516242622           // Expiration — время истечения токена (ОЧЕНЬ важно!)
  // Могут быть и другие claims, например, "scope" для прав доступа.
}

// Финальный токен выглядит так (закодированный в Base64):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJexpIjoxNTE2MjQyNjIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• Header: Определяет алгоритм шифрования.
• Payload: Содержит claims — основную информацию о пользователе и метаданные токена (особенно ключевые поля iat и exp).
• Signature: Создается путем шифрования объединенных header и payload с использованием секретного ключа (или публичного/приватного ключа в случае RSA). Это гарантирует, что токен не был изменен после его выпуска.

Как работает Access Token JWT в потоке авторизации?

Рассмотрим классическую схему OAuth 2.0 с использованием JWT:

1. Аутентификация: Пользователь логинится, предоставляя credentials (например, логин/пароль) на сервере аутентификации (Authorization Server).
2. Выпуск токена: Сервер аутентификации проверяет данные и, если они верны, создает JWT Access Token. Он включает в payload идентификатор пользователя (sub), срок действия (exp), права (scope) и подписывает его.
3. Передача клиенту: Токен возвращается клиенту (часто в теле ответа вместе с Refresh Token).
4. Доступ к ресурсам: При каждом запросе к защищенному API (Resource Server) клиент добавляет этот токен в заголовок Authorization: Bearer <your_jwt_access_token>.
5. Верификация на Resource Server: Сервер ресурсов:

    *   Проверяет **Signature** токена, используя известный ему секретный/публичный ключ. Это подтверждает, что токен был выпущен доверенным Authorization Server и не был подделан.
    *   Проверяет срок действия (`exp`). Если токен истек, запрос отвергается.
    *   Извлекает из payload данные пользователя (`sub`, `scope`) и использует их для **авторизации** — проверки, имеет ли этот конкретный пользователь право на выполнение данного запроса.
    *   **НЕ проверяет токен по базе данных или делает запрос к Authorization Server** (stateless подход).

Ключевые преимущества JWT как Access Token

• Stateless и масштабируемость: Серверу ресурсов не нужно хранить состояние сессии. Это упрощает масштабирование и горизонтальное расширение кластера серверов API.
• Самостоятельность (Self-contained): Все необходимые данные для авторизации содержатся внутри токена, что уменьшает нагрузку на базы данных.
• Поддержка микросервисов: Идеально для распределенных систем, где множество сервисов могут независимо проверять токен без центрального хранилища сессий.
• Удобство для клиента: Клиент (особенно мобильный или SPA) просто хранит токен и использует его, не управляя сложными сессионными куками.

Важные ограничения и соображения безопасности

• Неизменяемость после выпуска: Права (claims), записанные в токен при выпуске, нельзя изменить до его истечения. Для изменения прав нужно выпустить новый токен.
• Кратковременность жизни: Access Token по безопасности должен иметь относительно короткий срок жизни (например, 15 минут — 1 час). Это ограничивает риск, если токен будет скомпрометирован (украден).
• Нельзя отозвать мгновенно: Из-за stateless природы, если токен был выпущен, его нельзя "удалить" из системы до естественного истечения (exp). Для контроля доступа часто используют черные списки (blacklist) или очень короткие сроки жизни вместе с Refresh Token для получения нового Access Token.
• Размер: JWT может быть крупнее, чем случайный идентификатор сессии, и передаваться в каждом запросе.
• Безопасная передача и хранение: Токен должен передаваться только по HTTPS и безопасно храниться на клиенте (не в localStorage для веб-приложений из-за риска XSS, лучше в памяти или защищенных куках).

Пример базовой проверки JWT Access Token на PHP (Resource Server)

<?php
// Используем библиотеку firebase/php-jwt (предварительно установить через Composer)
use Firebase\JWT\JWT;
use Firebase\JWT\Key;

// Токен из заголовка Authorization
$jwt = $_SERVER['HTTP_AUTHORIZATION']; // "Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9..."
$jwt = str_replace('Bearer ', '', $jwt);

// Секретный ключ, известный Resource Server и Authorization Server (для HS256)
$secretKey = 'your-super-secret-key';

try {
    // Декодируем и проверяем токен: signature и exp
    $decoded = JWT::decode($jwt, new Key($secretKey, 'HS256'));
    
    // $decoded теперь содержит объект payload
    $userId = $decoded->sub;
    $userRole = $decoded->role; // Пример claim'а с ролью
    
    // Авторизация: проверяем право на доступ к текущему эндпоинту
    if ($userRole !== 'admin' && $currentEndpoint === '/admin/data') {
        http_response_code(403);
        exit('Forbidden');
    }
    
    // Пропускаем запрос дальше в приложение
    $request->setUserId($userId);
    
} catch (\Exception $e) {
    // Любая ошибка: неверная signature, истекший токен, невалидный формат
    http_response_code(401);
    exit('Invalid or expired access token');
}
?>

Таким образом, JWT Access Token — это мощный и стандартизированный механизм для безопасной передачи контекста аутентификации и авторизации в современных распределенных приложениях, сочетающий в себе самостоятельность, stateless-архитектуру и относительную простоту реализации.