Какие знаешь виды токенов?

Виды токенов в веб-разработке

В контексте фронтенд-разработки и веб-iприложений под "токенами" обычно понимаются авторизационные токены, которые используются для управления доступом и безопасной передачи данных о пользователе между клиентом и сервером. Они являются фундаментальным элементом современных аутентификационных механизмов.

1. Токены доступа (Access Tokens)

Это наиболее распространённый тип токенов, используемый для доступа к защищённым ресурсам API.

Характеристики:

• Краткий срок жизни: Обычно от 15 минут до нескольких часов.
• Содержание: Включает информацию о пользователе (claims) и разрешения (scopes).
• Формат: Чаще всего JWT (JSON Web Token), состоящий из трёх частей: заголовка, полезной нагрузки и подписи, разделённых точками.
• Передача: Как правило, в заголовке Authorization: Bearer <token>.

Пример JWT-структуры:

// Декодированная полезная нагрузка (payload)
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1516242622,
  "scope": "read:profile write:posts"
}

2. Токены обновления (Refresh Tokens)

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

Характеристики:

• Длинный срок жизни: Дни, недели или даже месяцы.
• Хранение: Должны храниться максимально безопасно на сервере или в защищённом клиентском хранилище (например, HTTP-only cookie).
• Уязвимость: Поскольку они долгоживущие, компрометация такого токена критична, поэтому реализуются механизмы отзыва (revocation).

Типичный flow OAuth 2.0 с refresh token:

// 1. Первоначальный запрос на аутентификацию (обычно через форму входа)
// 2. Сервер возвращает access_token и refresh_token

// 3. Когда access_token истекает, клиент использует refresh_token
async function refreshAccessToken() {
  const response = await fetch('/api/auth/refresh', {
    method: 'POST',
    credentials: 'include', // Для отправки HTTP-only cookie с refresh token
    headers: {
      'Content-Type': 'application/json'
    },
    // ИЛИ тело с refresh token, если хранится иначе
    body: JSON.stringify({ refresh_token: storedRefreshToken })
  });
  const { access_token, expires_in } = await response.json();
  // Обновляем access_token в памяти приложения
  return access_token;
}

3. Идентификационные токены (ID Tokens)

Специфичны для протокола OpenID Connect (расширение OAuth 2.0). Их цель — предоставить клиенту информацию о пользователе, а не доступ к ресурсам.

Характеристики:

• Содержание: Стандартные claims о пользователе (sub, name, email и т.д.).
• Аудитория (aud): Всегда предназначен для клиентского приложения.
• Формат: Также JWT.

4. Токены подтверждения (CSRF Tokens)

Защищают от межсайтовой подделки запроса (Cross-Site Request Forgery). Это не авторизационные, а защитные токены.

Принцип работы:

• Сервер генерирует уникальный токен и привязывает его к сессии пользователя.
• Токен включается в скрытые поля форм (<input type="hidden">) или в заголовки для AJAX-запросов.
• Сервер проверяет соответствие токена из запроса и токена в сессии.

Пример реализации в форме:

<form action="/api/transfer-money" method="POST">
  <input type="hidden" name="csrf_token" value="{{csrfToken}}">
  <input type="text" name="amount">
  <button type="submit">Перевести</button>
</form>

5. Токены для сброса пароля и верификации (One-Time Tokens)

Используются для одноразовых действий, таких как сброс пароля или подтверждение email.

Характеристики:

• Одноразовые: После использования становятся недействительными.
• Кратковременные: Срок жизни часто ограничен несколькими минутами или часами.
• Высокая энтропия: Должны быть криптографически стойкими, чтобы противостоять подбору.

Сравнительная таблица

Критические аспекты безопасности и хранения на фронтенде

• Access Token в SPA: Не хранить в LocalStorage из-за уязвимости к XSS-атакам. Предпочтительнее хранить в памяти приложения или использовать безопасные cookie с флагами HttpOnly, Secure, SameSite.
• Refresh Token: Никогда не должен быть доступен JavaScript. Идеальное решение — HttpOnly cookie, что также упрощает защиту от CSRF.
• JWT-валидация на клиенте: Декодирование JWT для извлечения данных пользователя (например, sub, exp) — это нормально, но **клиент никогда не должен доверять содержимому токена для принятия security.
• Механизм отзыва (Revocation): Система должна иметь возможность отозвать скомпрометированные токены, особенно refresh tokens.

Выбор типа токена и стратегии его хранения напрямую зависит от архитектуры приложения (SPA, SSR, мобильное), требований безопасности и используемых протоколов аутентификации (OAuth 2.0, OpenID Connect).