Где Front хранит токен авторизации?

Где Frontend хранит токен авторизации?

В современной веб-разработке frontend-часть приложения может хранить токены авторизации (обычно JWT — JSON Web Token) в нескольких местах, каждый из которых имеет свои преимущества, недостатки и сценарии использования. Выбор способа хранения напрямую влияет на безопасность, UX и архитектуру приложения.

Основные места хранения токенов

1. Локальное хранилище браузера (localStorage)
2. Сессионное хранилище (sessionStorage)
3. HTTP-Only куки (HttpOnly cookies)
4. Память приложения (in-memory)

1. localStorage (Постоянное хранилище)

localStorage предоставляет долговременное хранилище данных (до 5-10 МБ в зависимости от браузера), которое сохраняется между сессиями. Это самый распространённый, но и самый спорный способ.

// Сохранение токена
const token = 'eyJhbGciOiJIUzI1NiIs...';
localStorage.setItem('auth_token', token);

// Получение токена
const storedToken = localStorage.getItem('auth_token');

// Удаление токена при logout
localStorage.removeItem('auth_token');

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

• Простота реализации
• Токен доступен во всех вкладках/окнах одного домена
• Не требует дополнительной настройки сервера

Недостатки:

• Уязвимость к XSS-атакам (Cross-Site Scripting) — злоумышленник может внедрить JavaScript, который прочитает токен из localStorage
• Токен не очищается автоматически — требует явного удаления
• Не поддерживается в старых браузерах (IE7 и ниже)

2. sessionStorage (Сессионное хранилище)

Работает аналогично localStorage, но данные очищаются при закрытии вкладки браузера.

// Токен доступен только в текущей вкладке
sessionStorage.setItem('session_token', token);

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

• Более безопасен, чем localStorage — токен живёт только в рамках одной сессии
• Автоматическая очистка при закрытии вкладки

Недостатки:

• Токен не переносится между вкладками (пользователю нужно логиниться на каждой новой вкладке)
• Та же уязвимость к XSS, что и у localStorage

3. HTTP-Only Cookies (Безопасные куки)

Самый безопасный способ с точки зрения защиты от XSS.

// Frontend не имеет прямого доступа к кукам
// Установка происходит через сервер в заголовках ответа

// Пример ответа сервера при аутентификации
// Set-Cookie: auth_token=eyJhbGci...; HttpOnly; Secure; SameSite=Strict; Path=/

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

• Иммунитет к XSS — JavaScript не может прочитать куку с флагом HttpOnly
• Автоматическая отправка с каждым запросом (при правильных настройках domain/path)
• Браузерные механизмы управления сроком жизни (Expires, Max-Age)

Недостатки:

• Уязвимость к CSRF-атакам (требует дополнительной защиты)
• Сложнее реализовать stateless-архитектуру (токены в куках обычно требуют валидации на сервере)
• Ограничения по размеру (≈4КБ на куку, ≈20 кук на домен)

4. Хранение в памяти приложения (In-Memory)

Токен хранится только в переменной JavaScript и очищается при обновлении страницы.

let authToken = null;

// После успешного логина
authToken = response.data.token;

// При logout
authToken = null;

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

• Максимальная безопасность — токен полностью недоступен извне
• Идеально для одностраничных приложений (SPA) с короткими сессиями

Недостатки:

• Токен теряется при обновлении страницы — плохой UX
• Не подходит для долгоживущих сессий

Рекомендации по выбору способа хранения

Для максимальной безопасности (финтех, банки):

1. HttpOnly + Secure + SameSite=Strict куки
2. Дополнительная защита от CSRF через anti-CSRF токены
3. Короткий срок жизни access-токена (15-30 минут)
4. Использование refresh-токенов в HttpOnly куках для продления сессии

// Пример защищённой конфигурации
// Access-токен: короткоживущий, в памяти
// Refresh-токен: долгоживущий, в HttpOnly куке

// После логина
const { accessToken, refreshToken } = await login(credentials);
// accessToken хранится в памяти, refreshToken устанавливается сервером в куку

Для SPA с хорошим UX:

1. Access-токен в localStorage/sessionStorage
2. Refresh-токен в HttpOnly куке (если используется)
3. Реализация automatic token refresh при истечении срока
4. Защита от XSS через CSP (Content Security Policy) и санитизацию пользовательского ввода

// Пример автоматического обновления токена
async function fetchWithAuth(url, options = {}) {
  let token = localStorage.getItem('access_token');
  
  try {
    const response = await fetch(url, {
      ...options,
      headers: {
        ...options.headers,
        'Authorization': `Bearer ${token}`
      }
    });
    
    if (response.status === 401) {
      // Токен истёк, пробуем обновить
      const newToken = await refreshToken();
      localStorage.setItem('access_token', newToken);
      // Повторяем запрос с новым токеном
      return fetchWithAuth(url, options);
    }
    
    return response;
  } catch (error) {
    console.error('Auth error:', error);
    throw error;
  }
}

Ключевые принципы безопасности

1. Никогда не храните токены в plain text — используйте безопасные механизмы браузера
2. Всегда используйте HTTPS — особенно при работе с куками (флаг Secure)
3. Настройте CORS правильно — ограничьте источники, которые могут делать запросы
4. Реализуйте механизм инвалидации токенов — при logout токены должны становиться недействительными
5. Используйте short-lived access tokens и long-lived refresh tokens
6. Регулярно аудитируйте свою реализацию — безопасность требует постоянного внимания

Вывод

Оптимальный подход часто включает комбинацию методов: access-токен в памяти или localStorage для удобства, refresh-токен в HttpOnly куке для безопасности, плюс дополнительные меры защиты (CSP, CSRF-токены, правильные CORS). Выбор зависит от конкретных требований приложения: уровень необходимой безопасности, требуемый UX, архитектура backend (stateless vs stateful) и поддержка legacy-браузеров. В 2024 году тренд смещается в сторону использования HttpOnly кук с флагами Secure и SameSite, особенно для критичных приложений, поскольку это обеспечивает наилучшую защиту от наиболее распространённых веб-уязвимостей.